一名从百度离职的架构师是如何演进公司的技术架构

在这个系统架构上面，通过一个固定IP的Linux机器，使用Tomcat服务器搭建了仅面向PC的Web服务。在这种单服务应用会存在的问题会存在的问题有：服务不稳定　　由于每次代码升级都需要重启服务，会造成服务有小段时间的停服情况。服务器性能瓶颈　　由于单个服务的并发能力有限（tomcat并发处理上线600tps就比较高），且业务和数据库都部署在一个机器上面，随着业务发展，对服务器性能的要求会越来越高。JVM不方便调优　　业务逻辑处理、文件IO操作等都集中在一个应用中，对于JAVA应用来说，由于业务应用中部分逻辑是IO密集型的、部分是CPU密集型的、对内存的要求也是各种各样。这种情况下不方便对JVM的参数进行调优，也不方便对线程池数量进行统一设置。如果手里的资金足够，可以多采购几台服务器，采用集群式部署方式来是服务更加稳定，采用的架构如下：

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

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

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

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