具体描述
一个好的架构就像一个好的制度,我们不会时时刻刻感受到它的存在,但在关键时刻,它决定了系统能够到达的高度。
本书浓缩了携程公司的整个技术架构,可以帮助读者了解支撑一家大型企业所需要的核心技术产品,以及它们的架构和面临的挑战。本书由携程的一线研发工程师们精心编写,他们对携程各个领域的技术实践了如指掌,本书所提到的各种系统离不开他们的耕耘。在给读者呈现携程架构实践的同时,也希望本书能给读者带来一些警示和启发,共同推动技术的进步。
不同领域的架构关注点各有侧重,但是方法论是相通的。希望读者通过本书了解携程的架构实践,拓宽视野,丰富自己的架构工具箱,在遇到难题时,看看其他领域的解决思路,就可能碰撞出意想不到的“火花”。
作者简介
携程技术团队
作为携程集团的核心竞争力,携程技术团队由近7000位来自海内外的精英工程师组成,为携程集团业务的运作和开拓提供全面技术支持,并以技术创新源源不断地为产品和服务创造价值。
技术从来都不是闭门造车,携程技术团队会一直以开放和充满热情的心态,通过各种渠道和方式,和圈内小伙伴们探讨、交流、碰撞,共同收获和成长。
目录信息
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
· · · · · · (收起)
读后感
用户评价
初读《携程架构实践》,我立刻被书中贯穿始终的“用户至上”理念所打动。作为一个普通用户,我或许只关注搜索是否快速、支付是否便捷、订单是否安全,但这本书让我看到了这些流畅体验背后,是无数工程师对“稳定性”和“可用性”的不懈追求。书中详细阐述了携程在构建高可用架构时所采取的各种策略,例如服务治理、容错机制、数据备份与恢复等等。这些措施的背后,是工程师们对各种极端情况的预判和应对。想象一下,在旅游旺季,海量的用户涌入平台,需要同时处理数以亿计的订单请求,携程的系统是如何做到纹丝不动的?书中对此进行了深入的剖析,从负载均衡到流量控制,再到服务降级和熔断,每一个环节都体现了工程师们的匠心独运。同时,我也对书中关于“系统弹性”的讨论印象深刻。当某个服务出现故障时,整个系统是如何做到不受影响,甚至能够快速自我修复的?这背后涉及到服务间的解耦、异步通信、状态管理等一系列复杂的技术课题。这本书让我明白,一个成功的互联网架构,不仅仅是代码的堆叠,更是对风险的提前预知和对用户体验的极致呵护。它让我从一个用户的视角,更加深刻地理解了技术的力量,以及那些默默付出、保障我们顺畅出行的工程师们。
阅读《携程架构实践》过程中,我被书中对于“数据治理”的重视所深深吸引。作为一个提供旅行预订服务的平台,携程处理的数据量庞大且复杂,涵盖了用户、酒店、机票、订单、支付等方方面面。如何对这些数据进行有效的管理,保证数据的准确性、一致性、安全性,并能够从中挖掘出有价值的信息,是支撑业务发展和提升用户体验的关键。书中关于“数据仓库”、“数据湖”、“数据中台”等概念的实践,让我看到了携程在数据化运营方面所做的努力。如何从海量原始数据中提取、清洗、转换,形成可供分析和利用的数据资产?如何建立统一的数据标准和数据质量管理体系?如何利用大数据技术赋能业务决策和产品创新?这些都是非常具有挑战性的课题。我尤其对书中关于“AB测试”的实践印象深刻。携程是如何通过精细化的AB测试,来验证新功能的有效性,优化用户体验,并最终将最适合用户的产品方案推向大众?这种基于数据的决策方式,是现代互联网产品迭代的基石。这本书让我认识到,数据不仅仅是数字的堆叠,更是驱动业务增长和技术优化的核心动力。
《携程架构实践》这本书给我最大的感受是,一个庞大而复杂的系统,其稳定性绝非偶然,而是源于精心的设计和持续的投入。书中关于“监控与告警”的章节,让我看到了携程如何构建一套全方位的监控体系,涵盖了从服务器性能、应用响应、到业务流程的每一个环节。当系统出现异常时,能够第一时间被发现,并迅速定位问题根源,这背后需要海量的日志数据分析、指标收集和智能告警规则的设置。我特别关注书中关于“容错与降级”的讨论。在分布式系统中,任何一个节点都可能发生故障,如何设计优雅的容错机制,如何在服务不可用时进行合理的降级,以保证核心业务的可用性?这需要工程师们具备深厚的系统设计能力和风险意识。例如,在用户订票过程中,如果某个支付渠道出现故障,系统是如何自动切换到其他支付渠道,或者给用户提供明确的提示,而不是直接导致整个订票流程失败?这种对用户体验的极致追求,体现在了架构设计的每一个细节中。这本书让我认识到,保障系统的“韧性”,即在面对各种挑战时能够快速恢复和适应的能力,是现代互联网架构的核心要素之一。
细细品读《携程架构实践》,我最大的感受是,好的架构不仅在于技术上的精巧,更在于其背后所蕴含的“哲学”和“思维模式”。携程在构建其庞大的技术体系时,并非盲目跟风,而是有着清晰的战略思考。书中关于“服务拆分”的讨论,不仅仅是简单的代码模块化,更是业务边界的重新梳理和团队结构的优化。如何找到合适的微服务边界,如何平衡服务的粒度,如何管理好服务间的依赖关系,这些都是需要深厚的业务理解和技术功底。我尤其对书中关于“数据一致性”的探讨很感兴趣。在分布式系统中,如何保证不同服务间的数据同步和一致性,是一个巨大的挑战。携程是如何通过各种技术手段,例如消息队列、分布式事务、最终一致性等,来解决这个难题的?这让我认识到,数据是系统的核心,而保证数据的正确性是架构设计的重中之重。此外,书中对“可观测性”的重视也给我留下了深刻的印象。携程是如何建立起一套完善的监控、日志和追踪体系,从而能够实时了解系统的运行状态,快速定位和解决问题?这种“知己知彼”的能力,是支撑系统稳定运行的关键。这本书让我明白,一个优秀的架构师,不仅要懂技术,更要懂业务,懂人,懂管理,它是一门综合的艺术。
《携程架构实践》这本书给我带来的最深刻的感受是,架构的演进是一个持续不断、充满挑战的过程。它不是一蹴而就的,也不是一成不变的。携程作为一个经历了多年发展的在线旅游平台,其架构必然经历了多次重大的变革和优化。书中对于早期架构的描述,让我看到了技术发展的痕迹,以及随着业务增长带来的痛点。而对后来如何进行服务化拆分、引入微服务、构建高内聚低耦合的模块,则是一部生动的“解耦史”。我特别欣赏书中关于“权衡”的讨论。任何架构设计都离不开权衡,比如牺牲一定的开发效率来换取更高的性能,或者为了保证强一致性而接受更高的延迟。携程在不同阶段是如何进行这些权衡的?他们在面对技术债务时又是如何管理的?这些都是非常值得我们学习的经验。此外,书中对“领域驱动设计”(DDD)的阐述也让我眼前一亮。DDD的思想是如何帮助携程梳理复杂的业务领域,并将其映射到清晰的微服务边界的?这对于那些正在经历业务快速扩张、或者希望优化现有系统设计的团队来说,具有极高的参考价值。这本书不仅仅是技术的罗列,更是思维方式的传递。它教会我们如何从业务出发,去思考技术解决方案,如何将抽象的概念转化为具体的实践。读完这本书,我感觉自己对如何构建一个可扩展、可维护、高性能的系统有了更清晰的认识,也更加理解了“技术驱动业务”这句话的真正含义。
《携程架构实践》这本书给我最大的启发在于,技术架构的决策往往是在诸多约束条件下的最优解。书中并没有提供一套放之四海而皆准的“银弹”,而是展示了携程在不同历史时期、面对不同业务场景时,所做出的具体技术选择和权衡。例如,在早期阶段,为了快速响应市场需求,可能会选择更易于开发的单体架构,但随着业务规模的扩大,这种架构带来的技术债务会日益显现。书中描述了如何从单体向微服务演进的过程,这其中必然涉及到大量的重构、迁移和技术栈的更新,这是一个充满痛苦但又必须经历的转型。我尤其关注书中关于“技术选型”的讨论。携程在面对各种新技术时,是如何进行评估和引入的?他们是如何平衡新技术的先进性与现有系统的兼容性?是如何确保引入新技术能够真正解决业务问题,而不是制造新的麻烦?这些都是非常现实且重要的考量。此外,书中对“ DevOps”理念的实践也让我受益匪浅。携程是如何将开发、测试、部署、运维等环节紧密结合起来,实现高效的交付和快速的迭代? CI/CD流水线的建设、自动化测试的普及、监控与告警体系的建立,这些都离不开DevOps文化的支撑。这本书让我看到了一个成熟的技术团队是如何通过流程和文化的优化,来提升整体的工程效率和交付质量。
《携程架构实践》这本书给我带来的最大价值,在于其“解决问题”的导向性。书中详细描述了携程在发展过程中遇到的各种实际技术难题,以及他们是如何一步步找到解决方案的。比如,在面对海量数据存储和检索时,携程是如何选择合适的数据库技术,如何进行数据分片和索引优化,以保证查询的高效性?又比如,在进行复杂的交易处理时,如何保证交易的原子性、一致性、隔离性和持久性(ACID)?在分布式环境下,实现强一致性事务是一个巨大的挑战,携程又是如何应对的?书中对于“业务连续性”的保障也让我印象深刻。在遭遇突发事件,例如网络故障、机房宕机等情况下,携程的系统是如何做到快速恢复,保证业务不受大的影响的?这其中涉及到异地容灾、数据备份与恢复、故障转移等一系列复杂的技术措施。这本书让我看到,技术不仅仅是冰冷的代码,更是为用户提供稳定、可靠服务的重要保障。它让我从一个更高的维度去理解技术架构的重要性,以及它在支撑企业核心业务发展中的关键作用。
在阅读《携程架构实践》的过程中,我发现书中反复强调“持续学习和迭代”的重要性。携程的技术架构并非一成不变,而是随着业务的发展、技术的进步而不断演进的。书中对于“技术演进路线图”的描绘,让我看到了一个企业如何在前瞻性地规划其技术发展方向。例如,在早期,可能依赖于传统的单体架构,但随着移动互联网的兴起,对性能、可扩展性、响应速度提出了更高的要求,这就促使他们向微服务、高并发等方向演进。书中对于“技术选型”的决策过程也很有参考价值。他们是如何评估各种新兴技术的优劣,如何进行小范围的试验,如何判断是否适合引入到核心业务系统中?这背后需要严谨的科学态度和丰富的实践经验。我尤其欣赏书中关于“创新与试错”的讨论。在互联网行业,鼓励创新是必然的,但创新也伴随着风险。携程是如何在鼓励创新的同时,又能够有效控制风险,避免给业务带来颠覆性的影响?这种平衡艺术非常值得学习。这本书让我深刻认识到,一个成功的技术架构,是技术团队不断学习、不断尝试、不断优化的结果,它是一个动态的、充满活力的过程。
这次有幸读到《携程架构实践》,虽然我不是一个技术专家,但我对互联网公司如何构建庞大而稳定的系统一直充满好奇。这本书就像一位经验丰富的向导,为我揭开了携程这家出行巨头背后那错综复杂但又井然有序的技术世界。从早期单体架构的种种挑战,到如何逐步拆解、演进为如今高度分布式、微服务化的现代架构,整个过程充满了智慧和汗水。我尤其被书中关于“高可用性”和“高性能”的探讨所吸引,它们不仅仅是技术名词,更是用户体验的基石。想想我们每次在携程上顺畅地预订机票、酒店,背后有多少层精巧的设计在默默运行?这本书没有止步于理论的堆砌,而是深入到携程在实际应用中遇到的问题,以及他们是如何思考、实验、迭代,最终找到适合自己的解决方案。比如,在应对海量并发请求时,他们是如何通过负载均衡、缓存策略、限流熔断等手段来保证服务的稳定运行?在数据管理方面,如何处理分散在不同服务中的海量异构数据,并保证数据的一致性和时效性?这些都是我过去从未深入了解过的领域。作者用非常接地气的方式,将那些高深的技术概念娓娓道来,让我这个非技术背景的读者也能窥见其中的奥妙。它让我意识到,一个成功的互联网产品,绝不仅仅是漂亮的UI和丰富的功能,更离不开强大的、经过千锤百炼的底层架构支撑。这本书让我对“架构”这个词有了全新的认识,它不再是冰冷的代码堆叠,而是承载用户梦想、驱动商业运转的灵魂。
《携程架构实践》这本书为我打开了一扇了解互联网巨头技术底层的窗户。我尤其被书中关于“性能优化”和“成本控制”的探讨所吸引。在旅游行业,用户对于响应速度的要求极高,任何一点延迟都可能导致用户流失。携程是如何通过各种手段,将用户请求的处理时间缩短到极致?书中对于缓存策略、数据库优化、网络传输优化等方面的介绍,都充满了实践智慧。同时,随着业务规模的不断扩大,IT成本也成为一个不容忽视的问题。携程是如何在保证性能和可用性的前提下,实现成本的有效控制?例如,在云计算环境下,他们是如何选择合适的云服务、如何进行资源调度和优化,以降低运营成本?这些都是在快速发展的业务背后,工程师们必须面对的现实挑战。书中对于“技术债务”的管理也让我深有体会。任何系统在发展过程中都会积累技术债务,关键在于如何有效的识别、度量和偿还。携程在这方面是否有系统的管理机制?他们是如何平衡新功能的开发与旧系统的维护?这些都是值得我们借鉴的经验。这本书不仅仅是技术的堆砌,更是对“如何用技术创造更大的商业价值”的深入探讨。
可以通过本书,一窥携程复杂的业务形态以及因应这一复杂形态做出的特定架构取舍。比如携程的业务消息具有自有的特点,于是自研了QMQ队列。 "基于这些考虑我们并没有直接采用Kafka等基于partition存储模型的消息队列,我们的设计考虑是消费和存储模型是完全解耦的关系,Consumer需要很容易的扩容缩容,从现在来看这个选择也是正确的。现在去哪儿网的系统架构基本上呈现为基于消息驱动的架构,在我们内部系统之间的交互大部分都是以消息这种异步的方式来进行。比如我们酒店的订单变更消息就有接近70个不同的消费组订阅(可以将消费组理解为不同的应用),整个交易流程都是靠消息来驱动"
讲解携程的架构演化,大多都是实践方面的,内容还是不错,不过都是点到为止
可以通过本书,一窥携程复杂的业务形态以及因应这一复杂形态做出的特定架构取舍。比如携程的业务消息具有自有的特点,于是自研了QMQ队列。 "基于这些考虑我们并没有直接采用Kafka等基于partition存储模型的消息队列,我们的设计考虑是消费和存储模型是完全解耦的关系,Consumer需要很容易的扩容缩容,从现在来看这个选择也是正确的。现在去哪儿网的系统架构基本上呈现为基于消息驱动的架构,在我们内部系统之间的交互大部分都是以消息这种异步的方式来进行。比如我们酒店的订单变更消息就有接近70个不同的消费组订阅(可以将消费组理解为不同的应用),整个交易流程都是靠消息来驱动"
可能是博客文章成书的原因 算是架构思想和方法论的零散大集合 有些有价值的思路 但是都比较粗线条 读完后的收货就是了解
大杂烩,不喜欢