讲一下创业公司的技术架构演进

 

 

　　从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打包服务，能够做为一种资产提供能力，提供给其余的金融机构。