描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121341359
全书可分成上下两篇。上篇主要介绍整个网站由于业务发展所经历的几次主要的架构演进，包括从PHP 到Java 的改造、分布式改造、无线化改造、中台的改造、国际化改造。下篇主要介绍如何从不同的层次解决整个网站在大流量情况下遇到的性能瓶颈，包括端和管道的优化、应用层代码级优化、应用架构的优化、端到端的全链路优化。*后介绍做架构和性能优化的过程中必须面对的稳定性问题——如何体系化地解决网站的稳定性，是非常关键的。
书中提供的经验教训、优化思路，对于相关从业人员而言，均是独一无二的宝贵参考。
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.6 总结 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.11 Sequence ID的冲突问题 83
4.12 异地多活 84
4.13 多语言问题 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.6 稳定性组织保障 182
9.7 疑难问题排查思路 183
9.8 总结 190
附录 给新人成长的几点建议 191
参考资料 197
从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问题。
为了做业务的服务化改造，我们大量拆分了当时的业务系统，形成了商品中心、交易中心、用户中心、店铺中心。这些服务作为底层服务供上层的前台系统调用。
现在来看，系统的分布式改造为网站接下来5年的发展奠定了很好的基础，整个网站的扩展性非常好。几乎每个初创企业都必须经历一次分布式化的改造，才能为企业的长期发展奠定基础。笔者前面提及的几个重要的中间件产品和关键的分布式Session等技术在《深入分析Java Web技术内幕（修订版）》一书中有详细的介绍，感兴趣的读者可以自行去学习了解。
阶段三 无线化改造
到了2013年，无线技术已经非常火爆了。在此之前，无线的业务总是跟着PC走，基本上是PC做好后无线再复制一份，而且无线和PC还不是同一个前台系统，导致一个功能要做两遍，并且无线部门的开发人员本来就不多。这些给业务的发展带来很多问题。因此2013年底，启动了All in 无线项目，目标就是用一套系统、一套架构快速支撑多端的个性化，并在服务端做了很多模块化和组件化的改造。
随着无线技术的发展，我们也开始尝试一些新技术，代表性的就是Node。 Node在业界很火，前端同学非常推崇，而且它也大幅提升了前端的开发效率和体验。目前大家也多方尝试使用Node技术，并且用在一些业务线上。但是，从今天来看，Node并没有达到我们想象中的发展前景。这其中有多种原因，本书的后续章节会专门介绍网站的无线化改造实践，也将分享Node在实际使用中的一些思考。
阶段四 中台改造
中台这个概念早期是由美军的作战体系演化而来的，技术上的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。书中会有单独的一章介绍笔者看到、学到的中台的实践和思考。
阶段五 国际化
国际化一般会有两种思路：一种是一套原始代码部署到多个地方，各地的系统基本没有什么关联、保持相互独立，每个地方再根据本地实际情况做一些个性化的定制。一般来说，会精简原始代码，减少不必要的依赖。这种思路在一些跨国公司用得比较多，但是这个对技术要求比较低，不是我们介绍的重点。
另一种思路就是我们要介绍的国际化，它主要是解决如何将一套系统部署到多地的问题。一般国际化有两个发展阶段：个阶段是在国内实现了交易的单元化；第二个阶段是实现了中美的跨国部署。
国际化的本质仍然是要解决以下的通用问题：多语言问题、多时区问题、数据路由问题、全球数据的同步与复制问题。这些内容我们将在第5章介绍，提供一些可参考的通用思路。
二、挑战性能瓶颈
从第5章开始将介绍网站PV量从1亿到50亿的发展过程中应用系统遇到的各种性能瓶颈，以及我们的解决方案。这个过程可大致分为3个时间段。
第1个时间段：主要解决网站的易用性和扩展性问题。例如当时提的“去IOE”就是将数据库从Oracle迁到MySQL上，通过分库分表来解决扩展性问题，同时做了很多网页端的优化工作，如JavaScript（以下简称JS）的异步加载、首屏优先渲染等。
第2个时间段：这段时间网站的流量增长非常迅速，每年双11的流量更是异常疯狂，系统出现了性能瓶颈。记得某次评估双11的流量，光详情页系统就需要增加上万台服务器，简直无法想象！所以必须考虑用非常规手段来优化性能。这个阶段我们主要通过静态化技术来解决读系统的性能瓶颈，大概用了1~2年的时间来持续迭代，直到实现了静态化系统改造才算彻底解决了性能问题，使系统能够支持上百万的QPS。
第3个时间段：由于业务系统的复杂性上升非常快、业务的耦合度比较高，给系统的稳定性带来很大挑战，所以这个阶段进行了系统的稳定性建设，产出了很多稳定性工具和产品，另外性能优化也更朝着架构优化的方向发展。
我们还做了很多提升应用性能和开发效率的工作。
从端到中间的管道、再到应用层以及基础设施的优化，本书会分成4项内容章来介绍：应用层代码优化、应用架构的优化、全链路的优化和基础设施的优化。
后一章我们会介绍在整个网站飞速发展的同时，如何在进行架构的升级、应对突发的大流量这些的情况下，仍能保持整体网站的高可用和稳定性。至于如何做好双11的稳定性，这些内容已有多次的分享，本章会做一些系统的介绍。
三、组织架构的变迁
如果说技术是生产力，那么组织就决定了生产关系了，而生产关系要适应生产力的发展。笔者当时所在的团队是业务平台，可以理解成技术大团队中的架构师团队，本身没有具体的业务产品，专注于解决一些横向的、架构上的问题。一般每个重要项目中都会有一名架构师参与，业务平台和业务的关联比较直接、紧密。
中间件团队和业务平台相比，则和业务的距离稍微远一点，专注于业务开发过程中偏公共和通用的技术组件。这个团队和业务也相对比较紧密，业务开发中一些通用的技术组件，例如同步远程调用RPC框架、异步通信消息框架、业务动态配置框架、Web开发框架、分布式数据层、分布式Session框架等，都是在业务开发中会用到且需要统一和规范使用的通用组件。
由于业务平台、中间件团队和业务的关系相对紧密，因此团队的组织关系一定要和业务开发捆绑在一起。在早期，这两个团队的Leader好也是业务开发团队的Leader，而且这个Leader要有强力的话语权。否则这两个团队的业务很难落地。架构师和中间件团队可以理解为业务开发中偏精英一点的团队，从长期发展来看，业务开发也有强烈的意愿要往偏技术的方向发展，所以他们的关系不一定是长期稳定的。
……
君山做事情有几个特点：一是能把技术和业务相结合 ，在处理业务需求和问题时轻车熟路，在处理完业务需求的同时还会带来技术上的创新；二是善于推动技术创新落地，用自己的实践诠释了“创新只有被人使用、在业界形成潮流才算是真正的创新”这句话；三是善于总结思考，他每次都把技术和业务上遇到的问题和解法总结下来，并乐于分享，让团队共同成长！
——阿里巴巴研究员 小邪
做技术做到后期才会发现写代码并不是全部。随着业务的快速迭代，对系统的架构演进和相关技术的权衡会变得越来越重，在不同的阶段会有不同的取舍。特别是大型系统，除了要考虑技术，还要考虑相匹配的组织架构、工程文化等因素——这些挑战是很难通过亲历来获取的，毕竟成功的大型系统不算太多。
作者曾是淘宝网一线的技术专家，亲身经历了淘宝网业务飞速增长的过程，并将其中的经验和学习的过程记录下来，完整地为我们展现了一个初级系统在演化成一个全球、分布式的系统的过程中，从语言选择、分布式框架改造、平台化演进、系统优化到稳定性建设等关键过程的思考，内容翔实可信。从这些*实践中，技术点也许并不是*重要的，读者可收获多维度的启发和共鸣，推荐阅读！
——阿里云研究员 禇霸
一家伟大的互联网企业一般都离不开高超技术的支撑，而高超技术的养成又离不开每天迎面而来的各种挑战。本书作者有幸经历了淘宝网这些年的技术巨变，碰到了无数的问题，积攒了很多并发架构设计和性能优化的经验。好的架构是一个系统的根本，好的性能是一个系统稳定运行的保证，本书应该可以给大家带来不一样的收获。
——PerfMa CEO 你假笨（寒泉子）
针对C端用户的互联网业务是爆发式的、井喷式的，其带来的用户流量压力和对计算能力的要求也是非常惊人的，如何利用廉价的架构设计来部署分布式服务以应对亿级流量的场景是个非常严峻的问题。《大型网站技术架构演进与性能优化》一书讲解了高可用架构演化的进程，并提供了互联网架构性能优化的方法。正所谓互联网技术唯“快”而不破——解决了性能问题，其他问题也就迎刃而解。如果你的业务正处于流量并发暴增与系统架构变革的十字路口，那么本书恰好就是你的菜。这是一本关于互联网高并发架构设计的优秀书籍，它从各角度剖析系统设计的演化与优化，循序渐进地将一系列复杂问题阐述得清晰、简单、易懂，是一本理论与实践相结合的实用书籍。
——《分布式服务架构：原理、设计与实战》、《可伸缩服务架构：框架与中间件》作者 李艳鹏
对于一个高并发大流量网站的架构师而言，你的系统到底能够承受多高的并发、多大的流量，只有在你的系统经历了更高的并发、更大的流量以后才能知道。事前再多的设计、评审、测试、预演也只能让你相信，而不能让你知道。淘宝网作为全球*的电子商务网站，每年的双十一都会承受这个星球上可能是*的并发访问压力，那么淘宝的技术人员遇到了哪些挑战？做了哪些工作？感谢这本《大型网站技术架构演进与性能优化》，让我们一窥究竟。
——《大型网站技术架构：核心原理与案例分析》作者 李智慧
君山老师曾多次出席技术大会SDCC担任讲师及出品人，为技术总监、架构师等参会者带去了很多干货实料的分享。实践出真知，任何脱离实际工作的讨论无疑在浪费宝贵的时间成本，作者在淘宝网经历了Web应用系统从分布式、无线多端、中台以及到国际化的改造；在解决大流量问题的方向上，积累了很多从端的优化到管道到服务端甚至到基础环境优化的经验，这些助力他真正成为我们技术社区的明星专家，相信此书肯定会给广大的技术开发者带去*为一线的知识和成长。
——CSDN主编 钱曙光
评论
还没有评论。