推荐订阅源

　　从2015年6月百度离职后，加入创业公司到现在已经将近两年了。新系统的架构随着时间的推移做了非常多的变化以及调整，在这里对自己系统的架构的演进历程以及为什么做这种优化处理做一些总结，并讲述一下各个过程遇到的问题与解决方式。

在创业初期，为了赶上线进度一开始的时候，一切以功能为主，且创业初期资金有限，没有采购太多的服务器资源，因此系统在技术架构层面没有做太多的设计，系统的所有资源都放在一个服务器上，此时系统的架构可以如下：

　　在这个系统架构上面，通过一个固定IP的Linux机器，使用Tomcat服务器搭建了仅面向PC的Web服务。在这种单服务应用会存在的问题会存在的问题有：

1. 服务不稳定

　　由于每次代码升级都需要重启服务，会造成服务有小段时间的停服情况。

1. 服务器性能瓶颈

　　由于单个服务的并发能力有限（tomcat并发处理上线600tps就比较高），且业务和数据库都部署在一个机器上面，随着业务发展，对服务器性能的要求会越来越高。

1. JVM不方便调优

　　业务逻辑处理、文件IO操作等都集中在一个应用中，对于JAVA应用来说，由于业务应用中部分逻辑是IO密集型的、部分是CPU密集型的、对内存的要求也是各种各样。这种情况下不方便对JVM的参数进行调优，也不方便对线程池数量进行统一设置。

如果手里的资金足够，可以多采购几台服务器，采用集群式部署方式来是服务更加稳定，采用的架构如下：

　　在这个架构中，通过增加Nginx反向代理的方式，采用应用集群的方式解决了服务稳定性问题、通过增加应用服务器数量的方式提高了服务并发处理量、通过将应用服务、数据库、文件存储分离，避免了应用服务和存储相互竞争资源。但是当大量的访问、修改请求提交的数据库的时候，单机数据库较高的瓶颈。对于此问题的解决方式，可以通过增加缓存的方式处理。

　　在这种架构下，存在由于Nginx通过ip_hash或session-sticky解决会话维持对入口Nginx应用的压力较大、部分业务的查询不能做缓存且查询需要耗费较多的数据库资源、文件存储管理比较混乱，可以进一步对架构调整如下。

　　在这个架构下，通过应用服务共享Session到缓存服务上面，解决nginx主主集群部署下的会话维持。通过读写库分离，解决数据库单点的压力问题。通过独立的文件存储服务，便于文件的管理。随着业务发展，业务模块的划分的清晰。我们需要一种对支持对业务平台化，核心业务、非核心业务隔离，对于不同业务产生的数据进行隔离，需要对应用系统和数据库进行了垂直拆分，构建可靠、稳定的分布式架构。

 

　　在分布式架构下，对架构进行分层、服务化，内部简单系统（非真实系统）架构如下：

　　最后，随着技术能力的提升，可以对上述服务中的服务能力，可以提供向外的技术输出（想象一下阿里云）。比如底层服务中的缓存服务、MQ服务等基础技术服务，通过隔离机制，提供给其他公司使用；领域服务中的比如互金行业中针对小额分散产品的ABS打包服务，可以作为一种资产提供能力，提供给其他的金融机构。