知乎后浪云到底是怎么搭起来的，聊聊背后的架构那些事儿

这篇文章最早来源于知乎官方技术团队在知乎专栏“知乎技术团队”上发表的一篇技术分享，后来被众多技术社区和自媒体转载解读，文章主要讲述了知乎如何利用容器化技术（主要是Docker）和Kubernetes（K8s）平台，从早期的物理机时代一步步构建起一个服务于内部业务、被称为“后浪云”的私有云平台的过程，它不是一蹴而就的，而是一个不断演进和解决问题的故事。

早期的痛点：物理机时代的烦恼

在还没有“后浪云”的时候，知乎的业务是直接部署在物理服务器上的，这种方式带来了很多麻烦。资源浪费很严重，一个应用可能只需要一台服务器一半的计算能力，但没办法，它必须独占一整台机器，剩下的资源就白白闲置了。部署效率非常低，开发人员想上线一个新服务，需要先提交申请，运维同事再去准备机器、安装操作系统、配置网络和环境，一套流程下来可能要花上好几天时间。环境不一致的问题很头疼，开发人员在自己电脑上测试没问题，但一到线上服务器就可能因为环境差异而出错，排查起来非常费劲。

第一步：引入Docker，解决环境一致性问题

为了解决环境不一致这个最迫切的问题,知乎技术团队首先引入了Docker，你可以把Docker想象成一个超级轻量化的“集装箱”，开发者把应用程序和它所有依赖的库、环境配置都打包进这个“集装箱”里，形成一个标准的Docker镜像，这样，无论是在开发者的笔记本电脑上，还是在测试环境或者线上服务器上，只要运行这个镜像，就能保证环境完全一样，实现了“一次构建，随处运行”，这大大减少了因环境问题导致的故障。

第二步：拥抱Kubernetes，实现资源调度和自动化

用了Docker之后,环境问题解决了，但资源管理和部署效率的问题依然存在，一大堆Docker容器散落在不同的物理机上，怎么高效地管理它们呢？某个服务访问量突然变大，需要快速增加容器实例，该在哪台机器上启动？如何让用户访问到新启动的容器？机器故障了，上面的容器怎么自动迁移到别的健康机器上？

这时候,Kubernetes（常简称为K8s）出场了，K8s就像一个智能的“云操作系统”或者“集群大脑”，它的核心工作是资源调度和自动化运维，知乎团队基于K8s构建了“后浪云”的平台层。

1. 资源池化：后浪云把公司所有的物理服务器资源（CPU、内存等）汇聚成一个大的资源池，业务部门不再需要申请整台物理机，而是直接申请“我需要多少核CPU、多少G内存”。
2. 智能调度：当开发者提交一个服务（由多个Docker容器组成）要部署时，后浪云的“大脑”（K8s的调度器）会自动在资源池里寻找最合适的服务器节点，把容器“放”上去运行，它会综合考虑节点的资源余量、分布策略等因素。
3. 自动化运维：后浪云提供了强大的自动化能力。
   • 自动扩缩容：可以设置规则，当CPU使用率超过80%时，自动增加容器实例来分担压力；当访问量下降时，自动减少实例以节省资源。
   • 自愈能力：如果后浪云检测到某个容器运行异常了，它会自动重启这个容器；如果整个服务器节点宕机了，它会自动将该节点上的所有容器迁移到其他健康的节点上重新启动，保证了服务的高可用性。
   • 灰度发布：上线新版本时，可以先只让一小部分流量切换到新版本的容器上，观察没问题后再逐步扩大范围，实现了平滑升级，降低了上线风险。

演进中的挑战与优化

搭建后浪云的过程并非一帆风顺,文章中也提到了一些挑战和相应的解决方案。

• 网络问题：如何让成千上万个在不同物理机上的Docker容器能够像在同一个局域网里一样，高效、稳定地互相通信？知乎采用了Overlay Network（叠加网络） 等技术方案来解决这个问题。
• 存储问题：有状态的服务（比如数据库）的数据如何持久化保存，并且当容器被迁移时，数据也能跟着走？这需要引入分布式存储系统来提供可靠的存储卷。
• 监控与日志：在动态调度的环境下，容器的IP和位置随时可能变化，传统的监控和日志收集方式失效了，后浪云集成了Prometheus等监控工具，并建立了统一的日志收集管道，让运维人员能够清晰地掌握整个平台的运行状态。

知乎后浪云的搭建,是一个典型的互联网公司技术架构演进案例，它的核心思路是：通过容器化技术（Docker）实现应用环境的标准化和隔离，再通过容器编排平台（Kubernetes）实现底层物理资源的池化、智能调度和运维自动化。 这套架构最终极大地提升了知乎整体的研发效率和资源利用率，为业务的快速迭代和稳定运行提供了坚实的技术基础。