淘宝千万级并发架构的演进之路

说到千万级并发架构，经常会提到淘宝和12306，今天先谈谈淘宝的千万级并发架构演进之路，架构优化的方向以及架构设计的一般原则。

1. 淘宝千万级并发架构的演进之路

初始状态：单机架构

问题：随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务

第一次演进：tomcat与数据库分开部署

问题：随着用户数的增长，并发读写数据库成为瓶颈

第二次演进：引入本地缓存和分布式部署

问题：缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢

第三次演进：引入反向代理实现负载均衡

问题：反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈

第四次演进：数据库读写分离

问题：业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能

第五次演进：数据库按业务分库

问题：随着用户数的增长，单机的写库会逐渐会达到性能瓶颈

第六次演进：把大表拆分成小表

问题：数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈

第七次演进：使用LVS或F5来使多个ngnix负载均衡

问题：由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同

第八次演进：使用DNS轮询实现机房间的负载均衡

问题：随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求

第九次演进：引入nosql数据库和搜索引擎技术

问题：引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难

第十次演进：大应用拆分为小应用

问题：不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级

第十一次演进：复用的功能拆分成微服务

问题：不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱

第十二次演进：引入企业总线ESB屏蔽服务接口的访问差异

问题：业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难

第十三次演进：引入容器化技术实现运行环境隔离和动态服务管理

问题：使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低

第十四次演进：以云平台承载系统

问题：至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案

2. 架构优化的方向

架构优化主要分为垂直和水平两个维度。

系统性能就像木桶，系统的承载能力是以最低的那块木板决定的，可以垂直优化系统性能，但当前系统环境已达到极限，就需要以集群的方式来持续优化。

就像淘宝的架构，数据库按业务分库、大表拆分小表、引入nosql以及ESB都是在垂直维度上演进；分布式部署、负载均衡等都是在水平维度上演进。

垂直优化的常用方法

缓存：以空间换时间

并发：一个人干不完的活，那就找几个人干

惰性：提前处理或推迟处理

批量：批量操作，提高吞吐

更高效的实现：程序员都喜欢造轮子，但使用成熟的、经过验证的轮子往往比自己造的轮子性能更好

缩小解空间：在一个更小的数据范围内进行计算，而不是遍历全部数据

代码质量：衡量代码质量的标准是可读性、可维护性、可扩展性，但性能优化有可能会违背这些特性

水平扩展的常用方法

分布式：系统中的多个模块在不同服务器上部署

集群：一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务

负载均衡：请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载

正向代理：系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问

反向代理：当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器

3. 架构设计的原则

合适原则：合适优于业界领先

真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。选择最适合的才是最好的，而不是直接生搬硬套其他成功案例

简单原则：简单优于复杂

所以架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案，因为复杂的方案必然带有结构复杂性或者逻辑复杂性，从而增加了系统的复杂度，引出其他问题

演化原则：演化优于一步到位

架构设计时应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。

参考文献：https://www.cnblogs.com/ghhjanes/p/11200674.html

欢迎关注【技术型项目经理】公众号。可获取软件行业动态、技术积累和项目管理理念文章分享。可在菜单中选择获取「PMP」、「高项」（信息系统项目管理师）、「CISSP」、「Python」、「GoLang」、「C++」学习资料。