首页 > 科技 > 计算机 > 网络与互联网

高可用架构（第1卷）

作译者：高可用架构社区

出版时间：2017-10 千字数：788 版次：01-01 页数：652

开本：16开装帧： I S B N ：9787121314667

换版：

纸质书定价：￥108.0

库存:有

分享到：

共有图书评论0条【查看评论摘要】

看了又看

{{data.bookName}}

￥{{data.price}}

内容简介

前言

上架建议

作者简介

编辑推荐

音视频专区

第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 重构不是万能药.392
5.5.4 写好代码很难.393
5.5.5 悲观的结语394
秦 迪／5.6 系统运维之评价代码优劣的方法395
5.6.1 什么是好代码.395
5.6.2 结语403
5.6.3 参考阅读403
秦 迪／5.7 系统运维之如何应对烂代码404
5.7.1 改善可维护性.404
5.7.2 改善性能与健壮性409
5.7.3 改善生存环境.412
5.7.4 个人感想414
第6 章 大数据与数据库415
王 劲／6.1 某音乐公司的大数据实践.415
6.1.1 什么是大数据.415
6.1.2 某音乐公司大数据技术架构418
6.1.3 在大数据平台重构过程中踩过的坑425
6.1.4 后续的持续改进.430
王新春／6.2 实时计算在点评.431
6.2.1 实时计算在点评的使用场景431
6.2.2 实时计算在业界的使用场景432
6.2.3 点评如何构建实时计算平台433
6.2.4 Storm 基础知识简单介绍.434
6.2.5 如何保证业务运行的可靠性436
6.2.6 Storm 使用经验分享438
6.2.7 关于计算框架的后续想法442
6.2.8 疑问与解惑442
王卫华／6.3 百姓网Elasticsearch 2.x 升级之路.446
6.3.1 Elasticsearch 2.x 变化446
6.3.2 升级之路448
6.3.3 优化或建议451
6.3.4 百姓之道452
6.3.5 后话：Elasticsearch 5.0453
6.3.6 升级2.x 版本成功，5.x 版本还会远吗454
董西成 张虔熙／6.4 Hadoop、HBase 年度回顾457
6.4.1 Hadoop 2015 技术发展457
6.4.2 HBase 2015 年技术发展460
6.4.3 疑问与解惑466
常 雷／6.5 解密Apache HAWQ——功能强大的SQL-on-Hadoop 引擎.469
6.5.1 HAWQ 基本介绍469
6.5.2 Apache HAWQ 系统架构.472
6.5.3 HAWQ 中短期规划.479
6.5.4 贡献到Apache HAWQ 社区479
6.5.5 疑问与解惑480
萧少聪／6.6 PostgresSQL HA 高可用架构实战.482
6.6.1 PostgreSQL 背景介绍.482
6.6.2 在PostgreSQL 下如何实现数据复制技术的HA 高可用集群483
6.6.3 Corosync+Pacemaker MS 模式介绍484
6.6.4 Corosync+Pacemaker M/S 环境配置485
6.6.5 Corosync+Pacemaker HA 基础配置488
6.6.5 PostgreSQL Sync 模式当前的问题492
6.6.6 疑问与解惑492
王晶昱／6.7 从NoSQL 历史看未来.495
6.7.1 前言495
6.7.2 1970 年：We have no SQL496
6.7.3 1980 年：Know SQL 497
6.7.4 2000 年：No SQL .502
6.7.5 2005 年：不仅仅是SQL 504
6.7.6 2013 年：No，SQL .505
6.7.7 阿里的技术选择.505
6.7.8 疑问与解惑506
杨尚刚／6.8 MySQL 5.7 新特性大全和未来展望.508
6.8.1 提高运维效率的特性508
6.8.2 优化器Server 层改进.511
6.8.3 InnoDB 层优化513
6.8.4 未来发展517
6.8.5 运维经验总结.518
6.8.6 疑问与解惑519
谭 政／6.9 大数据盘点之Spark 篇521
6.9.1 Spark 的特性以及功能521
6.9.2 Spark 在Hulu 的实践.525
6.9.3 Spark 未来的发展趋势528
6.9.4 参考文章530
6.9.5 疑问与解惑530
萧少聪／6.10 从Postgres 95 到PostgreSQL 9.5：新版亮眼特性532
6.10.1 Postgres 95 介绍532
6.10.2 PostgresSQL 版本发展历史533
6.10.3 PostgresSQL 9.5 的亮眼特性534
6.10.4 PostgresSQL 还可以做什么544
6.10.5 疑问与解惑547
毕洪宇／6.11 MongoDB 2015 回顾：全新里程碑式的WiredTiger 存储引擎551
6.11.1 存储引擎的发展551
6.11.2 复制集改进.555
6.11.3 自动分片机制556
6.11.4 其他新特性介绍556
6.11.5 疑问与解惑.558
王晓伟／6.12 基于Xapian 的垂直搜索引擎的构建分析561
6.12.1 垂直搜索的应用场景561
6.12.2 技术选型.563
6.12.3 垂直搜索的引擎架构564
6.12.4 垂直搜索技术和业务细节.566
6.12.5 疑问与解惑568
第7 章 安全与网络572
郭 伟／7.1 揭秘DDoS 防护——腾讯云大禹系统572
7.1.1 有关DDoS 简介的问答.574
7.1.2 有关大禹系统简介的问答575
7.1.3 有关大禹系统硬件防护能力的问答576
7.1.4 有关算法设计的问答577
7.1.5 大禹和其他产品、技术的区别.578
冯 磊 赵星宇／7.2 App 域名劫持之DNS 高可用——开源版
HttpDNS 方案详解580
7.2.1 HttpDNSLib 库组成.581
7.2.2 HttpDNS 交互流程582
7.2.3 代码结构583
7.2.4 开发过程中的一些问题及应对.586
7.2.5 疑问与解惑593
马 涛／7.3 CDN 对流媒体和应用分发的支持及优化595
7.3.1 CDN 系统工作原理.595
7.3.2 网络分发过程中ISP 的影响602
7.3.3 防盗链.603
7.3.4 内容分发系统的问题和应对思路604
7.3.5 P2P 穿墙打洞607
7.3.6 疑问与解惑609
马 涛／7.4 HTTPS 环境使用第三方CDN 的证书难题与最佳实践611
蒋海滔／7.5 互联网主要安全威胁分析及应对方案613
7.5.1 互联网Web 应用面临的主要威胁613
7.5.2 威胁应对方案.616
7.5.3 疑问与解惑624

推荐序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卷）》一书时，我强烈支持，能够让更多的人学习到高可用组织这几年的积累，这是让人兴奋的！虽然本书中我分享的部分已经是两年前的方案，但现在看来，其中的设计思想与问题思考依然有参考价值。在得到博文视点送来的样书时，我又重新阅读了书中一些大拿的技术分享，反倒相比之前通过手机阅读文章有了更多的收获！
　　所以，这本高可用架构一书，一定可以作为你技术进阶路上常伴左右的好书！
　　吕毅链家大数据部负责人
　　前言　　
　　成为一名优秀的架构师需要哪些条件？首先需要有扎实的编程理论基础，对软件运作的原理以及算法有深入的理解；其次还需要有丰富的实践，能够将理论与实际相结合。除此之外，从他人优秀的实践经验中学习，是成为卓越架构师最有效的方法。笔者在刚开发微博之初，国内并没有类似社交网络的技术经验，但在国外，Facebook、Twitter等公司的工程师发表的相关实践文章，给了笔者所在团队架构师很多启发，团队也顺利地搭建了自己的架构，成功应对了业务的飞速增长。
　　搭建高并发及高可用大型系统长期都是业界难题，Twitter在创建之初，也多次出现不稳定甚至宕机的现象。不少架构师可能有同感，大型系统中任何一个小的模块设计不慎，就可能会导致部分用户访问失败，甚至全站不能访问的后果，给用户体验带来巨大的伤害。因此在微博核心系统中，团队中的架构师将系统可用性作为设计的首要考虑因素，如履薄冰，一路走来，终于在可用性方面跟同类产品相比取得了更好的成绩。类似的，系统可用性也应该是大部分互联网系统架构最基本的要求，这也是笔者发起及参与高可用架构社区的原因。
　　系统的可用性在过去、现在以及未来都是架构领域最重要的一个环节，但是相关的知识并没有太多现成的渠道可以获取。物以类聚，人以群分，高可用架构技术社区聚集了业界关注互联网架构的人群，并将各大一线公司具有丰富经验的架构师在社区的分享沉淀成本书中的文章。此外社区也举办全国各地架构主题的技术沙龙、每年一度的全球互联网架构大会（thegiac.com）以及以高并发为主题的编程竞赛活动，是学习及了解架构最有效的圈子。本书内容是高可用架构社区众多讲师对架构领域内容的一个阶段总结，也是社区长期活动的一个结晶。
　　带给我们架构方面启发的未必需要长篇大论，像上面提到的各种形式的偏重实践的架构总结与思考的文章，往往会带给我们更多帮助。无独有偶，短小的技术启迪文章在历史上也广受欢迎，笔者喜欢的《编程珠玑》一书中就提到，Jon Bentley在《ACM通讯》发表的有关编程的短文竟然成为了该学术期刊的王牌栏目之一，给工程师带来的启发一直影响至今。希望本书中各种架构设计思想，也能够长期伴随读者的技术职业生涯。
　　本书感谢Carson、陈刚、杜日旭、方圆、付海军、郭军、国忠、胡淼、计盛宇、李庆丰、刘世杰、刘伟、刘芸、吕涛、莫俊彬、秋翾、邓启明、苏传朋、苏小勇、四正、王杰、熊炼、侠天、余长洪、永莉、叶青、尹雯玉、魏佳、曾健生、臧秀涛等高可用架构志愿者对内容的大力贡献（按姓名拼音为序，由于篇幅关系所有志愿者未能全部列出），如果没有他们出于技术的热爱对优秀架构思想分享的推动，也不会有本书的内容。在此，对上述所有付出时间的志愿者表示由衷的感谢。
　　杨卫华 微博研发副总经理,高可用架构技术社区共同发起人
　　2017.9.26

查看更多 > 图书评论

暂无评论

发表图书评论

评论标题：
评论内容：
验证码：: 看不清楚
点击刷新
: 您还没有登录，请登录后再评论。
点击“登录”

购买过本书的顾客还买过

{{data.bookName}}

￥{{data.price}}