1、简介
系统服务化之后，服务间通信需要关注什么？
服务发现、负载均衡、路由、流控、通信可靠性、弹性、安全、监控、日志
API网关可以集中式的管理这些功能，但是会出现单点故障，并且实现起来网关会变得越来越臃肿。 并且网关是一个集中式的处理
Service Mesh是网络通信基础设施，可以将网络功能从代码中剥离出来。 通过Service Mesh不用在服务代码中实现用于可靠性通信的模式或断路，超时等控制。
Service Mesh是一个专门的软件基础设施层，和主进程独立，通过（HTTP，GRPC）进行代理通信，用于控制和监控微服务应用程序中服务到服务的内部通信，让服务到服务通信变得快速，安全，可靠。
2、由来
微服务中的服务发现问题如何解决
1、传统集中式代理
这是最简单和传统做法，在服务消费者和生产者之间，代理作为独立一层集中部署，由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5)，或者软件负载均衡器(如Nginx)，F5(4层负载)+Nginx(7层负载)这种软硬结合两层代理也是业内常见做法，兼顾配置的灵活性(Nginx比F5易于配置)。
这种方式通常在DNS域名服务器的配合下实现服务发现，服务注册(建立服务域名和IP地址之间的映射关系)一般由运维人员在代理上手工配置，服务消费方仅依赖服务域名，这个域名指向代理，由代理解析目标地址并做负载均衡和调用。
国外知名电商网站eBay，虽然体量巨大，但其内部的服务发现机制仍然是基于这种传统的集中代理模式，国内公司如携程，也是采用这种模式。
2、客户端嵌入式代理
这是很多互联网公司比较流行的一种做法，代理(包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。
Netflix开源的Eureka(注册中心)是这种模式的典型案例，国内阿里开源的Dubbo也是采用这种模式。
3、主机独立进程代理
这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如下图所示。这个模式一般也需要独立的服务注册中心组件配合，作用同模式二。
4、服务网格
所谓的ServiceMesh，其实本质上就是上面提到的模式三~主机独立进程模式，这个模式其实并不新鲜，业界(国外的Airbnb和国内的唯品会等)早有实践，那么为什么现在这个概念又流行起来了呢？我认为主要原因如下：
- 上述模式一和二有一些固有缺陷，模式一相对比较重，有单点问题和性能问题；模式二则有客户端复杂，支持多语言困难，无法集中治理的问题。模式三是模式一和二的折中，弥补了两者的不足，它是纯分布式的，没有单点问题，性能也OK，应用语言栈无关，可以集中治理。
- 微服务化、多语言和容器化发展的趋势，企业迫切需要一种轻量级的服务发现机制，ServiceMesh正是迎合这种趋势诞生，当然这还和一些大厂(如Google/IBM等)的背后推动有关。
模式三(ServiceMesh)也被形象称为边车(Sidecar)模式
3、业界开源对比
目前，业界主流的 Service Mesh 相关的框架有三个，分别是 Google，IBM，Lyft都参与其中的 Istio，以及 Bouyant 公司下的两个开源的 Service Mesh 的框架 Linkerd 以及 Conduit。
1、Istio
完整地包含了一个 Data Plane 以及 Control Plane，但是Istio 一直以来被挑战的地方其实在于他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承担了服务鉴权，Quota 控制，Tracing，Metrics等等能力，它是一个中央的节点，那 Mixer 就成了一个单点，这个单点的运维和高可用又成了一个问题。
另外，Istio 的性能是我们一直以来比较担心的问题
2、Linkerd
Linkerd 没有 Control Plane 这一层，只有 Sidecar。
Linkerd是用 Scala 写的，跑在 JVM 上面。 Linkerd 所需要的内存至少都需要 100M，这也是 Bouyant 官方不推荐 Linkerd 和应用做一对一的部署，而是采用 DaemonSet 的方式进行部署。而我们期望的一个部署方式是和应用做一对一的部署，这样的内存占用对于我们来说成本太过，我们期望将 Sidecar 的内存占用控制在 10M 左右。
3、Conduit
Conduit 也是 Linkerd 不久之前推出的一个Service Mesh 的框架，还不太成熟。Conduit 选择的语言是 Rust。比较小众
4、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，其实也是希望能够更好地和云原生时代的这些基础设施贴合。
参考：
