大型网站技术架构演进与性能优化

2018-06-12《大型网站技术架构演进与性能优化》从一名亲历者的角度，阐述了一个网站在业务量飞速发展的过程中所遇到的技术转型等各种问题及解决思路。从技术发展上看，网站经历了Web应用系统从分布式、无线多端、中台到国际化的改造；在解决大流量问题的方向上，涉及了从端的优化到管道到服务端甚至到基础环境优化的各个层面。

《大型网站技术架构演进与性能优化》总结的宝贵经验教训可以帮助读者了解当网站遇到类似问题时，应如何思考不同的解决思路、为什么要这样做、并最终做出合适的方案选择。

2009年加入淘宝，一直关注性能优化领域，经历了淘宝PV从1亿到10亿的发展历程，参与了淘宝高访问量Web系统模板引擎的改造、静态化、无线化、CDN等优化改造项目。先后研究过分布式数据库Cassandra系统、Tomcat、Jetty等系统的源码。一直参与淘宝访问量高的系统页面详情系统的优化工作，设计并实现了sketch模板引擎、MVC框架Feiba等，将服务端性能提升近50%左右；所在的性能优化小组一直在做详情的前端优化，将详情页的首屏展示时间缩短为1s之内。著有技术畅销书《深入分析Java Web技术内幕（修订版）》一书。

罗马不是一天建成的，能够支撑亿级交易量的大型网站也不是一蹴而就的。作者以一名亲历者的身份，阐述了一个大型网站在数年时间内从雏形成长为巨人时所经历的技术选型思考、方案选择，以及遇到的众多性能瓶颈和优化方案。

全书可分成上下两篇。上篇主要介绍整个网站由于业务发展所经历的几次主要的架构演进，包括从PHP 到Java 的改造、分布式改造、无线化改造、中台的改造、国际化改造。下篇主要介绍如何从不同的层次解决整个网站在大流量情况下遇到的性能瓶颈，包括端和管道的优化、应用层代码级优化、应用架构的优化、端到端的全链路优化。最后介绍做架构和性能优化的过程中必须面对的稳定性问题——如何体系化地解决网站的稳定性，是非常关键的。

书中提供的经验教训、优化思路，对于相关从业人员而言，均是宝贵的参考。

从1 亿到50 亿的技术之路

从2009 年到2016 年，笔者非常幸运地经历了网站PV 从1 亿到50 亿的飞速发展历程，在此过程中积累了一些大流量高并发网站架构设计和优化的经验。从技术发展来看，笔者经历了Web 应用系统从分布式、无线多端、中台到国际化的改造；在解决大流量问题的方向上，积累了很多从端的优化到管道到服务端甚至到基础环境优化的经验。现在您手头这本书所介绍的内容，大部分是笔者看到、学到的，是亲身参与和实践的经验。

本书要表达的内容并不是简单罗列所做过的事情，而主要是帮助读者了解当网站遇到类似问题时，应如何思考不同的解决思路、为什么要这样做、如何做出最终的方案选择……其实每种架构的选择必然有它专属的现实场景，因此本书涉及的这些话题也不一定就是最完美的解决方案。但，我希望本书的分享能启发大家在解决类似问题时的思考和判断。

一、架构演进之路

本书分成上下两篇。上篇主要介绍整个网站由于业务发展所经历的几次主要的架构演进，包括：从PHP 到Java 的改造、分布式改造、无线化改造、中台的改造、国际化改造。下篇主要介绍如何从不同的层次解决整个网站在大流量情况下遇到的性能瓶颈，包括端和管道的优化、应用层代码级优化、应用架构的优化、端到端的全链路优化。最后介绍做架构和性能优化的过程中必须面对的稳定性问题——如何体系化地解决网站的稳定性，这是非常关键的。

阶段一 从PHP 到Java

很多网站早期都是基于Linux+Apache+MySQL+PHP 架构的网站，从当时来看，这种非常流行的个人网站架构的确也非常匹配当时的发展状态。PHP 语言的特性是快速发布，从页面渲染到数据库访问，均可以在一个页面里全部搞定。

即使放到今天，这种架构仍然还有很多人在用，它的优点就是非常简单高效，但缺点也非常明显：扩展性和分布式不好，不适合企业级的、复杂业务逻辑的大规模协同开发。

随着网站的发展，大家觉得应该将PHP 切换到Java。为什么要切换到Java 语言呢？一般来说，企业选择开发语言会有如下考虑。

（1）语言本身的特性。每种语言开发出来都有它的特性和所适合的场景，像Python、PHP 这类脚本语言非常适合快速简单的开发方式，而Java 则比较适合构建复杂业务逻辑的企业级开发，但是开发效率会比PHP 要差一点。

（2）程序员队伍。企业选择何种开发语言，还要看市场上的人才队伍是不是足够，是不是有很高层次的人才。是否有高层次的人才，取决于当前的行业老大是不是也在用这种语言，比如当前的顶级互联网公司如果在用Java，那么自然这些公司的Java人才比较多，这样，他们的经验可以被快速复制到其他公司中。

（3）语言所对应的工具生态是否完善。一个语言是否有生命力，要看这个语言对应的生态工具是否完善，它的社区是否活跃。因为我们要用到各种工具，而我们也不可能自己去写每种工具，因此，是否能方便地利用开源工具，快速提升开发效率也是非常关键的。像现在很多大公司开源了很多Java 的中间件产品，这些中间件可以直接拿来使用，就不需要再重新开发了。

综合以上因素，电商网站选择Java 语言作为主要的系统开发语言是非常合适的。

从PHP 切换到Java 后，整个网站采用WebX+EJB+iBatis+JBoss+Oracle（后面又将EJB 改成Spring）的架构，但是随着业务量的不断增大，存储层的瓶颈暴露出来。

为了解决存储问题，就逐渐用上了非常昂贵的IBM 小型机、Oracle 的数据库以及EMC的高端存储（IOE）；并对数据库做了分库的拆分，分布式缓存（Tair）也随之诞生，分布式文件系统TFS 开始出现，CDN 也慢慢建立了。

阶段二 分布式改造

所谓分布式改造，就是尽量让系统无状态化，或者让有状态的信息封装在一定范围内，以免限制应用的横向扩展。简单来说，就是即便某个应用的少数服务器“宕”掉，也不会影响整体业务的稳定性。

要实现应用的分布式改造必须先解决以下几个问题。

（1）把应用微服务化：即将大量粗粒度的应用逻辑拆小，做服务化改造。

（2）必须先建立分布式服务框架。必须具备分布式RPC 框架、异步消息系统、

分布式数据层、分布式文件系统、服务的发现、注册和管理。

（3）必须要解决分布式Session 问题。

为了做业务的服务化改造，我们大量拆分了当时的业务系统，形成了商品中心、交易中心、用户中心、店铺中心。这些服务作为底层服务供上层的前台系统调用，此时的系统架构变成了如图0.1 所示的形式。

现在来看，系统的分布式改造为网站接下来5 年的发展奠定了很好的基础，整个网站的扩展性非常好。几乎每个初创企业都必须经历一次分布式化的改造，才能为企业的长期发展奠定基础。笔者前面提及的几个重要的中间件产品和关键的分布式Session 等技术在《深入分析Java Web 技术内幕（修订版）》一书中有详细的介绍，感兴趣的读者可以自行去学习了解。

阶段三 无线化改造

到了2013 年，无线技术已经非常火爆了。在此之前，无线的业务总是跟着PC 走，基本上是PC 做好后无线再复制一份，而且无线和PC 还不是同一个前台系统，导致一个功能要做两遍，并且无线部门的开发人员本来就不多。这些给业务的发展带来很多问题。因此2013 年底，启动了All in 无线项目，目标就是用一套系统、一套架构快速支撑多端的个性化，并在服务端做了很多模块化和组件化的改造。

随着无线技术的发展，我们也开始尝试一些新技术，最具代表性的就是Node。

Node 在业界很火，前端同学非常推崇，而且它也大幅提升了前端的开发效率和体验。

目前大家也多方尝试使用Node 技术，并且用在一些业务线上。但是，从今天来看，Node 并没有达到我们想象中的发展前景。这其中有多种原因，本书的后续章节会专门介绍网站的无线化改造实践，也将分享Node 在实际使用中的一些思考。

经过无线化改造的应用系统架构如图0.2 所示。

阶段四 中台改造

中台这个概念早期是由美军的作战体系演化而来，技术上的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。书中会有单独的一章介绍笔者看到、学到的中台的实践和思考。

阶段五 国际化

国际化一般会有两种思路：一种是一套原始代码部署到多个地方，各地的系统基本没有什么关联、保持相互独立，每个地方再根据本地实际情况做一些个性化的定制。一般来说，会精简原始代码，减少不必要的依赖。这种思路在一些跨国公司用得比较多，但是这个对技术要求比较低，不是我们介绍的重点。

另一种思路就是我们要介绍的国际化，它主要是解决如何将一套系统部署到多地的问题。一般国际化有两个发展阶段：第一个阶段是在国内实现了交易的单元化；第二个阶段是实现了中美的跨国部署。

国际化的本质仍然是要解决以下的通用问题：多语言问题、多时区问题、数据路由问题、全球数据的同步与复制问题。这些内容我们将在第5 章介绍，提供一些可参考的通用思路。

二、挑战性能瓶颈

从第5 章开始将介绍网站PV 量从1 亿到50 亿的发展过程中应用系统遇到的各种性能瓶颈，以及我们的解决方案。这个过程可大致分为3 个时间段，如图0.3 所示。

第1 个时间段：主要解决网站的易用性和扩展性问题。例如当时提的“去IOE”就是将数据库从Oracle 迁到MySQL 上，通过分库分表来解决扩展性问题，同时做了很多网页端的优化工作，如JavaScript（以下简称JS）的异步加载、首屏优先渲染等。

第2 个时间段：这段时间网站的流量增长非常迅速，每年双11 的流量更是异常疯狂，系统出现了性能瓶颈。记得某次评估双11 的流量，光详情页系统就需要增加上万台服务器，简直无法想象！所以必须考虑用非常规手段来优化性能。这个阶段我们主要通过静态化技术来解决读系统的性能瓶颈，大概用了1~2 年的时间来持续迭代，直到实现了静态化系统改造才算彻底解决了性能问题，使系统能够支持上百万的QPS。

第3 个时间段：由于业务系统的复杂性上升非常快、业务的耦合度比较高，给系统的稳定性带来很大挑战，所以这个阶段进行了系统的稳定性建设，产出了很多稳定性工具和产品，另外性能优化也更朝着架构优化的方向发展。

我们还做了很多提升应用性能和开发效率的工作，从成本的角度来看，可以把这些工作归结为如图0.4 所示的内容。

从端到中间的管道、再到应用层以及基础设施的优化，本书会分成4 章来介绍：

应用层代码优化、应用架构的优化、全链路的优化和基础设施的优化。

最后一章我们会介绍在整个网站飞速发展的同时，如何在进行架构的升级、应对突发的大流量这些极端的情况下，仍能保持整体网站的高可用和稳定性。至于如何做好双11 的稳定性，这些内容已有多次的分享，本章会做一些系统的介绍。

三、组织架构的变迁

如果说技术是生产力，那么组织就决定生产关系了，生产关系要适应生产力的发展。笔者当时所在的团队是业务平台，可以理解成技术大团队中的架构师团队，本身没有具体的业务产品，专注于解决一些横向的、架构上的问题。一般每个重要项目中都会有一名架构师参与，业务平台和业务的关联比较直接紧密。

中间件团队和业务平台相比，则和业务的距离稍微远一点，专注于业务开发过程中偏公共和通用的技术组件。这个团队和业务也相对比较紧密，业务开发中一些通用的技术组件，例如同步远程调用RPC 框架、异步通信消息框架、业务动态配置框架、Web 开发框架、分布式数据层、分布式Session 框架等，都是在业务开发中会用到且需要统一和规范使用的通用组件。

由于业务平台、中间件团队和业务的关系相对紧密，因此团队的组织关系一定要和业务开发捆绑在一起。在早期，这两个团队的Leader 最好也是业务开发团队的Leader，而且这个Leader 要有强力的话语权。否则这两个团队的业务很难落地。架构师和中间件团队可以理解为业务开发中偏精英一点的团队，从长期发展来看，业务开发也有强烈的意愿要往偏技术的方向发展，所以他们的关系不一定是长期稳定的。

当技术团队人员扩张到接近1000 人时，业务平台就慢慢解散了：因为随着技术团队分工越来越细，它的专业度也会越来越深，统一的架构师团队显然已经无法支撑这么多的业务团队了。在这种情况下，业务平台就被拆解分散到各个技术产品团队中，业务平台的Leader 也成为新的技术团队的Leader。该演进过程如图0.5 所示。

在图0.5 中，中间件团队在建立伊始，一定要和业务团队保持紧密关联，同时，一些中间件产品最好是发展得比较完善后，再独立成图0.5 右侧的结构，这会比较好。

如果从一开始，中间件团队就保持了图0.5 右侧的图的结构，在落地时会比较困难。

不过凡事都不是绝对的，人与人之间最大的问题其实就是信任问题。公司内部同事之间的协作最大的问题来自于利益的分配，团队之间合作最和谐的方式就是既有合作又有制约。这其中很多都是出于业务上的考虑。除了上面所介绍的，还有一个在组织结构上对技术影响比较大的事件——中台的提出——我们后面会介绍。

四、工程师文化的形成

在我看来，所谓的工程师文化是指就算没有KPI 的考核，大家仍然还会认为某些事情是应该做的，而某些事情是不应该做的。例如，遇到问题必须追根溯源、敬畏线上的每次变更并力保稳定性、在技术沟通上对事不对人、简单坦诚、做事不给自己也不给别人挖坑等。

笔者感受比较深的是如果一家公司有一个类似双11 这样的集中活动，那么对公司就是一次技术水平的大考，在这种压力下，在技术上要追求极致，工程师文化自然而然地、有默契地形成了。因此，像双11 这种活动能取得大家共识的公共事件可以在很大程度上推动技术的发展。

工程师文化和每个公司目前所处的环境和阶段也是息息相关的。如果一个创业公司每天面临着如何生存的问题，而员工却在考虑技术的设计是否完美，显然不是太现实。在这种情况下，业务开发的效率和稳定性会更重要。不过，长久来看，该还的债终究是要还的，一个好的工程师文化的建立对公司未来的良好发展至关重要。

1 构建大型网站：分布式改造 1

1.1 为什么要做分布式化 1

1.2 典型的分布式架构 2

1.3 分布式配置框架 4

1.4 分布式RPC 框架 6

1.5 分布式消息框架 8

1.6 分布式数据层 11

1.7 分布式文件系统 12

1.8 应用的服务化改造 15

1.9 分布式化遇到的典型问题 16

1.10 分布式消息通道服务的设计 19

1.11 典型的分布式集群设计思路 21

1.12 总结 24

2 无线化：无线时代下的架构演进 26

2.1 无线环境下的新挑战 26

2.2 端的演进 28

2.3 无线链路的优化 32

2.4 服务端的演进 36

2.5 思考：开发语言选择的思考 44

2.5 总结 46

3 大型网站平台化演进：大中台小前台 49

3.1 为什么需要中台 49

3.2 什么是中台 53

3.3 提升中台的效率 55

3.4 中台是否能解决一切问题 64

3.5 总结 65

4 全球化下的网站演进：全球部署方案 66

4.1 国际化的背景 67

4.2 面临的技术挑战 68

4.3 全球部署的目标架构 69

4.4 何为单元化 69

4.5 单元化解决什么问题 70

4.6 单元化数据分片方案 70

4.7 数据路由方案 74

4.8 接入层路由 78

4.9 服务层路由 79

4.10 数据层路由 81

4.10 Sequence ID 的冲突问题 83

4.11 异地多活 84

4.12 多语言问题 85

4.14 多时区问题 86

4.15 全球数据同步与数据路由 89

4.16 通用版与定制版的选择 90

4.17 全球化部署中遇到的坑 91

4.18 总结 92

5 应用程序优化：代码级优化 93

5.1 优化思路 93

5.2 影响性能的关键因素 97

5.3 Java 特性的优化 102

5.4 减少并发冲突 104

5.5 减少序列化 105

5.6 减少字符到字节的转换 105

5.7 使用长连接 106

5.8 总结 106

6 应用架构探索：合并部署 108

6.1 什么是架构 108

6.2 什么是合并部署 110

6.3 能解决什么问题 112

6.4 如何解决 114

6.5 取得的效果 118

6.6 更进一步地做多版本部署 118

6.7 关于高密度部署的思考 121

6.8 总结 122

7 链路优化：大秒系统的极致优化思路 123

7.1 一些数据 123

7.2 热点隔离 124

7.3 动静分离 125

7.4 基于时间分片削峰 133

7.5 数据分层校验 134

7.6 实时热点发现 136

7.7 关键技术优化点 137

7.8 大促热点问题思考 140

7.9 总结 141

8 全局基础设施优化：资源调度优化 142

8.1 什么是资源调度 142

8.2 资源抽象层 144

8.3 物理资源调度 149

8.4 应用层调度 152

8.5 遇到的问题 155

8.6 总结 164

9 网站高可用建设：大型网站的稳定性建设 165

9.1 故障带来的影响 165

9.2 网站的可用性指标 166

9.3 稳定性建设思路 167

9.4 高可用体系化建设 171

9.5 研发人员的转变 180

9.5 稳定性组织保障 182

9.6 疑难问题排查思路 183

9.7 总结 190

附录 给新人成长的几点建议 191

参考资料 197