下一代微服务-ServiceMesh

 

　　1、简介

 

　　系统服务化之后，服务间通信需要关注什么？

 

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

 

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

 

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

 

　　ServiceMesh是一个专门的软件基础设施层，和主进程独立，通过（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、业界开源对比

 

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

 

　　1、Istio

 

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

 

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

 

　　2、Linkerd

 

　　Linkerd没有ControlPlane这一层，只有Sidecar。

 

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

 

　　3、Conduit

 

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

 

　　4、SOFAMesh（阿里自研）

 

　　SOFAMesh其实直接采用了Istio的ControlPlane的Pilot和Auth，因为我们觉得Istio在这块上没有太大的问题甚至里面也有一些非常不错的设计，比如Pilot这部分的UniversalDataAPI就是非常不错的设计。Istio的Auth这部分也充分地利用了Kubernetes的安全机制。

 

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

 

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