知乎容器化之路的三大关键阶段
极客时间编辑部
讲述：杜力大小：1.29M时长：02:50
在近期举办的“解码腾讯云软件架构与应用”技术沙龙上，知乎容器平台高级工程师王路带来了关于知乎容器化之路的分享。据介绍，知乎从 2015 年开始全面容器化，到目前为止 99% 的业务都在容器上，基础的组件也在容器上。
提及为什么要容器化，王路表示：“当时知乎用的是纯物理机，成本比较高，资源利用率比较低。我们选的虚拟化方案，第一个就是虚拟机，就是 OpenStack，但人力维护成本还是比较高；另外虚拟机的的扩容效率也比较低。之后推出微服务，微服务和容器几乎是一脉相承的，所以我们最终确定了使用容器的方案。项目命名为 bay，就是海湾的意思。”
据王路介绍，当时他们面临三个选择，分别是 mesos、kubernetes 和 swarm，最后选择了 mesos 开始进行第一阶段的容器化改造。不过，当时只有业务的物理机是进行容器化的，基础组件并没有容器化。
第一阶段初代平台完成之后，主要支持以下几个功能：滚动升级、金丝雀发布、CI/CD 完整集成、支撑几乎全部业务、秒级自动扩容 （10->100 35s）等。
如果说第一阶段解决了业务容器化的问题，那么第二阶段就是在这个过程中又遇到了基础组件的问题，主要是 Kafka 集群管理的问题。一开始 Kafka 管理的是一个大的单集群，当时出了两个比较典型的问题，一个是 topic 的流量突然增加，引发整个集群的故障；第二个就是负载不均衡。
这一情况下如果由维护一套 Kafka 集群转成两套，成本非常高。知乎的解决办法就是对它进行容器化，定义更细粒度的调度单位和更高效的集群管理工具。
知乎最终做出的选择是对 Kafka broker 进行容器化，高效的集群管理工具则采用 kubernetes。理想状态就是在三台机器上跑三个 Kafka 集群，每一个 Kafka 的 broker 都是单独占用一个磁盘，构成三个集群。
随着业务的发展，有一些容器组越来越大，可能包含 1 千多个容器，上线一次会非常慢。而 bay 最终只能用一个口，它的速度是有上限的；第二个就是无法快速回滚；第三就是缺乏好用的运维工具；最后一点，mesos 的社区活跃度比较低。
根据这些不足，知乎考虑重建 bay 系统，目标就是提高部署速度。首先就是区分部署与发布；至于回滚，业务在部署新的代码之后，旧的代码是不销毁的，容器是实际存在的，但不对外提供服务。
在第三阶段的整体架构中，新的 bay 系统也是放在 kubernetes 上，相当于两套系统并存。目前知乎大概有 1/3 业务已经迁移到新的 bay 系统上了，快速部署在 3 秒之内就可以完成，平台的运行效率得到了很大的提高。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(2)
- 最新
- 精选
- Bird厉害
不懂学习了
收起评论