百度的百万服务治理之道
极客时间编辑部
讲述：丁婵大小：2.16M时长：04:44
在面对规模庞大且复杂的架构时，如何通过高效的基础设施和架构工程，让复杂的业务更简单呢？在刚刚结束的 QCon 北京全球软件开发大会上，百度资深研发工程师田健从服务治理和服务混部两方面介绍了大规模架构的服务管理之道。以下为重点内容。
从服务治理角度来看，应对大规模服务架构的首要问题是如何解决服务的快速、稳定的部署。对于一定规模的正式服务，需要通过分级发布流程来控制部署频率，保证服务整体稳定性和高可用。
另外，百度还需要全网分发的数据能力。当部署规模很小的时候，可以通过简单的命令实现远程数据拉取，并且通常源文件部署在单机系统上。而应对超大规模的数据分发过程，单机的网络、磁盘 I/O 等性能会出现瓶颈，稳定性也存在疑虑，导致整个分发系统失效。因此，源文件至少要保存在分布式文件系统来支撑更高的读取并发、提供更高的可用性，另一方面，则要借助 P2P 协议的快速分发能力，实现数据的全网高并发和高效传输。
前面提到，百度既希望服务是分级发布的，又需要全网快速分发，这就出现了速度和风险的悖论。因此还需要额外多考虑一点，就是将数据的分发和数据的生效逻辑拆开来做。因为在服务部署过程中，数据分发占用的时间要远远大于数据的生效时间。这样一来，全部服务可以通过 P2P 的传输实现快速的数据分发，同时又可以根据需求指定生效的分级流程，实现风险和速度的折衷。
解决了数据分发的过程，当然还要关注它的结果。一方面，各分发节点需要做数据校验，保证数据正确，另一方面，针对大规模数据分发，百度更关注数据如何保证一致性。传统的分发流程中，通过分发模块直接做数据的分发给各个实例，这就带来两个问题：
全部的分发流程由分发总控模块统一负责，容易出现性能瓶颈；
每一次分发过程都要进行过程跟踪，并跟进异常处理，这在高频次、大规模的分发场景下会耗费巨大人力。
因此，需要把面向过程的分发改造为面向结果的分发流程。在面向结果的分发流程中，百度设计了一个服务的 handler，它持有服务当前的数据和版本描述，并且接收来自分发总控的预期数据描述，并根据两者描述的 diff 点，不断的执行相应的数据传输动作。好处是：
分发模块仅分发数据描述，而不是数据文件，描述文件体量很小，拥有着极高的成功率；
一旦 handler 接收到了预期数据描述，便会自驱的让服务的数据向预期状态靠拢，持续的进行数据的获取直到描述成功，则不需要人为干预——包括故障重传和异常处理，即可实现数据的最终一致。
回滚的流程设计是服务部署的又一大痛点。针对大规模服务部署流程，需要一套快速的回滚流程，才能保证风险可控、损失最低。由于数据的分发是服务部署过程中耗时最长的一块，所以首先要考虑如何避免重复的下载。
一个合理的想法是保留多个版本，一般来讲，为了支持快速回滚，保留两个版本即可，这样磁盘占用空间翻倍。好在对于服务器的成本组成而言，冷备磁盘的开销是极低的，因此用空间换时间是可行的。但是仅保留多个版本是不够的，还需要有数据切换的流程设计。如果采用的是 cp 或者 mv 的方式，很容易出现长尾，因此更好的办法是通过软链来实现。
如果从长远考虑，可以采用共享文件系统来实现这个功能，百度大部分服务的数据仅在启动过程中加载，之后就不再使用，通过共享存储把这部分数据按需 mount，按需加载，加载完成后释放，则备份的成本就大大的降低，且生效速度不变。
如上就是主要内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论