技术型创业公司，创业公司结构框架图

2015年6月百度离职，加入创业公司，至今已近两年。随着时间的推移，新系统的架构经历了许多变化和调整。在这里，我总结一下自己系统的架构演变以及为什么要做这个优化，说说每个过程中遇到的问题以及解决方法。

创业之初，为了赶上当初上线的进度，所有的功能都是以功能为主，创业之初资金有限，所以系统在技术架构层面没有做太多的设计，系统的所有资源都放在一台服务器上。此时，系统的架构可以如下:

基于这种系统架构，使用固定IP的Linux机器和Tomcat服务器构建了一个纯PC的Web服务。这个单一服务应用程序会有问题。这些问题如下:

不稳定服务

因为每次代码升级都需要重新启动服务，所以服务会短时间停止服务。

服务器性能瓶颈

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

JVM不方便调优。

业务逻辑处理和文件IO操作都集中在一个应用程序中。对于JAVA应用程序，有些逻辑是IO密集型的，有些是CPU密集型的，对内存的要求也各不相同。这种情况下，不方便调优JVM的参数，统一设置线程池的数量。

如果有足够的资金，可以购买更多的服务器，采用集群部署，让服务更加稳定。采用的框架如下:

在该架构中，通过添加Nginx反向代理，利用应用集群解决服务稳定性问题，通过增加应用服务器数量增加服务的并发处理能力，将应用服务、数据库和文件存储分离，避免应用服务和存储争夺资源。但是，当大量数据库被访问和修改时，单机数据库的瓶颈很高。这个问题的解决方案可以通过增加缓存来处理。

在这种架构下，由于Nginx通过ip_hash或者session-sticky解决了会话维护的问题，门户Nginx应用压力很大，部分业务查询无法缓存，查询需要更多的数据库资源，文件存储管理混乱，因此可以进一步调整架构如下。

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