轻量ServiceMesh实践-InfoQ



 写点什么

UCloud 作为一家 To B 的公有云服务商，我们的 CTO 莫显峰经常说：“研发团队最首要的任务是提供稳定的服务，然后才是提供符合客户需求的、易用和低成本的产品”。但事实是，在提供稳定云服务的同时，面对快速发展的客户业务场景，我们还需要不断 “拥抱变化”。

Max Kanat-Alexander 在《简约之美：软件设计之道》（Code Simplicity）中提出的软件设计的 6 条法则恰到好处的描述了这一矛盾的事实，具体内容如下：

软件的目的是帮助他人；
相比降低开发成本，更重要的是降低维护成本；
变化定律：软件存在的时间越久，它的某部分需要变化的可能性越大；
缺陷定律：软件出现缺陷的可能性，正比于你对它所做修改的程度；
简洁定律：软件任一部分的维护难度，正比于该部分的复杂程度；
测试定律：你对软件行为的了解程度，等于你真正测试它的程度。

正像法则 1、3、4 和 6 所说的软件的目的就是满足客户的需求，而随着时间的推移，用户需求总会改变；伴随着用户需求的改变，软件也需要适应新的需求而做修改，修改必然会引入缺陷；如果要排除缺陷就必须进行测试。

但目前软件行业的现状大部分面临这样的问题，即无论花多大的成本去测试，真正的用户行为背后的需求总是不可能被完全满足的，缺陷总是会有的，这时我们最后的安全网就是“灰度发布”（又名“金丝雀发布”）。在采用用户真实行为作为终极测试的同时，通过控制变更范围尽可能的减少风险；一旦真的有缺陷可以快速回滚，尽可能以最大程度降低影响。

为何采用 ServiceMesh 实现灰度发布

Service Mesh 是用来处理各服务间通信的基础设施层。它主要通过构建云原生应用程序的各种复杂拓扑结构来完成传递请求。实际上，Service Mesh 通常与应用程序代码一起部署轻量级网络代理的阵列来实现请求。

在 ServiceMesh 之前，我们已经采用了 APIGateway 来实现灰度发布，但 APIGateway 通常仅部署在用户流量的入口，完全灰度发布就需要完整地部署两套系统。但是在微服务时代，任何一个微服务发生变更都需要完整地部署两套系统，这不仅成本很高而且严重影响了产品变更的速度。

而 ServiceMesh 正好可以解决这些问题，它的应用类似于将 APIGateway 部署到本地，同时提供了集中化控制，极大地简化了灰度发布的实现流程、降低了变更成本、同时加快了产品发布的进度。

为何采用轻量 ServiceMesh

正如敖小剑在《DreamMesh 抛砖引玉》系列文章中提到的：“Service Mesh 的发展进程，当前还处于前景虽然一致看好，但是脚下的路还处于需要一步一步走的早期艰难阶段。由于 Istio 和 Conduit 的尚未成熟，造成目前 Service Mesh 青黄不接的尴尬局面。” 到底该如何让 ServiceMesh 落地，这也是我们在 2017 年 10 月选择了 ServiceMesh 之后面临的难题。

Istio 可以提供一个完整的解决方案，通过为整个服务网格（ServiceMesh）提供行为检测和操作控制来满足微服务应用程序的各种需求。它在服务网络中提供了许多关键功能例如：流量管理、可观察性、策略执行、服务身份和安全、平台支持、集成和定制。

事实上我对 Istio 的流量管理 DSL 非常满意，同时通过评测也能够接受 Envoy 的性能开销，从当时来看 Istio 确实是一个非常优秀的且是唯一的候选者。但敖小剑在《DreamMesh 抛砖引玉》描述的几个问题，也困扰着我是否采用 Istio:

1. Ready for Cloud Native?

我们目前并没有采用 K8S，事实上我们所开发的 IaaS 控制面程序，本身就和 K8S 的功能类似。

2. 如何从非 Service Mesh 体系过渡到 Service Mesh？

我们有大量既有的服务。

3. 零侵入的代价

K8S 的网络方案已经是非常复杂且性能堪忧了，再通过 IPTables 来透明引流确实是雪上加霜，给未来的运维、Trouble-Shooting 带来了很高的复杂度。

4. 网络通讯方案

目前我们主要使用 gRPC 和 HTTP，但仍有数据库服务等业务不适合跑在 K8S 中，而 K8S 的网络方案需要能够兼容现有的数据库等业务。

如何实现轻量 ServiceMesh

Istio 在逻辑上可以分为数据面板和控制面板，这两部分的具体功能如下：

数据面板由一组智能代理（Envoy）组成，代理部署为 sidecar，调解和控制微服务之间所有的网络通信。
控制面板负责管理和配置代理来路由流量，以及在运行时执行策略。

下图是构成每个面板的不同组件：

经过一些代码级别的 Research 之后，我们最终选择了将 Pilot 从 Istio 中剥离出来，脱离 K8S 运行的轻量级 ServiceMesh 方案。

1.从 Istio 中剥离 Pilot 和 Envoy

在 Istio 中 Pilot 作为 Envoy 的控制面板提供集中式流量管理功能的模块，这是实现灰度发布必不可少的功能，事实上也是 ServiceMesh 的核心功能。Mixer 提供访问策略和控制功能，Istio-Auth 提供安全认证功能，但在 UCloud 的内网环境下，我们可以将这两个模块去掉。

得益于 Pilot 的良好设计， ETCD Platform 很容易实现，进而从 ETCD 获取 Service 和 ServiceInstance 信息。然后我们重写了 Pilot 的 main.go，保留了 Pilot 的 model、proxy 和 proxy/envoy 模块;删除其他的 Platform 仅保留新增的 ETCD Platform。

最后我们在保留完整的 Istio DSL 支持的同时，得到了完全脱离 K8S 运行和编译的 Pilot。同时我们将 Pilot 和 ETCD gRPC naming and discovery 做了深度整合，自动剔除没有在线的 ServiceInstance 信息。

2.采用 docker-compose 管理 container 实现 sidecar

我们仍然采用 container 的方式打包和部署微服务，但采用 Host 的网络方式简化了现存服务的网络通信方式。为了实现 Envoy 的 sidecar 部署，我们采用 docker-compose 模拟 k8s 的 POD，管理服务间的依赖关系。通过实现一个简单的服务管理、版本管理、集群管理、路由策略管理层，为集群中的每台 Node（VM 或物理服务器）生成 docker-compose 配置文件，从而实现每台 Node 的服务部署和管理。

最后针对 HTTP 1.0、HTTP 2.0 和 gRPC 的 RPC 方式，采用显式代理而不是 IPTables 透明引流和 Envoy 集成。