描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121314667
编辑推荐
√ 星光熠熠的技术翘楚
√ 匠心独具的破局思路
√ 业界首创的一线实践
√ 千锤百炼的专题精华
√ 匠心独具的破局思路
√ 业界首创的一线实践
√ 千锤百炼的专题精华
内容简介
本书由数十位一线架构师的实践与经验凝结而成，选材兼顾技术性、前瞻性与专业深度。各技术焦点，均由极具代表性的领域专家或实践先行者撰文深度剖析，共同组成“高可用”的全局视野与领先高度，内容包括精华案例、分布式原理、电商架构等热门专题，及云计算、容器、运维、大数据、安全等重点方向。不仅架构师可以从中受益，其他IT、互联网技术从业者同样可以得到提升
目 录
第1 章 高可用架构案例精选 1
郭斯杰／1.1 Twitter 高性能分布式日志系统架构解析 1
1.1.1 为什么需要分布式日志. 1
1.1.2 Twitter 如何考虑这个问题 4
1.1.3 基于Apache BookKeeper 构建DistributeLog 5
1.1.4 DistributeLog 案例分享13
1.1.5 疑问与解惑.13
颜国平／1.2 腾讯基于用户画像大数据的电商防刷架构.16
1.2.1 背景介绍16
1.2.2 黑产现状介绍16
1.2.3 腾讯内部防刷架构18
1.2.4 腾讯大数据收集维度.20
1.2.5 腾讯大数据处理平台——魔方21
1.2.6 疑问与解惑.24
王渊命／1.3 如何设计类似微信的多终端数据同步协议：Grouk 实践分享.26
1.3.1 移动互联网时代多终端数据同步面临的挑战26
1.3.2 多终端数据同步与传统消息投递协议的差异27
1.3.3 Grouk 在多终端数据同步协议上的探索实践.28
1.3.4 疑问与解惑.32
周 洋／1.4 如何实现支持数亿用户的长连消息系统：Golang 高并发案例33
1.4.1 关于push 系统对比与性能指标的讨论.33
1.4.2 消息系统架构介绍35
1.4.3 哪些因素决定推送系统的效果37
1.4.4 GO 语言开发问题与解决方案.38
1.4.5 消息系统的运维及测试41
1.4.6 疑问与解惑.42
唐福林／1.5 雪球在股市风暴下的高可用架构改造分享.46
1.5.1 雪球公司的介绍46
1.5.2 雪球当前总体架构47
1.5.3 雪球架构优化历程48
1.5.4 关于架构优化的总结和感想.53
1.5.5 疑问与解惑.54
麦俊生／1.6 亿级短视频社交美拍架构实战59
1.6.1 短视频市场的发展59
1.6.2 美拍的发展.60
1.6.3 短视频所面临的架构问题61
1.6.4 为支持亿级用户，美拍架构所做的一些改进62
1.6.5 后续发展68
刘道儒／1.7 微博“异地多活”部署经验谈69
1.7.1 微博异地多活建设历程69
1.7.2 微博异地多活面临的挑战70
1.7.3 异地多活的实践.73
1.7.4 异地多活的新方向74
孙宇聪／1.8 来自Google 的高可用架构理念与实践75
1.8.1 决定可用性的两大因素76
1.8.2 高可用性方案77
1.8.3 可用性7 级图表80
1.8.4 疑问与解惑.81
那 谁／1.9 深入理解同步／异步与阻塞／非阻塞区别84
1.9.1 同步与异步.84
1.9.2 阻塞与非阻塞85
1.9.3 与多路复用I/O 的联系86
第2 章 高可用架构原理与分布式实践.88
黄东旭／2.1 Codis 作者细说分布式Redis 架构设计88
2.1.1 Redis、Redis Cluster 和Codis88
2.1.2 我们更爱一致性90
2.1.3 Codis 在生产环境中的使用经验和坑91
2.1.4 分布式数据库和分布式架构.94
2.1.5 疑问与解惑.95
霍泰稳／2.2 给你介绍一个不一样的硅谷.98
2.2.1 Uber .98
2.2.2 Coursera.99
2.2.3 Airbnb102
2.2.4 硅谷行带给我的一些影响106
2.2.5 疑问与解惑106
金自翔／2.3 解耦的艺术——大型互联网业务系统的插件化改造110
2.3.1 插件化.110
2.3.2 如何处理用户交互115
2.3.3 如何处理数据.115
2.3.4 总结116
沈 剑／2.4 从零开始搭建高可用IM 系统117
2.4.1 什么是IM117
2.4.2 协议设计118
2.4.3 WEB 聊天室.122
2.4.4 IM 典型业务场景126
2.4.5 疑问与解惑126
陈宗志／2.5 360 分布式存储系统Bada 的架构设计和应用.129
2.5.1 主要应用场景.129
2.5.2 整体架构130
2.5.3 主要模块131
2.5.4 数据分布策略.132
2.5.5 请求流程133
2.5.6 多机房架构134
2.5.7 FAQ138
2.5.8 疑问与解惑139
张 亮／2.6 新一代分布式任务调度框架：东东Elastic-Job 开源项目
的10 项特性143
2.6.1 为什么需要作业（定时任务）.143
2.6.2 东东之前使用的作业系统144
2.6.3 Elastic-Job 的来历.144
2.6.4 Elastic-Job 包含的功能145
2.6.5 Elastic-Job 的部署和使用.146
2.6.6 对开源产品的开发理念.147
2.6.7 未来展望148
2.6.8 疑问与解惑149
付海军／2.7 互联网DSP 广告系统架构及关键技术解析152
2.7.1 优秀DSP 系统的特点152
2.7.2 程序化购买的特点153
2.7.3 在线广告的核心问题156
2.7.4 在线广告的挑战.156
2.7.5 DSP 系统架构.157
2.7.6 RTB 投放引擎的架构.158
2.7.7 DMP160
2.7.8 广告系统DMP 数据处理的架构.160
2.7.9 用户画像的方法.162
2.7.10 广告行业的反作弊.165
2.7.11 P2P 流量互刷166
2.7.12 CPS 引流作弊167
2.7.13 疑问与解惑168
王卫华／2.8 亿级规模的Elasticsearch 优化实战170
2.8.1 索引性能（Index Performance） .170
2.8.2 查询性能（Query Perofrmance） 171
2.8.3 其他173
2.8.4 疑问与解惑174
杨卫华／2.9 微博分布式存储考试题：案例讲解及作业精选179
2.9.1 访问场景179
2.9.2 设计180
2.9.3 sharding 策略180
2.9.4 案例精选181
李 凯／2.10 架构师需要了解的Paxos 原理、历程及实战.184
2.10.1 数据库高可用性难题184
2.10.2 Paxos 协议简单回顾.185
2.10.3 Basic Paxos 同步日志的理论模型186
2.10.4 Multi Paxos 的实际应用.187
2.10.5 依赖时钟误差的变种Paxos 选主协议简单分析190
2.10.6 疑问与解惑191
温 铭／2.11 OpenResty 的现在和未来193
2.11.1 OpenResty 是什么，适合什么场景下使用.193
2.11.2 某安全公司服务端技术选型的标准194
2.11.3 如何在项目中引入新技术.196
2.11.4 如何入门以及学习的正确方法197
2.11.5 OpenResty 中的测试和调试.199
2.11.6 NginScript 是否会替代OpenResty201
2.11.7 未来重点解决的问题和新增特性.202
2.11.8 开源社区建设203
2.11.9 疑问与解惑.203
第3 章 电商架构热点专题.205
张开涛／3.1 亿级商品详情页架构演进技术解密.205
3.1.1 商品详情页205
3.1.2 商品详情页发展史209
3.1.3 遇到的一些问题和解决方案220
3.1.4 总结228
3.1.5 疑问与解惑229
杨 超／3.2 大促系统全流量压测及稳定性保证——交易架构.232
3.2.1 交易系统的三个阶段232
3.2.2 交易系统的三层结构233
3.2.3 交易系统的访问特征234
3.2.4 应对大促的第1 步：全链路全流量线上压测.234
3.2.5 应对大促的第2 步：根据压力表现进行调优.237
3.2.6 异步和异构240
3.2.7 应对大促的第3 步：分流与限流242
3.2.8 应对大促的第4 步：容灾降级.244
3.2.9 应对大促的第5 步：完善监控.245
3.2.10 疑问与解惑246
吕 毅／3.3 秒杀系统架构解密与防刷设计.248
3.3.1 抢购业务介绍.248
3.3.2 具体抢购项目中的设计.249
3.3.3 如何解耦前后端压力250
3.3.4 如何保证商品库的库存可靠252
3.3.5 如何与第三方多方对账.254
3.3.6 项目总结255
3.3.7 疑问与解惑255
王富平／3.4 Lambda 架构与推荐在电商网站实践.257
3.4.1 Lambda 架构257
3.4.2 1 号店推荐系统实践260
3.4.3 Lambda 的未来262
3.4.4 思考263
3.4.5 疑问与解惑263
杨 硕／3.5 某公司线上真实流量压测工具构建.265
3.5.1 为什么要开发一个通用的压测工具265
3.5.2 常见的压测工具.266
3.5.3 构建自己的压测工具266
3.5.4 疑问与解惑271
第4 章 容器与云计算.273
陈 飞／4.1 微博基于Docker 容器的混合云迁移实战.273
4.1.1 为什么要采用混合云的架构273
4.1.2 跨云的资源管理与调度.275
4.1.3 容器的编排与服务发现.278
4.1.4 混合云监控体系.284
4.1.5 前进路上遇到的那些坑.286
4.1.6 疑问与解惑286
高 磊／4.2 互联网金融创业公司Docker 实践287
4.2.1 背景介绍287
4.2.2 容器选型287
4.2.3 应用迁移288
4.2.4 弹性扩容291
4.2.5 未来规划295
4.2.6 疑问与解惑295
高永超／4.3 使用开源Calico 构建Docker 多租户网络.297
4.3.1 PaaS 平台的网络需求.297
4.3.2 使用Calico 实现Docker 的跨服务器通讯.298
4.3.3 利用Profile 实现ACL301
4.3.4 性能测试306
4.3.5 Calico 的发展308
4.3.6 疑问与解惑309
彭哲夫／4.4 解析Docker 在芒果TV 的实践之路310
4.4.1 豆瓣时期310
4.4.2 芒果TV 的Nebulium Engine .311
4.4.3 Project Eru .312
4.4.4 细节313
4.4.5 网络314
4.4.6 存储315
4.4.7 Scale316
4.4.8 资源分配和集群调度316
4.4.9 服务发现和安全.317
4.4.10 实例317
4.4.11 总结318
4.4.12 疑问与解惑318
王关胜／4.5 微博基于Docker 的混合云平台设计与实践323
4.5.1 微博的业务场景及混合云背景.323
4.5.2 三大基础设施助力微博混合云.326
4.5.3 微博混合云DCP 系统设计核心：自动化、弹性调度328
4.5.4 引入阿里云作为第3 机房，实现弹性调度架构330
4.5.5 大规模集群操作自动化.331
4.5.6 不怕峰值事件.332
第5 章 运维保障333
王 康／5.1 360 如何用QConf 搞定两万以上服务器的配置管理.333
5.1.1 设计初衷333
5.1.2 整体认识334
5.1.3 架构介绍335
5.1.4 QConf 服务端336
5.1.5 QConf 客户端336
5.1.6 QConf 管理端340
5.1.7 其他341
5.1.8 疑问与解惑343
尤 勇／5.2 深度剖析开源分布式监控CAT347
5.2.1 背景介绍347
5.2.2 整体设计348
5.2.3 客户端设计349
5.2.4 服务端设计352
5.2.5 总结感悟357
杨尚刚／5.3 单表60 亿记录等大数据场景的MySQL 优化和运维之道359
5.3.1 前言359
5.3.2 数据库开发规范.360
5.3.3 数据库运维规范.363
5.3.4 性能优化368
5.3.5 疑问与解惑375
秦 迪／5.4 微博在大规模、高负载系统问题排查方法379
5.4.1 背景379
5.4.2 排查方法及线索.379
5.4.3 总结384
5.4.4 疑问与解惑385
秦 迪／5.5 系统运维之为什么每个团队存在大量烂代码387
5.5.1 写烂代码很容易.387
5.5.2 烂代码终究是烂代码388
5.5.3 重构
郭斯杰／1.1 Twitter 高性能分布式日志系统架构解析 1
1.1.1 为什么需要分布式日志. 1
1.1.2 Twitter 如何考虑这个问题 4
1.1.3 基于Apache BookKeeper 构建DistributeLog 5
1.1.4 DistributeLog 案例分享13
1.1.5 疑问与解惑.13
颜国平／1.2 腾讯基于用户画像大数据的电商防刷架构.16
1.2.1 背景介绍16
1.2.2 黑产现状介绍16
1.2.3 腾讯内部防刷架构18
1.2.4 腾讯大数据收集维度.20
1.2.5 腾讯大数据处理平台——魔方21
1.2.6 疑问与解惑.24
王渊命／1.3 如何设计类似微信的多终端数据同步协议：Grouk 实践分享.26
1.3.1 移动互联网时代多终端数据同步面临的挑战26
1.3.2 多终端数据同步与传统消息投递协议的差异27
1.3.3 Grouk 在多终端数据同步协议上的探索实践.28
1.3.4 疑问与解惑.32
周 洋／1.4 如何实现支持数亿用户的长连消息系统：Golang 高并发案例33
1.4.1 关于push 系统对比与性能指标的讨论.33
1.4.2 消息系统架构介绍35
1.4.3 哪些因素决定推送系统的效果37
1.4.4 GO 语言开发问题与解决方案.38
1.4.5 消息系统的运维及测试41
1.4.6 疑问与解惑.42
唐福林／1.5 雪球在股市风暴下的高可用架构改造分享.46
1.5.1 雪球公司的介绍46
1.5.2 雪球当前总体架构47
1.5.3 雪球架构优化历程48
1.5.4 关于架构优化的总结和感想.53
1.5.5 疑问与解惑.54
麦俊生／1.6 亿级短视频社交美拍架构实战59
1.6.1 短视频市场的发展59
1.6.2 美拍的发展.60
1.6.3 短视频所面临的架构问题61
1.6.4 为支持亿级用户，美拍架构所做的一些改进62
1.6.5 后续发展68
刘道儒／1.7 微博“异地多活”部署经验谈69
1.7.1 微博异地多活建设历程69
1.7.2 微博异地多活面临的挑战70
1.7.3 异地多活的实践.73
1.7.4 异地多活的新方向74
孙宇聪／1.8 来自Google 的高可用架构理念与实践75
1.8.1 决定可用性的两大因素76
1.8.2 高可用性方案77
1.8.3 可用性7 级图表80
1.8.4 疑问与解惑.81
那 谁／1.9 深入理解同步／异步与阻塞／非阻塞区别84
1.9.1 同步与异步.84
1.9.2 阻塞与非阻塞85
1.9.3 与多路复用I/O 的联系86
第2 章 高可用架构原理与分布式实践.88
黄东旭／2.1 Codis 作者细说分布式Redis 架构设计88
2.1.1 Redis、Redis Cluster 和Codis88
2.1.2 我们更爱一致性90
2.1.3 Codis 在生产环境中的使用经验和坑91
2.1.4 分布式数据库和分布式架构.94
2.1.5 疑问与解惑.95
霍泰稳／2.2 给你介绍一个不一样的硅谷.98
2.2.1 Uber .98
2.2.2 Coursera.99
2.2.3 Airbnb102
2.2.4 硅谷行带给我的一些影响106
2.2.5 疑问与解惑106
金自翔／2.3 解耦的艺术——大型互联网业务系统的插件化改造110
2.3.1 插件化.110
2.3.2 如何处理用户交互115
2.3.3 如何处理数据.115
2.3.4 总结116
沈 剑／2.4 从零开始搭建高可用IM 系统117
2.4.1 什么是IM117
2.4.2 协议设计118
2.4.3 WEB 聊天室.122
2.4.4 IM 典型业务场景126
2.4.5 疑问与解惑126
陈宗志／2.5 360 分布式存储系统Bada 的架构设计和应用.129
2.5.1 主要应用场景.129
2.5.2 整体架构130
2.5.3 主要模块131
2.5.4 数据分布策略.132
2.5.5 请求流程133
2.5.6 多机房架构134
2.5.7 FAQ138
2.5.8 疑问与解惑139
张 亮／2.6 新一代分布式任务调度框架：东东Elastic-Job 开源项目
的10 项特性143
2.6.1 为什么需要作业（定时任务）.143
2.6.2 东东之前使用的作业系统144
2.6.3 Elastic-Job 的来历.144
2.6.4 Elastic-Job 包含的功能145
2.6.5 Elastic-Job 的部署和使用.146
2.6.6 对开源产品的开发理念.147
2.6.7 未来展望148
2.6.8 疑问与解惑149
付海军／2.7 互联网DSP 广告系统架构及关键技术解析152
2.7.1 优秀DSP 系统的特点152
2.7.2 程序化购买的特点153
2.7.3 在线广告的核心问题156
2.7.4 在线广告的挑战.156
2.7.5 DSP 系统架构.157
2.7.6 RTB 投放引擎的架构.158
2.7.7 DMP160
2.7.8 广告系统DMP 数据处理的架构.160
2.7.9 用户画像的方法.162
2.7.10 广告行业的反作弊.165
2.7.11 P2P 流量互刷166
2.7.12 CPS 引流作弊167
2.7.13 疑问与解惑168
王卫华／2.8 亿级规模的Elasticsearch 优化实战170
2.8.1 索引性能（Index Performance） .170
2.8.2 查询性能（Query Perofrmance） 171
2.8.3 其他173
2.8.4 疑问与解惑174
杨卫华／2.9 微博分布式存储考试题：案例讲解及作业精选179
2.9.1 访问场景179
2.9.2 设计180
2.9.3 sharding 策略180
2.9.4 案例精选181
李 凯／2.10 架构师需要了解的Paxos 原理、历程及实战.184
2.10.1 数据库高可用性难题184
2.10.2 Paxos 协议简单回顾.185
2.10.3 Basic Paxos 同步日志的理论模型186
2.10.4 Multi Paxos 的实际应用.187
2.10.5 依赖时钟误差的变种Paxos 选主协议简单分析190
2.10.6 疑问与解惑191
温 铭／2.11 OpenResty 的现在和未来193
2.11.1 OpenResty 是什么，适合什么场景下使用.193
2.11.2 某安全公司服务端技术选型的标准194
2.11.3 如何在项目中引入新技术.196
2.11.4 如何入门以及学习的正确方法197
2.11.5 OpenResty 中的测试和调试.199
2.11.6 NginScript 是否会替代OpenResty201
2.11.7 未来重点解决的问题和新增特性.202
2.11.8 开源社区建设203
2.11.9 疑问与解惑.203
第3 章 电商架构热点专题.205
张开涛／3.1 亿级商品详情页架构演进技术解密.205
3.1.1 商品详情页205
3.1.2 商品详情页发展史209
3.1.3 遇到的一些问题和解决方案220
3.1.4 总结228
3.1.5 疑问与解惑229
杨 超／3.2 大促系统全流量压测及稳定性保证——交易架构.232
3.2.1 交易系统的三个阶段232
3.2.2 交易系统的三层结构233
3.2.3 交易系统的访问特征234
3.2.4 应对大促的第1 步：全链路全流量线上压测.234
3.2.5 应对大促的第2 步：根据压力表现进行调优.237
3.2.6 异步和异构240
3.2.7 应对大促的第3 步：分流与限流242
3.2.8 应对大促的第4 步：容灾降级.244
3.2.9 应对大促的第5 步：完善监控.245
3.2.10 疑问与解惑246
吕 毅／3.3 秒杀系统架构解密与防刷设计.248
3.3.1 抢购业务介绍.248
3.3.2 具体抢购项目中的设计.249
3.3.3 如何解耦前后端压力250
3.3.4 如何保证商品库的库存可靠252
3.3.5 如何与第三方多方对账.254
3.3.6 项目总结255
3.3.7 疑问与解惑255
王富平／3.4 Lambda 架构与推荐在电商网站实践.257
3.4.1 Lambda 架构257
3.4.2 1 号店推荐系统实践260
3.4.3 Lambda 的未来262
3.4.4 思考263
3.4.5 疑问与解惑263
杨 硕／3.5 某公司线上真实流量压测工具构建.265
3.5.1 为什么要开发一个通用的压测工具265
3.5.2 常见的压测工具.266
3.5.3 构建自己的压测工具266
3.5.4 疑问与解惑271
第4 章 容器与云计算.273
陈 飞／4.1 微博基于Docker 容器的混合云迁移实战.273
4.1.1 为什么要采用混合云的架构273
4.1.2 跨云的资源管理与调度.275
4.1.3 容器的编排与服务发现.278
4.1.4 混合云监控体系.284
4.1.5 前进路上遇到的那些坑.286
4.1.6 疑问与解惑286
高 磊／4.2 互联网金融创业公司Docker 实践287
4.2.1 背景介绍287
4.2.2 容器选型287
4.2.3 应用迁移288
4.2.4 弹性扩容291
4.2.5 未来规划295
4.2.6 疑问与解惑295
高永超／4.3 使用开源Calico 构建Docker 多租户网络.297
4.3.1 PaaS 平台的网络需求.297
4.3.2 使用Calico 实现Docker 的跨服务器通讯.298
4.3.3 利用Profile 实现ACL301
4.3.4 性能测试306
4.3.5 Calico 的发展308
4.3.6 疑问与解惑309
彭哲夫／4.4 解析Docker 在芒果TV 的实践之路310
4.4.1 豆瓣时期310
4.4.2 芒果TV 的Nebulium Engine .311
4.4.3 Project Eru .312
4.4.4 细节313
4.4.5 网络314
4.4.6 存储315
4.4.7 Scale316
4.4.8 资源分配和集群调度316
4.4.9 服务发现和安全.317
4.4.10 实例317
4.4.11 总结318
4.4.12 疑问与解惑318
王关胜／4.5 微博基于Docker 的混合云平台设计与实践323
4.5.1 微博的业务场景及混合云背景.323
4.5.2 三大基础设施助力微博混合云.326
4.5.3 微博混合云DCP 系统设计核心：自动化、弹性调度328
4.5.4 引入阿里云作为第3 机房，实现弹性调度架构330
4.5.5 大规模集群操作自动化.331
4.5.6 不怕峰值事件.332
第5 章 运维保障333
王 康／5.1 360 如何用QConf 搞定两万以上服务器的配置管理.333
5.1.1 设计初衷333
5.1.2 整体认识334
5.1.3 架构介绍335
5.1.4 QConf 服务端336
5.1.5 QConf 客户端336
5.1.6 QConf 管理端340
5.1.7 其他341
5.1.8 疑问与解惑343
尤 勇／5.2 深度剖析开源分布式监控CAT347
5.2.1 背景介绍347
5.2.2 整体设计348
5.2.3 客户端设计349
5.2.4 服务端设计352
5.2.5 总结感悟357
杨尚刚／5.3 单表60 亿记录等大数据场景的MySQL 优化和运维之道359
5.3.1 前言359
5.3.2 数据库开发规范.360
5.3.3 数据库运维规范.363
5.3.4 性能优化368
5.3.5 疑问与解惑375
秦 迪／5.4 微博在大规模、高负载系统问题排查方法379
5.4.1 背景379
5.4.2 排查方法及线索.379
5.4.3 总结384
5.4.4 疑问与解惑385
秦 迪／5.5 系统运维之为什么每个团队存在大量烂代码387
5.5.1 写烂代码很容易.387
5.5.2 烂代码终究是烂代码388
5.5.3 重构
前 言
推荐序1技术没有高低
高可用架构居然成书了，厚厚的一本，让人赞叹。从TimYang建立这个社群开始，我就一直参与其中，然而一切发生得如此之快，如此之自然，也是出乎意料。我想，这也是侠少约我写序的原因之一吧。
这里面有太多熟悉的朋友，确切地说，我跟他们中的大多数人都是很好的朋友。他们都乐于将自己的所知所学分享给社区，而我也每每从他们那里学到各种技术。
你可能会惊讶于本书内容的跨度之大，从业务系统到数据库，从容器到安全，从社区建设到行业观察，包罗万象。同时，讲解内容又实实在在，没有很多空话，偶有没说清楚的地方，肯定会有问答环节来补充说明。因为都是群内听讲的人提问，所以问答也非常契合主题。
这就保证了本书在特定章节上，比大多数同类书要讲得透彻、明白，适合初级人员阅读。同时，又对中高级技术人员有更大的价值。我们经常说架构师对技术的把握要有深度，也要有广度。广度从何而来，只能是读万卷书，阅千套系统积累而来。本书无疑是一个很好的素材源泉。
具体的内容我不在此赘述，相信大家仔细阅读后会收获颇丰。这里我还是介绍一下背后的这群人——这个由分享者和听众共同组成的大群体，这个称为高可用架构群的组织。
我经常讲，高可用架构这些群，像极了《一代宗师》里的金楼。因为你仔细看，技术圈就是互联网时代的武林。大家聚在这里，是因为在自己的领域里有所建树，都身怀绝技面对这个世界。所以我们会看到骄傲和拼搏，也会看到争论。因为很多人也都想着，功夫是一横一竖，站着的才有资格说话，错的，躺下。
但是幸运的是，他们找到了一种方式，来平息这种内心的躁动，就是通过在群里进行分享和答疑来进行“比武”。你说你的方式可行，就来分享吧。只要你的话我能懂，只要你的回答能使我满意，我便服气。而且慢慢地，大家也都认可了这种方式，技术领域之宽广，并非一个人可以统领。而承认一个人在某一个领域比你强并不丢人，更并不意味着你不可以在另外的领域独领风骚。
随着时间的流逝，这种技术驱动的交流也慢慢发酵成了真正的友情。金楼戏里让我感动的一幕。叶问比武前，金楼里的各位师傅都出来帮忙。三姐说，八卦手黑，小心。账房说，形意拳霸道，千万别轻敌。勇哥说，追风赶月别留情，你一定得响啊。
因为过去的这些坦诚交往，那些原本会被视为对手的人，在你遇到困难的时候，可以坚定地站在你身后。而当你遇到各种行业上的新事件，也会在群里表达自己真实的声音，期待从群里接收来自各方的诤言。
一群所学为一人学，一人可顶一群人。
这种健康的氛围，在技术圈里也愈发变得可贵。现在互联网在迅猛发展，很多新的技术被发明和引入了进来，碰撞和争论在所难免。但有一些圈子却变得特别吵闹，为了一个框架，为了一个语言就可以争到头破血流，发出各种攻击和谩骂，甚至堵上事业和人品，想想实在是让人遗憾。
高可用架构的这群人，他们都是工作在各个公司的一线技术管理人员，掌握着业界先进的工程技术。但其实他们也很普通，跟你一样，每天都在默默得工作和学习。不一样的是，他们可以聚在一起，输出这样优质的内容。
他们对技术的追求，他们共同的性格特质，也许更值得你体会。如果看完本书，你能够在技术理念有进一步的思考，那肯定是比看一本书本身收获更大的。
“其实天下之大，又何止南北？勉强求全等于固步自封，在你眼中这块饼是一个武林，对我来讲是一个世界。所谓大成若缺，有缺憾才能有进步，真管用的话，南拳又何止北传呐？”
我在叶先生出生的佛山旁边，广州，脑海中不断回响这段话。
一乐环信首席架构师兼云通讯事业部总经理
推荐序2
如果去问架构师什么是架构，可能会得到很多不同的答案，每个架构师都会对“架构”有不一样的理解，当然这不分对错，数据架构、应用架构、物理架构、组织架构等都是架构，甚至不仅在计算机行业，各行各业都会有类似的角色，但我觉得有一个核心的概念是共通的：架构必定是长期的生产活动中，经过深度思考，积累下来的实践和可复用的合理抽象。
作为Tim叔的朋友，我也是Tim叔发起的高可用架构微信群的早期成员之一，看着高可用架构群一步步发展起来，聚集了一大批一线的互联网架构师一起探讨和交流技术和架构上的问题。同时这个群也是国内早的一批尝试“在线群分享”这种形式的微信群，过去技术会议的分享受限于时间和空间，在它却这种形式下变得更加灵活和轻量，同时也能更好地沉淀下来。这里不得不提到Tim叔其人，虽然我不清楚技术群分享这个形式是否为Tim独创，但是确是非常“Tim-ish”的一个形式，Tim是国内早的分布式系统和高可用架构的实践者，同时也是一个活跃的技术，Blogger，我大概从2009年开始订阅Tim叔的Blog（后端技术），上面有很多很有价值和深度的技术文章，也算是看着Tim叔的Blog成长起来的程序员。互联网的分享精神，在这里就是一个很好的体现。随着近几年国内的互联网的蓬勃发展，新技术层出不穷，行业内也涌现出了很多优秀的工程师和架构师，Tim这两年就聚集起这样的一拨人，创造一个平台，能让大家的经验互相分享，思想互相碰撞，这本书就是一个很棒的阶段性的产物。
在一名工程师在成长的过程中，是否培养出“大局观”是一个重要的转折点，而快速提升自己“大局观”的方法之一就是多观察别人是怎么做的，并从中分析优势和劣势，在你面对不同的选择时多看看别人的思考过程，见多必然识广，也许此时你并不能直接解决自己遇到的问题，但更重要的是吸取别人的经验，思考得更全面。这几年随着互联网以及移动互联网的爆发，后端技术迭代的速度很快，新技术层见叠出，从RDBMS到NoSQL再到近的NewSQL；从单模块到SOA再到微服务；从简单的脚本部署和简单的HA到容器化的自动部署及调度；从单机到分布式再到近的云和Serverless……面对琳琅满目的设计和工具，该如何做出选择，本书不会明确告诉你答案，但是会通过一篇篇实际案例和分享来拓展你的眼界和视野，在你面临选择的时候能给到你一些启发。
本书并不是面向编程初学者的书，涉及一些比较深的内容，面也很广，建议有一定经验并希望更进一步的工程师和架构师阅读，你们一定会喜欢的。
再次感谢各位分享者和架构师，也感谢Tim和高可用架构团队的工作人员！
黄东旭PingCAPCTO
2017年8月写于海南三亚
推荐序3
我开始以为这是从理论开始的一本讲高可用的书，结果我拿到电子稿后发现上来就是很多不同公司的具体高可用的架构案例，而且是精选过的案例。从案例切入，会更加直接直观地让读者去了解高可用的架构，并且也提供了非常好的可参考的实例，如果读者在自己的场景中遇到类似问题，可以直接参考。除具体案例外，本书还通过不同公司中的系统的设计、改造的经验来介绍高可用的原理和分布式的实践，这个做法也比较有特色，依然选择了从具体的实践经验和具体的实例出发，而没有去凭空介绍很多道理，实践性非常强，并且案例所涵盖的范围是非常广泛的，和第1章的案例精选一样，都来自众的公司的实践。结束了前两章对高可用架构的案例和原理的介绍后，第3章用电商架构作为一个专题点进行了展开，在体量比较大的时候，利用电商的后端架构解决高可用还是有比较大挑战的，一些电商的经验还可以移植或者转化到别的系统当中，比较有参考价值。第4章从容器和云计算切入，这对高可用来说是一个重要的基础设施，不论基于公有云还是自己在内部做私有云亦或是采用混合云，云都是现在后端绕不过去的一个话题，而说到容器，就等同与说到了Docker，其轻量化以及通过Image来快速部署应用的特点，也使得Docker得到了广泛的应用。有了容器和云的支撑，那么如何在自身运维保障上能够适配高可用的要求，则是第5章提到的内容。没有高效的、自动的、可靠的运维支撑，是很难保障我们系统的高可用的。再接下来就到了大数据与数据库的部分，做高可用也好，做水平扩展也好，有状态的节点总是难处理的，这个章节专门针对数据库层面去做了案例的分析，大数据本身不仅仅包括了状态，还包括了计算，而大数据的计算往往是单个任务比较重的，那么做到高可用的挑战和处理我们很多前台的并发更高但是处理时长短、消耗资源小的并发任务有很大不同，这也是第6章会介绍的内容。后一章，介绍的是安全和网工，这个部分本身为整体应用系统提供了安全的防护和保障，进而使得从用户层面看系统是可用的。
本书的章节设置、前后的逻辑性很强，特别让我赞叹的是全书所有章节都是具体的案例，没有大套的理论、空洞的说教，都是从具体实际案例出发来介绍，一方面会给读者更强的现场感，一方面这些一个个具体的案例都是读者可参考的，相信这本书会给读者在高可用架构方面带来更多的信息和收获。
曾宪杰现任美丽联合集团技术副总裁
推荐序4
记得我还在新浪工作的那会儿，作为一名职场工程师新人，很早就开始关注Tim的技术博客。在理想国际大厦里也常见到Tim，但那时Tim对我来说是“只可远观而不可亵玩焉”。
很多年过去，随着自己在技术上的成长，我有幸加入到Tim组织的高可用架构群里。高可用群里的一项基本规则就是：大家要积极做技术分享。当时作为相对年轻的成员，我有些焦虑，毕竟与群里的大拿比较，我做的事情似乎不够高大上。但在百度完成一段抢购类型项目后，我发现在项目中总有些值得提炼的技术可以分享，于是主动联系了Tim并表达了分享的意愿。让人意外的是，在Tim事先了解内容的情况下，我也顺利地完成了一场人气爆棚的群内技术分享，总体反馈是，效果不错！事后也的确有同学联系我，采用了我的一些思路在公司内实现了抢购方案，同样，我也从高可用架构的其他分享里升华了技术视野，自此，我感受到了技术交流的重要性。
近两年我参加了不少技术会议，翻译了技术书籍，也随着团队内不少同学尝试图文、现场的技术交流，能明显感受到技术社区的活跃以及中国技术的快速崛起。当得知高可用组织要与博文视点联合出品《高可用架构（第1卷）》一书时，我强烈支
高可用架构居然成书了，厚厚的一本，让人赞叹。从TimYang建立这个社群开始，我就一直参与其中，然而一切发生得如此之快，如此之自然，也是出乎意料。我想，这也是侠少约我写序的原因之一吧。
这里面有太多熟悉的朋友，确切地说，我跟他们中的大多数人都是很好的朋友。他们都乐于将自己的所知所学分享给社区，而我也每每从他们那里学到各种技术。
你可能会惊讶于本书内容的跨度之大，从业务系统到数据库，从容器到安全，从社区建设到行业观察，包罗万象。同时，讲解内容又实实在在，没有很多空话，偶有没说清楚的地方，肯定会有问答环节来补充说明。因为都是群内听讲的人提问，所以问答也非常契合主题。
这就保证了本书在特定章节上，比大多数同类书要讲得透彻、明白，适合初级人员阅读。同时，又对中高级技术人员有更大的价值。我们经常说架构师对技术的把握要有深度，也要有广度。广度从何而来，只能是读万卷书，阅千套系统积累而来。本书无疑是一个很好的素材源泉。
具体的内容我不在此赘述，相信大家仔细阅读后会收获颇丰。这里我还是介绍一下背后的这群人——这个由分享者和听众共同组成的大群体，这个称为高可用架构群的组织。
我经常讲，高可用架构这些群，像极了《一代宗师》里的金楼。因为你仔细看，技术圈就是互联网时代的武林。大家聚在这里，是因为在自己的领域里有所建树，都身怀绝技面对这个世界。所以我们会看到骄傲和拼搏，也会看到争论。因为很多人也都想着，功夫是一横一竖，站着的才有资格说话，错的，躺下。
但是幸运的是，他们找到了一种方式，来平息这种内心的躁动，就是通过在群里进行分享和答疑来进行“比武”。你说你的方式可行，就来分享吧。只要你的话我能懂，只要你的回答能使我满意，我便服气。而且慢慢地，大家也都认可了这种方式，技术领域之宽广，并非一个人可以统领。而承认一个人在某一个领域比你强并不丢人，更并不意味着你不可以在另外的领域独领风骚。
随着时间的流逝，这种技术驱动的交流也慢慢发酵成了真正的友情。金楼戏里让我感动的一幕。叶问比武前，金楼里的各位师傅都出来帮忙。三姐说，八卦手黑，小心。账房说，形意拳霸道，千万别轻敌。勇哥说，追风赶月别留情，你一定得响啊。
因为过去的这些坦诚交往，那些原本会被视为对手的人，在你遇到困难的时候，可以坚定地站在你身后。而当你遇到各种行业上的新事件，也会在群里表达自己真实的声音，期待从群里接收来自各方的诤言。
一群所学为一人学，一人可顶一群人。
这种健康的氛围，在技术圈里也愈发变得可贵。现在互联网在迅猛发展，很多新的技术被发明和引入了进来，碰撞和争论在所难免。但有一些圈子却变得特别吵闹，为了一个框架，为了一个语言就可以争到头破血流，发出各种攻击和谩骂，甚至堵上事业和人品，想想实在是让人遗憾。
高可用架构的这群人，他们都是工作在各个公司的一线技术管理人员，掌握着业界先进的工程技术。但其实他们也很普通，跟你一样，每天都在默默得工作和学习。不一样的是，他们可以聚在一起，输出这样优质的内容。
他们对技术的追求，他们共同的性格特质，也许更值得你体会。如果看完本书，你能够在技术理念有进一步的思考，那肯定是比看一本书本身收获更大的。
“其实天下之大，又何止南北？勉强求全等于固步自封，在你眼中这块饼是一个武林，对我来讲是一个世界。所谓大成若缺，有缺憾才能有进步，真管用的话，南拳又何止北传呐？”
我在叶先生出生的佛山旁边，广州，脑海中不断回响这段话。
一乐环信首席架构师兼云通讯事业部总经理
推荐序2
如果去问架构师什么是架构，可能会得到很多不同的答案，每个架构师都会对“架构”有不一样的理解，当然这不分对错，数据架构、应用架构、物理架构、组织架构等都是架构，甚至不仅在计算机行业，各行各业都会有类似的角色，但我觉得有一个核心的概念是共通的：架构必定是长期的生产活动中，经过深度思考，积累下来的实践和可复用的合理抽象。
作为Tim叔的朋友，我也是Tim叔发起的高可用架构微信群的早期成员之一，看着高可用架构群一步步发展起来，聚集了一大批一线的互联网架构师一起探讨和交流技术和架构上的问题。同时这个群也是国内早的一批尝试“在线群分享”这种形式的微信群，过去技术会议的分享受限于时间和空间，在它却这种形式下变得更加灵活和轻量，同时也能更好地沉淀下来。这里不得不提到Tim叔其人，虽然我不清楚技术群分享这个形式是否为Tim独创，但是确是非常“Tim-ish”的一个形式，Tim是国内早的分布式系统和高可用架构的实践者，同时也是一个活跃的技术，Blogger，我大概从2009年开始订阅Tim叔的Blog（后端技术），上面有很多很有价值和深度的技术文章，也算是看着Tim叔的Blog成长起来的程序员。互联网的分享精神，在这里就是一个很好的体现。随着近几年国内的互联网的蓬勃发展，新技术层出不穷，行业内也涌现出了很多优秀的工程师和架构师，Tim这两年就聚集起这样的一拨人，创造一个平台，能让大家的经验互相分享，思想互相碰撞，这本书就是一个很棒的阶段性的产物。
在一名工程师在成长的过程中，是否培养出“大局观”是一个重要的转折点，而快速提升自己“大局观”的方法之一就是多观察别人是怎么做的，并从中分析优势和劣势，在你面对不同的选择时多看看别人的思考过程，见多必然识广，也许此时你并不能直接解决自己遇到的问题，但更重要的是吸取别人的经验，思考得更全面。这几年随着互联网以及移动互联网的爆发，后端技术迭代的速度很快，新技术层见叠出，从RDBMS到NoSQL再到近的NewSQL；从单模块到SOA再到微服务；从简单的脚本部署和简单的HA到容器化的自动部署及调度；从单机到分布式再到近的云和Serverless……面对琳琅满目的设计和工具，该如何做出选择，本书不会明确告诉你答案，但是会通过一篇篇实际案例和分享来拓展你的眼界和视野，在你面临选择的时候能给到你一些启发。
本书并不是面向编程初学者的书，涉及一些比较深的内容，面也很广，建议有一定经验并希望更进一步的工程师和架构师阅读，你们一定会喜欢的。
再次感谢各位分享者和架构师，也感谢Tim和高可用架构团队的工作人员！
黄东旭PingCAPCTO
2017年8月写于海南三亚
推荐序3
我开始以为这是从理论开始的一本讲高可用的书，结果我拿到电子稿后发现上来就是很多不同公司的具体高可用的架构案例，而且是精选过的案例。从案例切入，会更加直接直观地让读者去了解高可用的架构，并且也提供了非常好的可参考的实例，如果读者在自己的场景中遇到类似问题，可以直接参考。除具体案例外，本书还通过不同公司中的系统的设计、改造的经验来介绍高可用的原理和分布式的实践，这个做法也比较有特色，依然选择了从具体的实践经验和具体的实例出发，而没有去凭空介绍很多道理，实践性非常强，并且案例所涵盖的范围是非常广泛的，和第1章的案例精选一样，都来自众的公司的实践。结束了前两章对高可用架构的案例和原理的介绍后，第3章用电商架构作为一个专题点进行了展开，在体量比较大的时候，利用电商的后端架构解决高可用还是有比较大挑战的，一些电商的经验还可以移植或者转化到别的系统当中，比较有参考价值。第4章从容器和云计算切入，这对高可用来说是一个重要的基础设施，不论基于公有云还是自己在内部做私有云亦或是采用混合云，云都是现在后端绕不过去的一个话题，而说到容器，就等同与说到了Docker，其轻量化以及通过Image来快速部署应用的特点，也使得Docker得到了广泛的应用。有了容器和云的支撑，那么如何在自身运维保障上能够适配高可用的要求，则是第5章提到的内容。没有高效的、自动的、可靠的运维支撑，是很难保障我们系统的高可用的。再接下来就到了大数据与数据库的部分，做高可用也好，做水平扩展也好，有状态的节点总是难处理的，这个章节专门针对数据库层面去做了案例的分析，大数据本身不仅仅包括了状态，还包括了计算，而大数据的计算往往是单个任务比较重的，那么做到高可用的挑战和处理我们很多前台的并发更高但是处理时长短、消耗资源小的并发任务有很大不同，这也是第6章会介绍的内容。后一章，介绍的是安全和网工，这个部分本身为整体应用系统提供了安全的防护和保障，进而使得从用户层面看系统是可用的。
本书的章节设置、前后的逻辑性很强，特别让我赞叹的是全书所有章节都是具体的案例，没有大套的理论、空洞的说教，都是从具体实际案例出发来介绍，一方面会给读者更强的现场感，一方面这些一个个具体的案例都是读者可参考的，相信这本书会给读者在高可用架构方面带来更多的信息和收获。
曾宪杰现任美丽联合集团技术副总裁
推荐序4
记得我还在新浪工作的那会儿，作为一名职场工程师新人，很早就开始关注Tim的技术博客。在理想国际大厦里也常见到Tim，但那时Tim对我来说是“只可远观而不可亵玩焉”。
很多年过去，随着自己在技术上的成长，我有幸加入到Tim组织的高可用架构群里。高可用群里的一项基本规则就是：大家要积极做技术分享。当时作为相对年轻的成员，我有些焦虑，毕竟与群里的大拿比较，我做的事情似乎不够高大上。但在百度完成一段抢购类型项目后，我发现在项目中总有些值得提炼的技术可以分享，于是主动联系了Tim并表达了分享的意愿。让人意外的是，在Tim事先了解内容的情况下，我也顺利地完成了一场人气爆棚的群内技术分享，总体反馈是，效果不错！事后也的确有同学联系我，采用了我的一些思路在公司内实现了抢购方案，同样，我也从高可用架构的其他分享里升华了技术视野，自此，我感受到了技术交流的重要性。
近两年我参加了不少技术会议，翻译了技术书籍，也随着团队内不少同学尝试图文、现场的技术交流，能明显感受到技术社区的活跃以及中国技术的快速崛起。当得知高可用组织要与博文视点联合出品《高可用架构（第1卷）》一书时，我强烈支
媒体评论
这本成型于两年前的书，完整地见证了技术社交圈刚刚兴起的年代，充满了时代感，让我能够回忆起那段并不遥远的愉快历史。书中很多文章的作者在这短短两年里，已经迅速提升，成为了各个公司的骨干人员。我很愿意推荐这本书，相信它能为愿意踏上技术*的同学提供帮助。
张亮 东东架构部总监
张亮 东东架构部总监
系统的高可用架构梳理，各大互联网公司的高可用实践，能落地的高可用细节，相信不管在互联网做技术多少年，阅读本书后，你一定会有收获，推荐。
58沈剑 架构师之路作者
2017年我国移动互联网用户已经突破7亿，互联网用户可以选择的服务越来越丰富。而互联网服务的可用性，直接关乎提供这些互联网服务的公司的营收和业绩报表。众多的流量涌入互联网公司的服务器，在高并发的场景下，使用高可用架构会有效改善服务的可用性。本书汇集了业界很多领先公司在高可用方向上的实践经验，以及在各类业务场景下实现高可用架构的实操案例，希望本书能给你带来在高可用架构设计上的一些启发。
付海军 时趣互动技术总监
很高兴看到《高可用架构（第1卷）》一书的面世，更高兴看到杨卫华老师的“高可用架构”公众号还在坚持运营，这是技术社区的福音。架构的重要性不言而喻，这本书里除了我的篇章外，每篇文章都阐述了和架构相关的一个技术点，而且都包含了一线研发人员的实际经验，相信你会很感兴趣并收获多多。
霍泰稳 极客邦科技创始人兼CEO
《高可用架构（第1卷）》在讲述高可用架构的理论知识之外，更重要的是收录了众多知名互联网公司专家骨干的一线实战经验，包含了各个优秀团队在面对业界前沿的棘手问题时所做的探索和取舍，相信各位读者在读完本书之后会对架构这个话题有全新的认识。
秦迪 微博平台及大数据技术专家
在*近这两三年里，国内的技术社群飞速发展，“高可用架构”便是其中的代表，它汇聚了国内中的一批真正的技术专家，专注技术的分享和交流。这本书是现在中国互联网技术发展的一个缩影，见证了它从封闭走向分享和开放，从跟随走向参与和引领。
希望每个工程师都能读读这本书，体会技术带来的乐趣。
温铭 OpenResty Inc. 合伙人，工程师
在学习编程时，我们有很多教程类的书籍可利用，但要学习架构，就很难有教程了。而这本书的内容是直接来自一线的架构实践经验总结，虽然内容跨度比较大，但这正是在其他教程类型的书中很难学习到的，所以推荐给进阶的研发人员。另外，即便同在软件研发行业，细分起来，领域的区隔还是很大的，看看同行的一些实践经验，即便不能拿来直接用，但对解决自己面临的难题还是会有帮助的。
王渊命 青云容器平台负责人，前微博架构师，技术写作者
评论
还没有评论。