Service mesh 原理与实践（十九）- 如何自己动手用 Go 语言实现一套 Service Mesh 架构

Posted 2021-09-12 云世

云世  公众号

在“自己动手用 Go 实现 Service Mesh”这个大的模块中，会带你动手用 Go 语言实现一套简单的 Service Mesh 系统，以加强你对 Service Mesh 原理的掌握和理解。在编写代码之前，这一讲我们先来讲一下项目背景，包括为什么要进行自研、自研 Service Mesh 的优势、自研 Service Mesh 可以解决哪些问题，以及项目框架的初步搭建等内容。

首先，我们先来看一下这个项目的背景。假定你所在的 B 公司目前已经初具规模，正在进行从单体服务到微服务的初步拆分，公司的主要语言为 Go 语言，同时存在 Python、Node.js、php 等多种语言。

项目背景

公司的 X 项目目前已经初具规模，随着人员的扩张，从单体服务拆解到了多个子服务。但现在遇到了一些问题，急需解决方案。该项目目前面临如下困难。

• 入口层缺乏统一的系统网关：多个服务同时对外暴露，无法进行统一的登录验证、加/解密等功能，只能在各个对外暴露的服务中单独实现，无法进行统一的维护。

• 存在雪崩现象：某一个核心微服务出现故障后，导致级联故障，依赖的服务因为响应延时变高，都将出现故障，最终导致整站故障。

• 无法处理突发流量：很多时候因为运营活动，前期没有配合提前扩容资源, 导致服务被突发流量打挂。

• 内部通过内网集中网关调用：内部通过统一的网关调用，一旦内部集中网关出现问题，导致所有服务出现故障，继而引起整站故障。

• 项目可观测性不足，问题排查困难：各个服务自己实现监控指标，没有统一的监控，随着服务数量增多，问题越来越难以排查。

鉴于以上多种问题，已经影响了线上 App 的稳定性，急需技术手段解决。

下面我们针对上述问题，进行技术选型，调研以下几种解决方案，包括微服务框架、开源 Service Mesh 方案、自研 Service Mesh 方案。

以下三种方案，通过服务治理的方式，都可以解决上述问题，其中微服务框架需要再引入一个开源系统网关或者用框架实现聚合层。下面我们来看几种常见的框架选型。

技术选型 

微服务框架

【了解更多DDD系列课程，搜索  云世   公众号获取】

​​​​​​​

微服务框架在 Web 框架的基础上，增加了服务治理、注册发现、可观测性、负载均衡、RPC 等多种功能，目的是提高微服务架构的稳定性。 

优点：

• 通过服务发现的方式直接调用 upstream 服务，无须经过中间代理层，性能高；

• 微服务框架相对比较成熟。

缺点：

• 框架维护升级成本高，微服务的拆分会导致服务数量非常多，一旦框架发布，后续升级几乎不可能完成；

• 旧服务接入困难，修改代码成本高；

• 语言相关，一般情况下只能维护一种语言的微服务框架，对于小众语言无法支持。

总结：

相对来说 Go 语言的微服务框架并不算丰富，更多框架还停留在 Web 方面，比如 Gin、Echo 都是出色的 Web 框架。如果是新项目，微服务框架 go-zero 是相对不错的选择。

开源 Service Mesh 方案

开源 Service Mesh 方案，我们在前面章节“技术选型：在众多 Service Mesh 开源产品中选择合适自己的”中，已经做了详细讲解，这里我们还是通过一张技术方案对比图做一个简单的回顾：

下面我们对开源 Service Mesh 方案的优缺点也做一个简单的总结。

优点：

• 相对于微服务框架，通过和业务架构解耦的方式，降低了升级维护的成本；

• 新旧服务接入同样简单，可以通过 iptables 网络劫持无感知方式接入，也可以通过修改少量代码支持；

• 语言无关性，公司的小众语言也可以很好地支持；

• 可以持续跟进社区方案，获得社区的最新成果；

• 项目启动快，不需要研发，只需要做好测试。

缺点：

• 代码二次扩展难度比较大，需要特定的语言开发经验，公司个性化的需求无法满足； 

• 开源软件往往版本变化比较大，向前兼容性比较差，如果想要维护升级，也需要对源码有一定的掌握，否则升级风险比较大。

总结：

开源 Service Mesh 方案最大的优势是和社区贴近，项目启动快，但也有二次扩展的瓶颈，难以满足公司的个性化需求。

自研 Service Mesh 方案

自研 Service Mesh 方案分为两种，一种是数据面 Sidecar 和控制面全部自研，另外一种是使用开源数据面，但是自研或者二次开发控制面。

• 完全自研

我们先来看一下数据面和控制面完全自研的方案。

优点：

• 具备开源 Service Mesh 方案相对于微服务框架的优势；

• 可扩展性强，可以兼容公司运维环境，对于一些定制型需求，比如新的 RPC 协议支持、多协议服务治理、新的负载均衡支持等； 

• 项目把控力强，出现问题可以快速解决。

缺点：

• 研发成本高，需要一定的研发时间，上线灰度到稳定版本也需要时间，在灰度过程中可能会有 Bug 出现；

• 和社区有一定的割裂。

• 开源数据面+自研控制面

因为公司运维环境的原因，直接使用开源控制面方案基本上无法满足控制面个性的需求，比如第三方注册中心的支持、虚拟机环境的支持等。下面看一下这种方案的优缺点。

优点：

• 可以满足公司多样的运维环境；

• 控制面自研或者二次开发，有一定的定制性。

缺点：

• 数据面 Sidecar 依然有开源方案的弊端。 

• 首先于数据面无法定制，其次对于控制面能做的联动有一定的局限性。

最终选择

结合以上调研，最终我们决定选择数据面和控制面都自研的 Service Mesh 方案。相对于上述缺点，完全自研的方案可控性和可扩展性都很出色，对比微服务框架方案又有维护升级成本低、兼容多种语言等优势。

至此，我们的方案已经确定了。下面我们来看一下技术实现部分，具体包括数据面和控制面需要实现的功能点，以及技术选型，如何依靠开源社区的力量快速实现核心功能。

技术实现

下面我们来看一下本次方案要实现的功能点，因为篇章有限，这里只讲解最核心的部分。具体的数据面和控制面的实现部分，接下来的两讲我们将详细展开。

功能点

数据面 Sidecar：

• 实现基础框架，能够代理 HTTP 协议，并具备扩展性；

• 支持限流、熔断等服务治理中间件； 

• 支持可观测性组件，包括 Log、Trace 和 Metrics；

• 支持服务注册和发现，能够代理业务服务进行注册；

• 通过 xDS 和控制面通信。

控制面：

• 同时兼容虚拟机和 Kubernetes，和公司现有的 CMDB 系统打通，同步机器元数据。

• 支持 xDS 协议，兼容现有的、采用 xDS 协议的数据面。

技术选型

为了快速实现，这里我们就不从头设计框架层了，经过调研，Go-Micro 框架完全可以满足我们数据面 Sidecar 的需求，其本身也支持了多种协议。（Go-Micro 项目地址https://github.com/asim/go-micro）

控制面 Envoy 也提供了基础框架，为了降低复杂度，我们不使用 Istio 二次开发，直接用 Envoy 提供的控制面基础框架来开发。（地址为https://github.com/envoyproxy/go-control-plane）

总结

今天我们主要了解了自研 Service Mesh 项目的原因，对比了微服务框架和多种开源 Service Mesh 方案，结合项目的背景现状确定了自研 Service Mesh 的方案。

本讲内容总结如下：

根据今天内容的讲解，结合公司项目背景，如果让你选择合适的方案，你会做出何种选择呢，是选用微服务框架还是开源Service Mesh 方案，抑或和我一样选择自研的方案呢？

欢迎你关注【云世】公众号，在留言区分享你的观点。

云世

【云世】专注职场人的硬实力和软技能提升。为产品上云，微服务和云原生前沿技术和落地实践布道，分享微服务架构、容器、K8s、Service Mesh等云技术干货、案例、经验；持续发布职场做事方法论、团队管理、读书笔记，好书推荐等软技能。

公众号   

今天的内容到这里就结束了，下一讲我们讲解数据面：基于 Go-Micro 快速实现代理模块，在这一讲会实现一个 Sidecar，然后结合代码讲解，帮助你从源码出发更好地了解 Service Mesh 数据面的原理。

更多“service mesh”系列课程，在 云世 公众号搜索：      

微服务的问题、微服务架构选型、微服务技术选型、servicemesh架构、servicemesh自研架构优缺点