我之所以了解到这本书，是因为前面看Kubenetes的时候，作者提到Google使用的Borg集群管理系统。据称，Google在05年之前就开始使用Borg集群管理系统。对于这一点，我其实有些惊讶的。毕竟服务器集群编排系统其实也就是最近几年才逐渐兴起的。然后我查相关资料的时候，发现了这本书。草草翻阅了一下目录，发现这本书其实是属于DevOps的书籍。
最近几年，后端出了很多新鲜的名词，比如微服务（micro service），DevOps，Docker容器，容器编排等等。看起来好像是五花八门，但事实上都是多位一体的。关键原因是互联网服务的规模增长和标准提高，分布式后端系统不断普及。在分布式后端系统中，micro service是一种科学的架构，按照服务拆分完成分布式的架构模型。而分布式系统本身的复杂度是很高的，传统的运维方式难以保证业务的稳定，而DevOps就是为了改善这种问题。此外，分布式系统的环境差异是客观存在的，Decker则可以很大程度上消除环境差异，使得分布式系统中的应用部署和运行更加一致和简单。最后，分布式系统可能存在地理位置的隔离，或者是通过局域网络连接，所以它的管理是存在很大难度的，因此需要类似于Kubenetes的这种技术的帮助。
上面我算是谈了一点对现代运维的一些理解。接下来，我就按照该书的内容，总结一下相关的知识点。说实话，运维本身是件很复杂的工作，有很多琐碎的内容。这本书也不能幸免，它的章节之间是挺独立的。因此，我的这个笔记会显得比较凌乱。
1. 拥抱风险，服务质量目标（第三章，第四章）：
Google并不想建立一个非常可用的服务，服务的设计可靠性与成本、服务特性等等都是相关的。举例来说，如果提高服务质量的边际开发成本高于期望的收益，就可以放弃这种计划。
一个比较好的例子——Google+中与用户隐私相关的数据是存放在spanner中的，而可选的数据（不重要的但是能够提高用户体验的数据）放在BigTable中。这无疑是明智的选择，Spanner系统的使用成本本身就高过BigTable，而且Spanner提供的强一致性也带来了较高的延迟。
此外，Google建立了明确的服务质量目标体系，简单来说就是服务质量严格量化。任何服务本身都存在一个实时的服务质量指数，这个指数可以用来指导开发和发布的步调。如果当前服务质量指数低于预期，就应该采取更加保守的开发和发布计划，以提高服务质量指数。
Google并不追求所谓的极致服务质量，甚至还会主动停机以测试服务的设计。一个例子是Chubby服务的计划内停机，Chubby服务提供分布式锁服务，Google有很多服务都是建立在Chubby之上的。然而Chubby的可靠性太高，为了避免上层服务对Chubby的可靠性过度依赖，Chubby服务会在满足规定服务质量的前提下，进行停机测试以推动上层服务的改进。
2. 监控与自动化系统（第六章，第七章）
Google对监控系统的构建非常重视，一个缺乏良好监控系统的后端就如同一个黑盒，很多工作都无从谈起。而监控系统本身可以用来分析长期趋势、跨时间比较、报警、方便构建可视化监控页面以及提供临时性的回溯分析。第七章介绍了以自动化的方式实现集群上线，内容比较粗略。
任何的服务都会提供http端口供服务监控使用，这个类似于Spring Boot actuator的方式。
3. 自动构建发布与简单化原则（第八章，第九章）
Google的发布工程哲学主要有以下几点构成。首先是自服务模型，各个团队独立发布，且使用自动构建和自动发布。其次是追求速度，有的团队甚至使用“测试通过即发布”。第三是封闭性，第三方库和构建工具是包含在构建任务内部的，换言之构建工具被放置在与被构建程序同一个源代码仓库中。最后是策略和流程，整个发布工程被分割为不同的阶段，特定的人能够执行特定的操作（好像和所说的自动化有点矛盾）。
在“简单化”的章节，描述了一些通俗的例子。比如说，减少意外复杂度（难以评估的改变），删除不需要的代码而不是注释，谨慎使用功能开关，把“负代码行”作为一个工作量指标。
这本书之后的内容就到了最佳实践的内容，这一部分中大多数的内容我目前都无法细致理解，估计要过几年再来研究了。而负载均衡和共识系统的内容，我可能在后续专门研究一下。因为这部分内容深入说来，还是有很多理论或者底层知识的。
发表评论