摘要：网易云容器平台期望能给实施了微服务架构的团队提供完整的解决方案和闭环的用户体验，为此从 2016 年开始，我们容器服务团队内部率先开始进行 dogfooding 实践，看看容器云平台能不能支撑得起容器服务本身的微服务架构，这是一次很有趣的尝试。
一旦决定做微服务架构，有很多现实问题摆在面前，比如技术选型、业务拆分问题、高可用、服务通信、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试，以及调度和部署等等，这并非一些简单招数能够化解。实践微服务架构的方式有千万种，我们探索并实践了其中的一种可能性，希望可以给大家一个参考。本文是《网易容器云平台的微服务化实践》系列文章的第一篇。
Docker 容器技术已经过了最早的喧嚣期，逐渐在各大公司和技术团队中应用。尽管以今天来看，大家从观念上已经逐渐认可 “将镜像定义为应用交付标准，将容器作为应用运行的标准环境” 的观点，但还是有相当一部分人在迷惑容器技术作为一个标准，应该怎么落地，怎样才能大规模线上应用，怎么玩才能真正解放生产力，促进软件交付效率和质量？答案其实在应用的架构当中。
微服务架构不是因 Docker 容器技术而生，但确实是因容器技术而火。容器技术提供了一致性的分发手段和运行环境，使得只有微服务化后的应用架构，才能配合容器发挥其最大价值。而微服务化架构引入了很大的复杂性，只有应用容器化以及规模化的容器编排与调度才能避免运维效率下降。容器技术和微服务化架构之间本是一种相辅相成的互补关系。
网易容器云平台的前身是网易应用自动部署平台 (OMAD)，它能够利用 IaaS 云提供的基础设施，实现包括构建和部署一体化在内的整个应用生命周期管理。2014 年，以 Docker 为代表的容器技术进入大众视野，我们惊喜地发现，容器技术是自动部署平台从工具型应用进化为平台型应用过程中最重要的一块拼图。原本用户需要初始化主机，然后借助自动部署平台完成应用的构建和部署。引入容器技术之后，用户从功能开发到测试到一键部署上线，整个应用交付过程中不用关心主机初始化、主机间通信、实例调度等一系列应用之外的问题。这简直是信仰 DevOps 的人的福音。
我们从 2015 年开始探索容器技术的最佳实践方式，从当初 “胖容器” 与容器集群的产品形态，到后来关于有状态和无状态服务的定义，以及如今的新计算与高性能计算，我们一直在思考并丰富着容器技术的应用场景。无论产品形态如何调整，容器云平台的核心概念一直是 “微服务”，通过微服务这一抽象提供高性能的容器集群管理方案，支持弹性伸缩、垂直扩容、灰度升级、服务发现、服务编排、错误恢复、性能监测等功能，满足用户提升应用交付效率和快速响应业务变化的需求。网易云容器平台期望能给实施了微服务架构的团队提供完整的解决方案和闭环的用户体验，为此从 2016 年开始，我们容器服务团队内部率先开始进行 dogfooding 实践，一方面检验容器云平台能不能支撑得起容器服务本身的微服务架构，另一方面通过微服务化实践经验反哺容器云平台产品设计，这是一次很有趣的尝试，也是我们分享容器云平台微服务化架构实践的初衷。
在谈容器服务的微服务架构实践之前，有必要先把网易云容器服务大致做个介绍。目前网易云容器服务团队以 DevOps 的方式管理着30+微服务，每周构建部署次数 400+。网易云容器服务架构从逻辑上看由 4 个层次组成，从下到上分别是基础设施层、Docker 容器引擎层、Kubernetes （以下简称 K8S）容器编排层、DevOps 和自动化工具层：
容器云平台整体业务架构如下：
抛开容器服务具体业务不谈，仅从业务特征来说，可以分成以下多种类型（括号内为举例的微服务）：
面向终端用户 （OpenAPI 服务网关）、面向服务（裸机服务）
同步通信（用户中心）、异步通信（构建服务）
数据强一致需求（etcd 同步服务）、最终一致需求（资源回收服务）
吞吐量敏感型（日志服务）、延时敏感型（实时服务）
CPU 计算密集型（签名认证中心）、网络 IO 密集型（镜像仓库）
在线业务（Web 服务）、离线业务（镜像检查）
批处理任务（计费日志推送）、定时任务（分布式定时任务）
长连接（WebSocket 服务网关）、短连接（Hook 服务）
……