淘宝旧版本(淘宝旧版本2021)

最近写了一篇关于高并发的文章，发现了一篇关于高并发架构演进的好文章，收获颇丰，所以分享给大家。相信你看完一定会有所收获。

1. 概述

以淘宝为例，介绍了一亿到千万级并发情况下服务器架构的演进过程，并列举了每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的了解。最后，总结了建筑设计的一些原则。

特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径2. 基本概念

在介绍架构之前，为了避免一些读者不了解架构设计中的一些概念，下面是一些基本概念:

分布式的

系统中的几个模块部署在不同的服务器上，可以称为分布式系统。比如Tomcat和数据库部署在不同的服务器上，或者两个功能相同的Tomcat部署在不同的服务器上。

高可用性

当系统中的某些节点出现故障时，其他节点可以接管并继续提供服务，因此可以认为系统具有高可用性。

组

特定领域的软件部署在多个服务器上，整体提供一类服务，称为集群。比如Zookeeper中的主从部署在多台服务器上，形成一个整体，提供集中配置服务。在普通集群中，客户端总是可以连接到任意一个节点获得服务，当集群中的一个节点掉线时，其他节点可以自动接替它继续提供服务，这表明集群具有高可用性。

负载均衡

当请求发送到系统时，可以认为系统是负载均衡的，通过某种方式将请求平均分配到多个节点，使系统中的每个节点都能平均处理请求负载。

正向代理系统和反向代理系统想要访问外网时，都是通过一个代理服务器转发请求，也就是外网的代理服务器发起的访问。此时，代理服务器实现前转代理。当外部请求进入系统时，代理服务器将请求转发给系统中的服务器。对于外部请求，只有代理服务器与之交互。此时代理服务器实现反向代理。简单来说，正向代理就是代理服务器访问外部网络而不是内部系统的过程，反向代理就是外部访问系统的请求通过代理服务器转发到内部服务器的过程。

3. 架构演进3.1 单机架构以淘宝为例。网站初期，应用程序和用户数量都很少，所以Tomcat和数据库可以部署在同一个服务器上。当浏览器向www.taobao.com发出请求时，首先通过DNS服务器(域名系统)将域名转换成实际的IP地址10.102.4.1，然后浏览器访问该IP对应的Tomcat。

随着用户数的增长，Tomcat和数据库之间竞争资源，单机性能不足以支撑业务3.2 第一次演进：Tomcat与数据库分开部署Tomcat和database分别独占服务器资源，显著提升了各自的性能。

随着用户数的增长，并发读写数据库成为瓶颈3.3 第二次演进：引入本地缓存和分布式缓存在Tomcat的同一服务器或JVM上添加本地缓存，对外添加分布式缓存，缓存热门商品信息或热门商品的html页面等。通过缓存，可以在读写数据库之前拦截大部分请求，大大减轻了数据库压力。

涉及的技术包括:使用memcached作为本地缓存，Redis作为分布式缓存，还涉及到一些缓存一致性、缓存穿透/击穿、缓存雪崩、热数据集中失败等问题。

缓存抗住了大部分的访问请求，随着用户数的增长，并发压力主要落在单机的Tomcat上，响应逐渐变慢3.4 第三次演进：引入反向代理实现负载均衡在多台服务器上部署Tomcat，使用反向代理软件(Nginx)将请求平均分配给每台Tomcat。这里假设Tomcat最多可以支持100个并发，Nginx最多可以支持50000个并发，那么理论上Nginx可以通过将请求分发到500个Tomcat来抵抗50000个并发。

涉及的技术有:Nginx和HAProxy，都是工作在网络第七层的反向代理软件。它们主要支持http协议，还涉及会话共享、文件上传和下载。

反向代理使应用服务器可支持的并发量大大增加，但并发量的增长也意味着更多请求穿透到数据库，单机的数据库最终成为瓶颈3.5 第四次演进：数据库读写分离数据库分为读数据库和写数据库。可以有多个读数据库，写数据库的数据通过同步机制同步到读数据库。对于需要查询最新写入数据的场景，可以在缓存中多写一个副本，通过缓存获取最新数据。

涉及的技术包括:Mycat，这是一个数据库中间件。它可以用来组织数据库的分离、读取和写入，以及将数据库分成表。客户端可以通过它访问下层数据库，还会涉及到数据同步和数据一致性。

业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能3.6 第五次演进：数据库按业务分库将不同服务的数据保存在不同的数据库中，从而减少服务之间的资源竞争。对于大流量的服务，可以部署更多的服务器来支持它们。同时跨业务表不能直接做关联分析，需要通过其他途径解决，但这不是本文的重点。有兴趣的可以自行搜索解决方案。

随着用户数的增长，单机的写库会逐渐会达到性能瓶颈3.7 第六次演进：把大表拆分为小表比如评论数据可以根据商品ID哈希，路由到对应的表中存储；对于支付记录，可以按小时创建表，每个小时表可以连续拆分成小表，可以使用用户ID或记录号路由数据。只要实时操作中的表数据量足够小，并且请求可以均匀分布到多台服务器上的小表上，就可以通过横向扩展来提高数据库的性能。前面提到的Mycat也支持将大表拆分成小表时的访问控制。

这种方式明显增加了数据库运维的难度，对DBA的要求更高。当数据库采用这种结构设计时，已经可以称之为分布式数据库，但它只是一个逻辑完整的数据库。数据库中不同的组件由不同的组件实现，如子数据库和子表的管理由Mycat实现，SQL的分析由一个独立的数据库实现，读写分离可由网关和消息队列实现，查询结果汇总可由数据库接口层实现等。这个架构其实就是MPP(海量并行处理)架构。

目前，开源和商用的MPP数据库很多，其中有Greenplum、TiDB、Postgresql XC、HAWQ等。比较流行，还有商用的如NTU的GBase，樊蕊科技的雪球DB，华为的LibrA等。

不同的MPP数据库侧重点不同。例如，TiDB更侧重于分布式OLTP情形，而Greenplum更侧重于分布式OLAP情形。这些MPP数据库基本上都提供了类似Postgresql、Oracle、MySQL这样的SQL标准支持能力，可以将一个查询解析成分布式执行计划，分发到每台机器上并行执行。最后返回数据库本身收集的数据，还提供权限管理、数据库子表、事务、数据复制等能力。，而且大部分都可以支持100个节点以上的集群，大大降低了数据库的运维成本，使数据库能够实现横向扩展。

数据库和Tomcat都能够水平扩展，可支撑的并发大幅提高，随着用户数的增长，最终单机的Nginx会成为瓶颈3.8 第七次演进：使用LVS或F5来使多个Nginx负载均衡因为瓶颈是Nginx，所以无法通过两层Nginx实现多个Nginx的负载均衡。图中的LVS和F5是工作在网络第四层的负载均衡解决方案，其中LVS是软件，运行在操作系统的内核状态，可以转发TCP请求或者更高层的网络协议，所以支持的协议更加丰富，性能远高于Nginx。可以假设单个LVS可以支持几十万个并发请求转发；F5是一种负载均衡硬件，类似于LVS提供的产品。它的性能比LVS的高，但价格昂贵。

由于LVS是一个单机软件，如果LVS所在的服务器宕机，整个后端系统将无法访问，因此需要有一个备用节点。

虚拟IP可以通过keepalived软件模拟，然后虚拟IP可以绑定到多个LVS服务器。当浏览器访问虚拟IP时，会被路由器重定向到真实的LVS服务器。当主LVS服务器宕机时，keepalived软件会自动更新路由器中的路由表，将虚拟IP重定向到另一台正常的LVS服务器，从而达到LVS服务器高可用的效果。

这里需要注意的是，上图中Nginx层到Tomcat层的绘制并不意味着所有Nginx都向所有Tomcat转发请求。在实际使用中，可能是几个Nginx以下的Tomcats的一部分，这些Nginx通过keepalived高可用，其他Nginx连接到其他Tomcats，这样可以访问的Tomcats数量可以翻倍。

由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同3.9 第八次演进：通过DNS轮询实现机房间的负载均衡可以在DNS服务器中配置一个域名对应多个IP地址，每个IP地址对应一个不同机房的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略来选择一个IP供用户访问。

该方法可以实现机房的负载均衡。至此，系统可以在机房级水平扩展，通过增加机房可以解决几千万到几亿的并发。系统入口处的请求并发性不再是问题。

随着数据的丰富程度和业务的发展，检索、分析等需求越来越丰富，单单依靠数据库无法解决如此丰富的需求3.10 第九次演进：引入NoSQL数据库和搜索引擎等技术当数据库中的数据达到一定规模时，数据库就不适合复杂的查询，只能满足一般的查询场景。对于统计报表场景，当数据量较大时，结果可能无法用完，运行复杂查询时，其他查询会变慢。对于全文检索、可变数据结构等场景，数据库本来就不适合。因此，有必要针对具体的场景推出合适的解决方案。

比如，海量文件存储可以通过分布式文件系统HDFS解决；对于关键值数据，可以用HBase和Redis解决；对于全文检索场景，可以通过ElasticSearch等搜索引擎解决；对于多维分析场景，可以用麒麟或者德鲁伊解决。

当然，更多组件的引入也会增加系统的复杂性。不同组件存储的数据需要同步，需要考虑一致性，需要更多的运维手段来管理这些组件。

引入更多组件解决了丰富的需求，业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难3.11 第十次演进：大应用拆分为小应用应用代码按照业务板块划分，让各个应用的职责更加清晰，可以独立升级迭代。这时候应用之间可能会涉及到一些常见的配置，可以通过分布式配置中心Zookeeper来解决。

不同应用之间存在共用的模块，由应用单独管理会导致相同代码存在多份，导致公共功能升级时全部应用代码都要跟着升级3.12 第十一次演进：复用的功能抽离成微服务比如用户管理、订购、支付、认证等功能。存在于多个应用程序中，那么这些功能的代码可以单独提取出来，形成一个单一的服务来管理。这样的服务叫微服务。应用程序和服务通过HTTP、TCP或RPC请求访问公共服务，每个服务都可以由一个团队管理。

此外，还可以通过Dubbo、SpringCloud等框架实现服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。

不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱3.13 第十二次演进：引入企业服务总线ESB屏蔽服务接口的访问差异通过ESB统一访问协议转换，应用通过ESB访问后端服务，服务与服务通过ESB相互调用，降低系统的耦合度。这种将单个应用拆分为多个应用，公共服务单独提取和管理，利用企业消息总线解决服务间耦合问题的架构，被称为SOA (Service Oriented)架构，很容易与微服务架构混淆，因为其表现形式非常相似。

个人认为，微服务架构是指将公共服务从系统中提取出来，分别管理的思想，而SOA架构是指将服务拆分，使服务接口访问统一的一种架构思想。SOA架构包含了微服务的思想。

业务不断发展，应用和服务都会不断变多，应用和服务的部署变得复杂，同一台服务器上部署多个服务还要解决运行环境冲突的问题，此外，对于如大促这类需要动态扩缩容的场景，需要水平扩展服务的性能，就需要在新增的服务上准备运行环境，部署服务等，运维将变得十分困难3.14 第十三次演进：引入容器化技术实现运行环境隔离与动态服务管理目前最流行的容器化技术是Docker，最流行的容器管理服务是Kubernetes(K8S)。应用/服务可以打包成Docker镜像，镜像可以通过K8S动态分发部署。Docker镜像可以理解为可以运行你的应用/服务的最小操作系统，应用/服务的运行代码放在里面，根据实际需要设置运行环境。

在将整个“操作系统”打包成映像后，可以将它分发给需要部署相关服务的机器。您可以直接启动Docker映像来启动服务，这使得服务的部署和运维变得简单。

在大促之前，可以在现有的机器集群上划分服务器来启动Docker镜像，这样可以增强服务的性能。大促之后可以关闭镜像，不会影响机器上的其他服务。(在3.14节之前，运行在新增机器上的服务的系统配置需要修改以适应该服务，这将导致机器上其他服务所需的运行环境被破坏)。

使用容器化技术后服务动态扩缩容问题得以解决，但是机器还是需要公司自身来管理，在非大促的时候，还是需要闲置着大量的机器资源来应对大促，机器自身成本和运维成本都极高，资源利用率低3.15 第十四次演进：以云平台承载系统系统可以部署到公有云，利用公有云的海量机器资源解决动态硬件资源问题。大促期间可以在云平台临时应用更多资源，结合Docker和K8S快速部署服务。大促之后可以释放资源，真正做到按需付费。资源利用率大大提高，同时运维成本大大降低。

所谓云平台，就是通过统一的资源管理，将海量的机器资源抽象成一个整体资源，在这个整体资源上，硬件资源(如CPU、内存、网络等。)可以动态应用，以及在其上通用的操作系统，常用的技术组件(如Hadoop技术栈，MPP数据库等。)可以提供给用户使用，甚至可以提供开发的应用。用户可以解决自己的需求(如音视频等。)而与应用中使用的技术没有任何关系。

云平台将涉及以下概念:

IaaS:基础设施即服务。与上述机器资源整体统一相对应，硬件资源的级别可以动态应用；

平台即服务。与上述相对应，提供通用的技术组件，方便系统的开发和维护；

SaaS:软件即服务。对应上述提供开发的应用或服务，按功能或性能需求付费。

至此，以上所提到的从高并发访问问题，到服务的架构和系统实施的层面都有了各自的解决方案，但同时也应该意识到，在上面的介绍中，其实是有意忽略了诸如跨机房数据同步、分布式事务实现等等的实际问题，这些问题以后有机会再拿出来单独讨论4. 架构设计总结

有必要按照上述演进路径调整架构吗？不，上面提到的架构演进序列只是一个方面的单一改进。在实际场景中，可能同时有几个问题需要解决，也可能另一个方面先到达瓶颈。这时候就要根据实际问题来解决。比如政务类的并发可能不大，但是业务可能比较丰富的场景，高并发不是要解决的关键问题，这个时候可能优先考虑需求丰富的解决方案。

对于要实现的系统，架构应该设计到什么程度？

对于性能指标明确的单次实现系统，架构设计能够支持系统的性能指标要求就足够了，但要预留扩展架构的接口，以备不时之需。对于不断发展的系统，如电子商务平台，应设计满足下一阶段用户和性能指标的要求，并根据业务的增长迭代升级架构，以支持更高的并发和更丰富的业务。

服务器端架构和大数据架构有什么区别？

所谓“大数据”，其实是海量数据采集、清洗转换、数据存储、数据分析、数据服务等场景解决方案的总称。每个场景都包含多种可选技术，如Flume、Sqoop、Kettle等。对于数据收集，HDFS、FastDFS、NoSQL数据库HBase、MongoDB等。用于数据存储，以及用于数据分析的Spark技术栈和机器学习算法等。

一般来说，大数据架构是根据业务需求整合各类大数据组件的架构，一般提供分布式存储、分布式计算、多维分析、数据仓库、机器学习算法等能力。服务器端架构更多的是指应用组织层面的架构，底层能力往往由大数据架构提供。

建筑设计有什么原则吗？

N+1设计。系统中的每个组件都不应有单点故障；

回滚设计。保证系统可以向前兼容，系统升级时应该有回滚版本的方法；

禁用设计。应提供配置，控制特定功能是否可用，系统故障时功能可快速离线；

监控设计。在设计阶段应考虑监控手段；

多数据中心设计。如果系统需要极高的可用性，应考虑在多个数据中心实现多个活动，至少在一个机房断电的情况下，系统仍能可用；

采用成熟的技术。新开发或开源的技术往往隐藏着很多bug，如果没有商业支持，出了问题可能就是一场灾难；

资源隔离设计。避免单一业务占用所有资源；

该架构应该是水平可伸缩的。只有系统可以横向扩展，才能有效避免瓶颈问题；

如果没有，就买。如果非核心功能需要占用大量R&D资源才能解决，可以考虑采购成熟产品；

使用商业硬件。商用硬件可以有效降低硬件故障的概率；

快速迭代。系统要快速开发小功能模块，尽早上线验证，及早发现问题，大大降低系统交付风险；

无状态设计。服务应该是无状态的，当前接口的访问不依赖于接口上次访问的状态。

作者:华世欧

https://segmentfault.com/a/1190000018626163