合理的架构一个大型的、负载的单体应用可能会让你的整个开发进度缓慢、部署困难。所以,为了解决这种问题,不妨在开发初期便将应用程序设计为微服务架构的程序,虽然可能会提升程序之间的沟通难度,但却为你的应用提供了后续自由伸缩的可能,帮你解决后期发展起来的伸缩难题。对于已经上线的应用,整体微服务化可能是非常困难的,毕竟你不可能让整个团队重新开发一套系统出来,这样的情况下,不妨把核心的、请求量较高的业务单独拆分出来,作为一个服务,让每一个服务都变成专注与单一的责任和功能的小的区块,更好的对外提供服务。二、资源架构在云计算的时代,云计算大行其道,为各行各业提供计算能力的支持,合理的利用云计算所提供的能力,就能帮助我们更加轻松的去做好应用的高可用。一般来说,我们的每一个应用大体上都可以分为四层:入口层、业务层、缓存层、数据库层。当我们做好每一层的优化,那么我们的应用本身对于可能出现的问题进行避免。入口层入口层通常的情况下指的是Nginx、Apache等层面的东西,来负责应用的入口。一般情况下,我们会将应用程序定位在某一个IP,那么如果我们这个IP宕机了,就会导致服务的不可用,所以,在入口层我们不妨使用负载均衡,通过对压力的评估和成本的预估以及技术实现的难度,我们可以选择自建负载均衡或者使用云服务商提供的负载均衡器,在这样的情况下,当我们入口层后面的业务出现了单点故障时,可以自动借助于负载均衡的健康检查和请求分发的机制,把请求转发分配到可用的节点,保证服务的正常运转。业务层业务层通常是由PHP、Java、Python、Go等写的逻辑代码构成的,需要依赖于后台数据库及一些缓存层面的东西。如何实现业务层的高可用呢看最核心的就是,业务层不要有状态,将状态分散到缓存层和数据库。目前大家通常喜欢将以下几种数据放入业务层。第一个是session,即用户登录相关的数据,但好的做法是将session放在数据库里,或者一个比较稳定的缓存系统中。第二个是缓存,在访问数据库时,如果一个查询很慢,就希望将这些结果暂时放到进程里,下次再做查询时就不用再访问数据库了。一个简单的原则就是业务层不要有状态。在业务层没有状态时,一台业务层服务器当掉了之后,Nginx/Apache会自动将所有的请求打到另外一台业务层的服务器上。由于没有状态,两台服务器没有任何差异,所以用户完全感受不到。如果把session放在业务层里面的话,那么面临的问题是,这个用户以前是登录在一台机器上的,这个进程死掉后,用户就会被登出了。缓存层非常简单的架构里是没有缓存这个概念的。但在访问量上来之后,MySQL之类的数据库扛不住了,比如在SATA盘里跑MySQL,QPS到达200、300甚至500时,MySQL的性能会大幅下降,这时就可以考虑用缓存层来挡住绝大部分服务请求,提升系统整体的容量。缓存层如果希望实现高可用的架构,最好的方案就是将缓存层分的细一些,采用分布式的缓存或者是云计算服务商提供的云缓存能力,来减轻数据库层的压力。数据库层在数据库层面实现高可用,通常是在软件层面来做。例如,MySQL有主从模式(Master-Slave),还有主主模式(Master-Master)都能满足需求。MongoDB也有ReplicaSet的概念,基本都能满足大家的需求。