下一代微服务-ServiceMesh

一、简介

系统服务化以后，服务间通讯须要关注什么？

服务发现、负载均衡、路由、流控、通讯可靠性、弹性、安全、监控、日志

API网关能够集中式的管理这些功能，可是会出现单点故障，而且实现起来网关会变得愈来愈臃肿。 而且网关是一个集中式的处理

Service Mesh是网络通讯基础设施，能够将网络功能从代码中剥离出来。 经过Service Mesh不用在服务代码中实现用于可靠性通讯的模式或断路，超时等控制。

Service Mesh是一个专门的软件基础设施层，和主进程独立，经过（HTTP，GRPC）进行代理通讯，用于控制和监控微服务应用程序中服务到服务的内部通讯，让服务到服务通讯变得快速，安全，可靠。

二、由来

微服务中的服务发现问题如何解决

一、传统集中式代理

这是最简单和传统作法，在服务消费者和生产者之间，代理做为独立一层集中部署，由独立团队(通常是运维或框架)负责治理和运维。经常使用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，F5(4层负载)+Nginx(7层负载)这种软硬结合两层代理也是业内常见作法，兼顾配置的灵活性(Nginx比F5易于配置)。

这种方式一般在DNS域名服务器的配合下实现服务发现，服务注册(创建服务域名和IP地址之间的映射关系)通常由运维人员在代理上手工配置，服务消费方仅依赖服务域名，这个域名指向代理，由代理解析目标地址并作负载均衡和调用。

国外知名电商网站eBay，虽然体量巨大，但其内部的服务发现机制仍然是基于这种传统的集中代理模式，国内公司如携程，也是采用这种模式。

二、客户端嵌入式代理

这是不少互联网公司比较流行的一种作法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式通常须要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并按期报心跳，客户端代理则发现服务并作负载均衡。

Netflix开源的Eureka(注册中心)是这种模式的典型案例，国内阿里开源的Dubbo也是采用这种模式。

三、主机独立进程代理

这种作法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是做为独立进程部署在每个主机上，一个主机上的多个消费者应用能够共用这个代理，实现服务发现和负载均衡，以下图所示。这个模式通常也须要独立的服务注册中心组件配合，做用同模式二。

四、服务网格

所谓的ServiceMesh，其实本质上就是上面提到的模式三~主机独立进程模式，这个模式其实并不新鲜，业界(国外的Airbnb和国内的惟品会等)早有实践，那么为何如今这个概念又流行起来了呢？我认为主要缘由以下：

1. 上述模式一和二有一些固有缺陷，模式一相对比较重，有单点问题和性能问题；模式二则有客户端复杂，支持多语言困难，没法集中治理的问题。模式三是模式一和二的折中，弥补了二者的不足，它是纯分布式的，没有单点问题，性能也OK，应用语言栈无关，能够集中治理。
2. 微服务化、多语言和容器化发展的趋势，企业迫切须要一种轻量级的服务发现机制，ServiceMesh正是迎合这种趋势诞生，固然这还和一些大厂(如Google/IBM等)的背后推进有关。

模式三(ServiceMesh)也被形象称为边车(Sidecar)模式

三、业界开源对比

目前，业界主流的 Service Mesh 相关的框架有三个，分别是 Google，IBM，Lyft都参与其中的 Istio，以及 Bouyant 公司下的两个开源的 Service Mesh 的框架 Linkerd 以及 Conduit。

一、Istio

完整地包含了一个 Data Plane 以及 Control Plane，可是Istio 一直以来被挑战的地方其实在于他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承担了服务鉴权，Quota 控制，Tracing，Metrics等等能力，它是一个中央的节点，那 Mixer 就成了一个单点，这个单点的运维和高可用又成了一个问题。

另外，Istio 的性能是咱们一直以来比较担忧的问题

二、Linkerd

Linkerd 没有 Control Plane 这一层，只有 Sidecar。

Linkerd是用 Scala 写的，跑在 JVM 上面。 Linkerd 所须要的内存至少都须要 100M，这也是 Bouyant 官方不推荐 Linkerd 和应用作一对一的部署，而是采用 DaemonSet 的方式进行部署。而咱们指望的一个部署方式是和应用作一对一的部署，这样的内存占用对于咱们来讲成本太过，咱们指望将 Sidecar 的内存占用控制在 10M 左右。

三、Conduit

Conduit 也是 Linkerd 不久以前推出的一个Service Mesh 的框架，还不太成熟。Conduit 选择的语言是 Rust。比较小众

四、SOFA Mesh（阿里自研）

SOFA Mesh 其实直接采用了 Istio 的 Control Plane 的Pilot 和 Auth，由于咱们以为 Istio 在这块上没有太大的问题甚至里面也有一些很是不错的设计，好比Pilot 这部分的 Universal Data API 就是很是不错的设计。Istio 的 Auth 这部分也充分地利用了 Kubernetes 的安全机制。

而Mixer 这部分，其实我以前就提到咱们是以为有设计上问题的，因此咱们的想法是直接把 Mixer 搬到 Sidecar 中实现。

再者，你们都知道 Istio 的 Sidecar 是 Envoy，它是一个用 C++ 写的，那么咱们怎么把Mixer 移入到 Sidecar 中去呢，其实咱们的 SOFA Mesh 的 Sidecar 是采用了 Golang 来写的，因此才给把 Mixer 移入Sidecar 提供了可能性，固然，咱们选择用 Golang 来研发 Sidecar 不只仅是为了把 Mixer 移入到 Sidecar 而已，其实也有其余的考虑，一方面，在云计算的时代，Golang以及成为构建基础设施的首选语言，咱们看到大量的基础设施都是用 Golang 写的，包括 Docker，Kubernetes 等等，选择 Golang，其实也是但愿可以更好地和云原生时代的这些基础设施贴合。

参考：

https://www.sohu.com/a/235575064_99940985

http://www.javashuo.com/article/p-kbrpnzwp-bc.html