下一代微服务-ServiceMesh

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和国内的唯品会等)早有实践,那么为什么现在这个概念又流行起来了呢?我认为主要原因如下:

  1. 上述模式一和二有一些固有缺陷,模式一相对比较重,有单点问题和性能问题;模式二则有客户端复杂,支持多语言困难,无法集中治理的问题。模式三是模式一和二的折中,弥补了两者的不足,它是纯分布式的,没有单点问题,性能也OK,应用语言栈无关,可以集中治理。
  2. 微服务化、多语言和容器化发展的趋势,企业迫切需要一种轻量级的服务发现机制,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,其实也是希望能够更好地和云原生时代的这些基础设施贴合。

参考:

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

https://www.cnblogs.com/williamjie/p/9497435.html

posted @ 2019-06-28 11:12  leon66666  阅读(...)  评论(... 编辑 收藏