电子工业出版社-网上书店

一个好的架构就像一个好的制度，我们不会时时刻刻感受到它的存在，但在关键时刻，它决定了系统能够到达的高度。本书浓缩了携程公司的整个技术架构，可以帮助读者了解支撑一家大型企业所需要的核心技术产品，以及它们的架构和面临的挑战。本书由携程的一线研发工程师们精心编写，他们对携程各个领域的技术实践了如指掌，本书所提到的各种系统离不开他们的耕耘。在给读者呈现携程架构实践的同时，也希望本书能给读者带来一些警示和启发，共同推动技术的进步。不同领域的架构关注点各有侧重，但是方法论是相通的。希望读者通过本书了解携程的架构实践，拓宽视野，丰富自己的架构工具箱，在遇到难题时，看看其他领域的解决思路，就可能碰撞出意想不到的“火花”。

第1 章 携程整体技术架构 001
1.1 携程技术架构概览 003
1.1.1 分层架构 003
1.1.2 接入层技术 005
1.1.3 后端技术 006
1.1.4 技术保障 007
1.2 携程整体技术架构演进 008
1.2.1 呼叫中心时代 009
1.2.2 互联网和移动互联网时代 009
1.2.3 大数据和人工智能时代 011

第2 章 移动大前端 013
2.1 CRN 框架 014
2.1.1 背景介绍 014
2.1.2 框架设计 015
2.1.3 性能优化 016
2.1.4 配套支撑系统建设 019
2.2 Web 框架 021
2.2.1 微信小程序应用框架CWX 021
2.2.2 CRN 浏览器端运行框架CRN-Web 024
2.2.3 下一代前端框架解决方案 NFES 027
2.3 插件化 033
2.3.1 插件化的来源 033
2.3.2 方案的实现 034
2.4 Node.js 038
2.4.1 应用场景 038
2.4.2 应用部署 039
2.4.3 运维与监控 040
2.4.4 公共服务 044
2.5 移动发布平台MCD 045
2.5.1 平台服务架构 045
2.5.2 生命周期管理 046
2.5.3 开发流程管理 048
2.5.4 发布流程管理 049
2.6 用户行为监测UBT 050
2.6.1 数据采集 050
2.6.2 传输与存储 052
2.6.3 实时分析 054
2.7 CData 055
2.7.1 性能管理 055
2.7.2 错误统计 056
2.7.3 访问量统计 057
2.7.4 排障支持 057
2.8 本章小结 058

第3 章 用户接入 059
3.1 GSLB 技术 059
3.1.1 GSLB 系统概述 060
3.1.2 DNS 工作方式 060
3.1.3 GSLB 工作原理 061
3.2 CDN 063
3.2.1 CDN 静态加速 064
3.2.2 CDN 动态加速 065
3.2.3 CDN 动态域名切换 066
3.3 App 端接入 066
3.4 负载均衡 067
3.4.1 负载均衡器工作原理 068
3.4.2 负载均衡优化手段 070
3.4.3 负载均衡算法 074
3.4.4 负载均衡会话保持 076
3.5 软负载系统SLB 077
3.5.1 SLB 的产生背景 077
3.5.2 SLB 的架构设计 078
3.5.3 SLB 实现的几个难点 083
3.6 API Gateway 086
3.6.1 API Gateway 的架构设计 087
3.6.2 API Gateway 在携程的使用 091
3.7 本章小结 092

第4 章 呼叫中心 093
4.1 软交换系统SoftPBX 095
4.1.1 携程软交换系统现状 095
4.1.2 软交换架构与信令路径 095
4.1.3 组件规划与分布 096
4.1.4 应用场景 099
4.2 交互式语音应答系统SoftIVR 101
4.2.1 什么是交互式语音应答 101
4.2.2 SoftIVR 架构与特点 101
4.2.3 信令传输流程与核心组件 104
4.2.4 应用场景 108
4.3 全渠道客服云系统 109
4.3.1 全渠道客服云系统的意义 109
4.3.2 客服云整体架构 111
4.3.3 服务端架构 112
4.3.4 应用场景 115
4.4 本章小结 117

第5 章 框架中间件 118
5.1 服务化 120
5.1.1 为什么需要服务化中间件框架 120
5.1.2 服务化中间件框架的基本架构 121
5.1.3 服务注册中心设计解析 122
5.1.4 服务治理系统功能解析 125
5.2 消息队列 128
5.2.1 消息队列的特性与使用场景 128
5.2.2 主流消息队列 129
5.2.3 携程消息队列QMQ 132
5.3 配置中心 137
5.3.1 为什么需要配置中心 137
5.3.2 配置中心的特性 138
5.3.3 Apollo 源码部分解析 139
5.3.4 配置中心面临的新挑战 141
5.4 数据访问 142
5.4.1 数据访问层概述 142
5.4.2 为什么要引入数据访问中间件 143
5.4.3 数据访问中间件的主流方案 144
5.4.4 携程数据访问中间件功能解析 146
5.5 缓存层 150
5.5.1 总体架构 150
5.5.2 分片和路由 151
5.5.3 高可用 153
5.5.4 水平拆分 154
5.5.5 跨机房容灾 156
5.5.6 跨区域同步 159
5.5.7 双向同步 163
5.6 本章小结 167

第6 章 数据库 168
6.1 上传发布 171
6.1.1 表结构设计规范 172
6.1.2 数据库表结构的发布 172
6.1.3 SQL Server 的特殊之处 173
6.2 监控告警 176
6.2.1 数据库大盘监控 176
6.2.2 运维数据库OPDB 178
6.2.3 语句监控 179
6.3 数据库高可用 187
6.3.1 SQL Server 高可用 188
6.3.2 MySQL 高可用 189
6.3.3 Redis 高可用架构 193
6.4 本章小结 194

第7 章 IaaS ＆ PaaS 195
7.1 网络架构演进 198
7.1.1 基于 VLAN 的二层网络 198
7.1.2 基于VXLAN 的大二层SDN 网络 200
7.1.3 基于BGP 的三层SDN 网络 203
7.2 K8s 和容器化的实践 207
7.2.1 部署架构 207
7.2.2 网络 208
7.2.3 调度 209
7.2.4 存储 212
7.2.5 监控 214
7.2.6 容器化 215
7.3 混合云 217
7.3.1 混合云整体设计 218
7.3.2 混合云网络＆ 安全 220
7.3.3 混合云计费＆ 对账 222
7.3.4 混合云运维 224
7.4 持续交付 226
7.4.1 发布的艺术 226
7.4.2 Tars 系统设计 229
7.5 本章小结 232

第8 章 监控 233
8.1 指标监控和告警系统Hickwall 234
8.1.1 指标监控的应用和挑战 235
8.1.2 指标模型的选择 236
8.1.3 Hickwall 架构 238
8.2 开源分布式应用监控系统CAT 241
8.2.1 为什么需要应用监控系统 241
8.2.2 应用监控系统的特点 243
8.2.3 客户端实现解析 245
8.2.4 存储模型解析 247
8.3 公共日志服务平台CLog 250
8.3.1 日志系统的演进与特点 251
8.3.2 CLog 的架构 252
8.4 告警系统 257
8.4.1 告警系统的需求特点 258
8.4.2 流式告警的实现和处理 259
8.5 本章小结 263

第9 章 网站高可用 264
9.1 可用性指标与度量 265
9.1.1 Ctrip ATP 266
9.1.2 Ctrip ATP 算法 266
9.1.3 Ctrip ATP 架构 267
9.1.4 订单预测模型 268
9.2 服务熔断、限流与降级 270
9.2.1 微服务架构下的可用性 271
9.2.2 熔断、限流在携程的落地 272
9.2.3 熔断、限流的治理问题 274
9.3 灾备数据中心 276
9.3.1 冷备模式 277
9.3.2 热备模式 278
9.3.3 多活模式 278
9.4 网站单元化部署 281
9.4.1 单元化架构 282
9.4.2 单元化思路 283
9.5 基础组件支持 285
9.5.1 路由调度 285
9.5.2 数据复制 287
9.6 全链路压测 292
9.6.1 技术选型与系统设计 292
9.6.2 构造与隔离压测数据 295
9.6.3 全链路监控设计 295
9.7 运维工具高可用 296
9.7.1 哪些运维工具需要实现高可用 296
9.7.2 工具的改造 297
9.7.3 定期故障演练 300
9.8 混沌工程 300
9.8.1 混沌工程的起源 301
9.8.2 混沌工程的5 条原则 301
9.8.3 如何进行一个混沌实验 304
9.9 数据驱动运营 307
9.9.1 智能运维AIOps 308
9.9.2 AI 算法在运维领域的典型场景 309
9.9.3 运维数据仓库 312
9.10 GNOC 314
9.11 本章小结 319

序言
当今IT 技术的发展越来越快，更新换代可谓日新月异，让从业者们应接不暇。然而，无论技术如何变化和发展，有些恒久而弥新的知识和能力，依然可以稳定地沉淀下来，它们跨越了不同的开发语言、不同的运行平台，始终是我们关注的焦点。架构，在每年的技术大会上都是热门的话题。架构的关键设计在很大程度上决定了一个系统的非功能属性，如可用性、可扩展性和可维护性等。这也是我们如此重视架构的原因，一个好的架构就像一个好的制度，我们虽然不会时时刻刻感受到它的存在，但在关键时刻，它决定了系统能够到达的高度。
现实的系统往往很复杂，很难表述，它包含了太多的细枝末节，以及未来的不断变化。但优雅而简洁的架构设计能在很大程度上将系统的精髓剥离和抽象出来，化繁为简，以不变应万变。无论什么时候，衡量一个系统的架构设计是否优秀的标准都是高可用、高性能、低成本和高扩展性，例如：在遇到各种突发网络状况，甚至单个机房发生故障时，系统是否依然稳定运行，高可用；在亿万量级访问的高并发下，系统是否能在7×24 小时内一直稳定运行，是否能在毫秒级别依然准确而稳定地返回数据；如果业务访问量超出预期、成倍增加，系统是否不需要修改大量代码，只需要调整配置，扩容服务器，即可快速支持；如果业务需求快速变化，系统是否可以通过业务架构的良好扩展能力，无须大量改动代码就能够轻松应对……要想实现上述目标，完成一个优秀的架构设计，必须以架构师丰富的实战经验为依托。而在何种场景下采用何种架构设计，并真正解决问题，才是体现架构师能力的关键。所以，要想成为一名优秀的架构师，需要技术人员保持“空杯心态”，不断地学习、交流、实践，才能修成正果，这也是我们出版这本书的初衷。
从2016 年开始，我们持续在“携程技术”微信公众号发表相关文章，每年年底还会编辑成合辑，和大家分享携程每年的技术成长和经验积累。2019 年年初，电子工业出版社的编辑联系我们，希望我们把这几年的相关文章编撰成书以整体呈现携程的技术架构，大家一拍即合，于是有了本书。
虽然介绍特定技术产品架构的文章很多，但能在一本书中将整个公司的技术架构浓缩是很难得的。本书可以帮助读者了解支撑一家大型企业所需要的核心技术产品，以及它们的架构和面临的挑战。不同领域的架构关注点各有侧重，但是方法论是相通的。希望读者通过本书了解携程的架构实践，拓宽视野，丰富自己的架构工具箱，在遇到难题时，看看其他领域的解决思路，就可能碰撞出意想不到的“火花”。
携程技术副总裁 李小林

前言
重回首，去时年，揽尽风雨苦亦甜。不知不觉，携程已经走过了20 多年的历程。多年来，携程不断地深耕在线旅游（OTA）行业，力求为用户提供更加多元、舒适的服务。时至今日，作为国内优秀的OTA 企业，携程正逐渐成为推动全球旅游行业发展的中坚力量。
与众不同的业务基因，决定了携程必须走出一条适合自身发展的技术道路。随着携程业务规模的快速扩张，其技术体系也在持续沉淀。技术领域没有银弹，技术体系必然会随着业务需求的变更而不断演进，并且在演进过程中，每一次成功或失败所积累的经验教训都会在下一次实践过程中得到体现。本书将从流量接入层、后端系统和技术保障三方面出发，介绍携程在各个技术领域的最新实践及相关思考。
第一部分主要介绍流量接入层。流量接入层是用户使用携程服务的入口，直接影响用户的服务体验。这部分首先介绍携程在前端技术领域，尤其是移动开发框架与周边设施的实践方案；然后阐述如何通过提升网络层访问的性能和质量，来进一步改善用户体验；最后解析携程优质服务的核心系统——呼叫中心是如何构建的。
第二部分主要介绍后端系统。可靠的后端系统是处理海量用户请求的关键，其主要特征包括高可用、高并发、高性能。这部分从分布式消息队列、微服务、配置中心等核心中间件入手，剖析携程在框架中间件体系建设过程中遇到的一系列难题及其应对措施。同时针对如何构建高效、可靠的数据访问层及存储体系等，与读者进行深入探讨。
第三部分主要介绍技术保障。产品从立项到研发、测试、上线，再到运行时的监控、弹性扩缩容，其生命周期的每一个阶段都需要完善的技术保障支持。这部分涵盖了持续集成、监控告警及多数据中心架构等内容，以及携程如何在持续提升研发效率的同时，降低甚至避免快速迭代对网站可用性产生的负面影响。中国抓住了信息革命的机遇，造就了很多世界级的互联网公司，也拥有了众多互联网领域的“独角兽”，但市场上还没有能够全面介绍一家公司的完整技术体系的书籍，本书的初衷正在于此。我们从一线研发工程师中遴选出本书的作者团队，将架构演进过程中遇到的挑战、走过的弯路及最新的实践方案编撰成书，在给读者呈现携程技术架构体系的同时，也希望给读者带来一些启发，共同推动技术进步。
我们并不完美，但我们心怀敬畏。愿各位永葆对技术的憧憬与热忱。
《携程架构实践》编委会

本书配套资源下载

对不起，暂无音视频资源！