系统架构升级之道，关注关键服务依赖

【数据库】

一个典型的互联网应用，前端服务器可以利用负载均衡服务，组成一个集群，但是只有一个mysql主库，这时候，mysql服务就是系统中依赖的关键服务。

关键服务的性能和波动将成为整个系统的性能瓶颈和主要问题源。

为了减轻只有一个mysql主库的依赖，我们引入了一主多从的架构，让更多从库也来提供查询服务，减轻主库的查询依赖。

这样升级改造后，系统的性能和稳定性还是有明显的提升，但是mysql查询的复杂度和数量增加后，mysql的性能瓶颈依然会很突出。

【缓存层】

于是，继续升级，引入redis或者memcache，将大量的结果缓存起来，把应用尽量从mysql隔离，减少对数据库的依赖。

这时候，我们会欣喜的发现，应用的性能比之前完全依赖mysql的时候要强好多，稳定性也响应的提高很多。

随着我们的系统越来越复杂，访问量越来越大，缓存层的压力也会越来越大。

一方面是内存不足的问题，另一方面数据更新更复杂，还有就是访问压力以及内网带宽的瓶颈也增加了。

这时候又要开始对缓存层继续升级改造了，于是分布式缓存集群也就出现了。

通过一致性hash算法或者简单的散列方法，都可以很容易的增加redis/memcache服务来构建更大规模的集群。

这样一来，随着服务器增加，单机的内存瓶颈减轻了，访问压力以及带宽压力也降低了，但是数据更新的问题依然存在。

数据更新的问题，就是数据不一致的问题，本质上就是因为一个数据的多次写入，中间出现异常的话，就导致出现不一致了。

关于数据一致性问题，我们后面再来详细分析和讲解。

随着缓存层集群的构建，整个系统架构就变成了多前端服务器，多缓存服务器，一个主库，多个从库。

主库主要承载数据写入的负载，在大部分的互联网应用中，写入的数量相对还是少很多的，所以大部分时候，这样的架构也就可以安枕无忧啦。

【更大规模】

我们的追求不仅是眼前的苟且，还有更强大的系统和更多的用户。

当我们的应用，用户数、访问量过千万之后，以前的架构还是会遇到越来越多的挑战。

这里面，可能数据库还是会第一个出现瓶颈，毕竟一个主库，再强大也是没法做到一秒钟数万次的更新，哪怕只是小小的点击数的增加。

这时候，就要开始考虑对数据库做分拆了，把一个数据库分拆为好几个数据库（分表分库）。

而分拆的方式，大家应该能想到的，比如：水平分拆和垂直分拆。

【水平分拆】

典型的水平分拆就是对数据做归档，按照日期（每年归档），把旧的数据迁移到归档库里面，访问量少，也不会有写入的压力。

水平分拆对整个系统的改造和变化相对来说是影响比较小的，毕竟数据结构没有变化，只是数据源增加了。

而这种分拆带来的明显效果就是，数据规模减少，数据库的读写性能都会有明显的提升，当然对整个应用的性能和稳定性都会有很大提高。

【垂直分拆】

如果只是对数据库做垂直分拆，只是把一部分数据表迁移到其他独立数据库中，比如：把用户相关的信息表迁移到用户库，把商品相关的产品表迁移到商品库，那这个分拆也不算难。

但是，往往伴随着系统规模的变大，应用的复杂度也会不断提高。

所以，这个时候垂直分拆，很可能会同时进行应用的分拆。

比如：把用户的登录注册、信息维护单独部署和维护，把商品信息的管理和维护单独部署。

这时候，应用也就同时进行了垂直分拆，即：把大的应用进行组件化、服务化。

【微服务】

到这个阶段，大家应该就开始感觉大一个系统的复杂了吧。

一开始说好的做一个互联网应用，而现在却出来了很多个应用和服务，他们之间又有很多关联，组成一个大型的系统。

这时候，系统中的关键服务依赖已经不仅仅是缓存层、数据库服务，而变成了一个个拆分之后的应用、微服务了。

这时候，系统的性能和稳定性就完全依赖各个微服务的性能和稳定性了。

如果，再把每个微服务按照上面的架构升级路线演练一遍，貌似又不那么困难。

但是，全部组合在一起，新的难点已经是对这些服务的监控、运维、故障排除等治理工作。

【畅想未来】

那么，系统继续升级的话，我想，可能就是自动化运维的工作会更多了吧。

一两个数据库宕机不用怕，主从自动切换，数据库集群秒级自动恢复。

几个缓存服务器网络不稳定也没关系，有备份的缓存可以先用着。

微服务的一些服务器不稳定，服务自动降级，并且在微服务稳定后自动恢复以及同步数据。

甚至一个机房断网、断电了，其他机房依然正常的提供全面的服务，不影响用户使用。

【总结】

关键服务依赖总是最重要的环节，也是最容易出问题的地方。

系统架构升级，正是对这些关键依赖的瓶颈进行针对性优化升级和改造。

应用从小变大，再分拆变小，从一个应用到很多个微服务，这些都是技术不断变革的过程。

规模化带来了带来了的总体容量和总体性能的提高，同时也带来了关于服务治理的新挑战。

那么，是不是开发系统都要用这么复杂的架构呢？

其实不是，上面的架构升级过程，其实是对线上问题不断发现和解决的过程，也是一个不得已的过程。如果一个系统的用户量、业务量不大，一开始就复用一套庞大的系统架构，那真的就费时费力，累死自己，完全没必要。所以，合适就好。

在实战课程 《PHP秒杀系统 高并发高性能的极致挑战》中，也是针对这类高并发的业务场景做了特定的性能优化以及分布式方案，大家可以参考学习。