网易容器云平台的微服务化实践（一）

此文已由做者冯常健受权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

摘要：网易云容器平台指望能给实施了微服务架构的团队提供完整的解决方案和闭环的用户体验，为此从 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 服务）
○ ……

一旦决定作微服务架构，有不少现实问题摆在面前，好比技术选型、业务拆分问题、高可用、服务通讯、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试，以及调度和部署等等……这并不是一些简单招数可以化解。

做为主要编程语言是 Java 的容器服务来讲，选择 Spring Cloud 去搭配 K8S 是一个很天然的事情。Spring Cloud 和 K8S 都是很好的微服务开发和运行框架。从应用的生命周期角度来看，K8S 覆盖了更广的范围，特别像资源管理，应用编排、部署与调度等，Spring Cloud 则对此无能为力。从功能上看，二者存在必定程度的重叠，好比服务发现、负载均衡、配置管理、集群容错等方面，但二者解决问题的思路彻底不一样，Spring Cloud 面向的纯粹是开发者，开发者须要从代码级别考虑微服务架构的方方面面，而 K8S 面向的是 DevOps 人员，提供的是通用解决方案，它试图将微服务相关的问题都在平台层解决，对开发者屏蔽复杂性。举个简单的例子，关于服务发现，Spring Cloud 给出的是传统的带注册中心 Eureka 的解决方案，须要开发者维护 Eureka 服务器的同时，改造服务调用方与服务提供方代码以接入服务注册中心，开发者需关心基于 Eureka 实现服务发现的全部细节。而 K8S 提供的是一种去中心化方案，抽象了服务 （Service），经过 DNS+ClusterIP+iptables 解决服务暴露和发现问题，对服务提供方和服务调用方而言彻底没有侵入。

对于技术选型，咱们有本身的考量，优先选择更稳定的方案，毕竟稳定性是云计算的生命线。咱们并非 “K8S 原教旨主义者”，对于前面提到的微服务架构的各要点，咱们有选择基于 K8S 实现，好比服务发现、负载均衡、高可用、集群容错、调度与部署等。有选择使用 Spring Cloud 提供的方案，好比同步的服务间通讯；也有结合二者的优点共同实现，好比服务的故障隔离和熔断；固然，也有基于一些成熟的第三方方案和自研系统实现，好比配置管理、日志采集、分布式调用跟踪、流控系统等。

咱们利用 K8S 管理微服务带来的最大改善体如今调度和部署效率上。以咱们当前的状况来看，不一样的服务要求部署在不一样的机房和集群（联调环境、测试环境、预发布环境、生产环境等），有着不一样需求的软硬件配置（内存、SSD、安全、海外访问加速等），这些需求已经较难经过传统的自动化工具实现。K8S 经过对 Node 主机进行 Label 化管理，咱们只要指定服务属性 （Pod label），K8S 调度器根据 Pod 和 Node Label 的匹配关系，自动将服务部署到知足需求的 Node 主机上，简单而高效。内置滚动升级策略，配合健康检查 （liveness 和 readiness 探针）和 lifecycle hook 能够完成服务的不停服更新和回滚。此外，经过配置相关参数还能够实现服务的蓝绿部署和金丝雀部署。集群容错方面，K8S 经过副本控制器维持服务副本数 （replica），不管是服务实例故障（进程异常退出、oom-killed 等）仍是 Node 主机故障（系统故障、硬件故障、网络故障等），服务副本数可以始终保持在固定数量。

Docker 经过分层镜像创造性地解决了应用和运行环境的一致性问题，可是一般来说，不一样环境下的服务的配置是不同的。配置的不一样使得开发环境构建的镜像没法直接在测试环境使用，QA 在测试环境验证过的镜像没法直接部署到线上……致使每一个环境的 Docker 镜像都要从新构建。解决这个问题的思路无非是将配置信息提取出来，以环境变量的方式在 Docker 容器启动时注入，K8S 也给出了 ConfigMap 这样的解决方案，但这种方式有一个问题，配置信息变动后没法实时生效。咱们采用的是使用 Disconf 统一配置中心解决。配置统一托管后，从开发环境构建的容器镜像，能够直接提交到测试环境测试，QA 验证经过后，上到演练环境、预发布环境和生产环境。一方面避免了重复的应用打包和 Docker 镜像构建，另外一方面真正实现了线上线下应用的一致性。

Spring Cloud Hystrix 在咱们的微服务治理中扮演了重要角色，咱们对它作了二次开发，提供更灵活的故障隔离、降级和熔断策略，知足 API 网关等服务的特殊业务需求。进程内的故障隔离仅是服务治理的一方面，另外一方面，在一个应用混部的主机上，应用间应该互相隔离，避免进程间互抢资源，影响业务 SLA。好比绝对要避免一个离线应用失控占用了大量 CPU，使得同主机的在线应用受影响。咱们经过 K8S 限制了容器运行时的资源配额（以 CPU 和内存限制为主），实现了进程间的故障和异常隔离。K8S 提供的集群容错、高可用、进程隔离，配合 Spring Cloud Hystrix 提供的故障隔离和熔断，可以很好地实践 “Design for Failure” 设计哲学。

服务拆分的好坏直接影响了实施微服务架构的收益大小。服务拆分的难点每每在于业务边界不清晰、历史遗留系统改造难、数据一致性问题、康威定律等。从咱们经验来看，对于前两个问题解决思路是同样的：1）只拆有肯定边界能独立的业务。2）服务拆分本质上是数据模型的拆分，上层应用经得起倒腾，底层数据模型经不起倒腾。对于边界模糊的业务，即便要拆，只拆应用不拆数据库。

如下是咱们从主工程里平滑拆出用户服务的示例步骤：

1.将用户相关的 UserService、UserDAO 分离出主工程，加上 UserController、UserDTO 等，造成用户服务，对外暴露 HTTP RESTful API。
2.将主工程用户相关的 UserService 类替换成 UserFaçade 类，采用 Spring Cloud Feign 的注解，调用用户服务 API。
3.主工程全部依赖 UserServce 接口的地方，改成依赖 UserFaçade 接口，平滑过渡。

通过以上三个步骤, 用户服务独立成一个微服务，而整个系统代码的复杂性几乎没有增长。

数据一致性问题在分布式系统中广泛存在，微服务架构下会将问题放大，这也从另外一个角度说明合理拆分业务的重要性。咱们碰到的大部分数据一致性场景都是能够接受最终一致的。“定时任务重试+幂等” 是解决这类问题的一把瑞士军刀，为此咱们开发了一套独立于具体业务的 “分布式定时任务+可靠事件” 处理框架，将任何需保证数据最终一致的操做定义为一种事件，好比用户初始化、实例重建、资源回收、日志索引等业务场景。以用户初始化为例，注册一个用户后，必须对其进行初始化，初始化过程是一个耗时的异步操做，包含租户初始化、网络初始化、配额初始化等等，这须要协调不一样的系统来完成。咱们将初始化定义为一种 initTenant 事件，将 initTenant 事件及上下文存入可靠事件表，由分布式定时任务触发事件执行，执行成功后，清除该事件记录；若是执行失败，则定时任务系统会再次触发执行。对于某些实时性要求较高的场景，则能够先触发一次事件处理，再将事件存入可靠事件表。对于每一个事件处理器来讲，要在实现上确保支持幂等执行，实现幂等执行有多种方式，咱们有用到布尔型状态位，有用到 UUID 作去重处理，也有用到基于版本号作 CAS。这里不展开说了。

当业务边界与组织架构冲突时，从咱们的实践经验来看，宁愿选择更加符合组织架构的服务拆分边界。这也是一种符合康威定律的作法。康威定律说，系统架构等同于组织的沟通结构。组织架构会在潜移默化中约束软件系统架构的形态。违背康威定律，很是容易出现系统设计盲区，出现 “两无论” 互相推脱的局面，咱们在团队间、团队内都碰到过这种状况。
nbsp;
本文是《网易容器云平台的微服务化实践》系列文章的第一篇，介绍了容器技术和微服务架构的关系，咱们作容器云平台的目的，以及简单介绍了网易云容器服务基于 Kubernetes 和 Spring Cloud 的微服务化实践经验。限于篇幅，有些微服务架构要点并未展开，好比服务通讯、服务发现和治理、配置管理等话题；有些未说起，好比分布式调用跟踪、CI/CD、微服务测试等话题，这些方面的实践经验会在后续的系列文章中再作分享。实践微服务架构的方式有千万种，咱们探索并实践了其中的一种可能性，但愿能够给你们一个参考。

网易云计算基础服务深度整合了 IaaS、PaaS 及容器技术，提供弹性计算、DevOps 工具链及微服务基础设施等服务，帮助企业解决 IT、架构及运维等问题，使企业更聚焦于业务，是新一代的云计算平台，点击可免费试用。

文章来源： 网易云社区