扇贝 Service Mesh 发展历程

伴随 Kubernetes 的兴起，越来越多的公司开始实践 Service Mesh，以应对规模越来越大的微服务间通信问题。本文主要介绍了 Service Mesh 演进的常见形式，扇贝 Service Mesh 选型落地 Envoy 的过程，以及如何基于 go-control-plane 搭建自己的 Envoy xDS 服务端。希望能对在大家落地 Service Mesh 的过程中提供一点思路。

扇贝业务现状

首先跟大家简单说明一下扇贝的业务状况，扇贝三年前就开始实行 Docker 化和微服务化来应对需求的快速变更。随着公司规模扩大，组织结构也相应的调整拆分，业务团队之间变得独立，微服务数量开始快速上升，因此 2018 年初我们的技术架构也开始转向 Kubernetes 来应对挑战，Service Mesh 的落地便是伴随着转型 Kubernetes 开始的。

目前扇贝的微服务有五百多个，整个 Kubernetes 集群有七十多个节点，运行了五千多 Pod，承担每天数十亿次的内外部 API 调用，峰值 QPS 过万。

Service Mesh 的演进形式

Service Mesh 一词出现的时间虽然较晚，但宽泛的来讲，他所追求的通信与业务解耦的理念却有很长的发展的历程，通常会有下面几种演进形式：

• 较原始的时候，开发者需要在业务代码中实现服务发现、负载均衡、熔断重试等功能，这些都是脏活累活，本不属于业务的核心功能，却需要开发者花费大量的心血。

• 第二阶段，自然而然的我们就会想到把这部分功能剥离出来，抽象成可复用的类库，比如Java世界中的 Spring Cloud/Netflix OSS。但是这些框架从进程角度来看，还是跟业务是耦合的，而且还存在着跨语言困难，版本升级难以推进，框架庞大业务同学学习成本高等问题。

• 第三阶段，服务通信的技术栈进一步下沉，通过 Nginx，HAProxy，Apache 等反向代理的使用引入 Proxy 层，分离业务与服务通信。Proxy层的引入是一个承上启下的阶段。有了 Proxy 层，服务注册发现、负载均衡、重试熔断等机制得以脱离业务语言和框架，开始热闹起来。但是以传统反向代理为核心的，服务变化需要重启进程甚至更改配置文件的 Proxy 层，在面对 Kubernetes 时代微服务频繁重启、漂移的状况时就显得力不从心了。

• 进入 Kubernetes 时代，Service Mesh 概念开始出现，通信网络分为了控制平面和数据平面，Linked、Envoy、Istio 等产品登上历史舞台。并由第一代的 proxy per node（Linked v1 ） 模式快速进化到 Sidecar 形式，使得通信层离真实业务足够进，控制力度足够细&#