大型web系统架构演进

以一个餐饮系统的演化为例

1.单机系统

应用和数据库部署在一台机器上，此时系统架构如下：

2.应用与数据库分离

访问量增大，应用往往是内存计算。数据库做增删改的时候，是磁盘操作，最容易出现性能问题，导致拖累应用系统的响应速度，此时需要把数据库和应用分离，此时架构如下：

3.数据库读写分离

访问量继续增大，数据库操作往往是读多写少，此时为了环境数据库的压力，可以做数据库的读写分离，此时系统架构如下：

4.缓存高频读数据

访问量继续增大，还是读多写少的场景，数据库做了读写分离，但数据库的读是从磁盘读取数据，效率赶不上内存读取，可以增加内存缓存来提高读请求的性能，此时的系统架构如下：

5.应用负载均衡

访问量继续增大，在数据库读写分离和引入缓存后，单实例应用更容易成为性能瓶颈所在，可以通过部署应用集群，通过负载均衡，缓解应用服务器的压力，此时架构如下：

6.数据库拆分

访问量继续增大，数据库的拆分，可以分成两步：

第一步：按业务分库，不同模块的代码放在一起时，有些模块的访问量大，出现性能问题时，会影响其他木块的访问，此时需要拆分不同的模块，分开部署，通常的步骤是先拆分数据库，再拆分应用，资源足够的时候，也可以同步进行。具体拆分步骤可以参考：先改造原有sql语句中不同模块之间的连接查询------>将不同的表迁移到不同的数据库------>更改应用中不同业务模块的数据库连接信息------>拆分应用，此时的系统架构如下：

第二步：当单业务中的核心表的数据量变的很大的时候，可以考虑引入数据库中间件，把单表的数据进行分库分表拆分，此时需要根据业务慎重选择拆分条件，尽量少的减少跨库查询，以免来自不同库的数据合并影响性能。此时的系统架构如下：

7.应用的拆分

访问量继续增大，需要对应用进行拆分，按业务模块分成不同的集群，此时的系统架构如下：

8.微服务化

访问量继续增大，单个业务模块仍需要继续拆分，且随着服务的增多，服务的治理、监控、限流等都需要全面的提升，可以进行微服务化的改造，此时的系统架构如下：

9.服务网格化(service mesh)

访问量继续增大，微服务架构中，单个服务的代码中需要耦合太多的非业务模块，如需服务的监控、跟踪、限流、降级等通用代码，此时可以进行服务网格化的改造，此时的系统架构如下：