《SRE Google运维解密》读书笔记(部分)

= 716

我之所以了解到这本书,是因为前面看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的发布工程哲学主要有以下几点构成。首先是自服务模型,各个团队独立发布,且使用自动构建和自动发布。其次是追求速度,有的团队甚至使用“测试通过即发布”。第三是封闭性,第三方库和构建工具是包含在构建任务内部的,换言之构建工具被放置在与被构建程序同一个源代码仓库中。最后是策略和流程,整个发布工程被分割为不同的阶段,特定的人能够执行特定的操作(好像和所说的自动化有点矛盾)。

在“简单化”的章节,描述了一些通俗的例子。比如说,减少意外复杂度(难以评估的改变),删除不需要的代码而不是注释,谨慎使用功能开关,把“负代码行”作为一个工作量指标。

这本书之后的内容就到了最佳实践的内容,这一部分中大多数的内容我目前都无法细致理解,估计要过几年再来研究了。而负载均衡和共识系统的内容,我可能在后续专门研究一下。因为这部分内容深入说来,还是有很多理论或者底层知识的。

发表评论