【编者的话】Dubbo 在 2011 开源之后,一直是国内最受欢迎的 RPC 框架,之后 Spring Boot 和 Spring Cloud 的面世,助推了微服务的火热程度。计算机的世界变化很快,自从容器和 Kubernetes 登上舞台之后,给原有的 RPC 领域带来了很大的挑战。这个文章主要讲述 RPC 领域遇到的问题,以及 RPC 怎么去拥抱 Kubernetes 的一些思考。
Kubernetes 是一个开源的,用于管理云平台中多个主机上的容器化的应用, Kubernetes 的目标是让部署容器化的应用简单并且高效,Kubernetes 提供了应用部署、规划、更新、维护的一种机制。Kubernetes 简称为 K8s。
在 Kubernetes 中,最小的管理元素不是一个个独立的容器,而是 Pod。Pod 的生命周期需要注意以下几点:
应用、容器、Pod 的关系:
如果一些 Pods 提供了一些功能供其它的 Pod 使用,在 Kubernetes 集群中是如何实现让这些前台能够持续的追踪到这些后台的?答案是:Service 。
Kubernetes Service 是一个定义了一组 Pod 的策略的抽象,这些被服务标记的Pod一般都是通过 label Selector 决定的。Service 抽象了对 Pod 的访问。
默认的 Service ,通过一个集群 Ip 获取 A Record 。但是有时需要返回所有满足条件的 Pod ip 列表,这时候可以直接使用 Headless Services 。
随着微服务的普及,应用之间的通信有了足够多的成熟方案。Dubbo 在 2011 年开源之后,被大量的中小型公司采用;在 Spring Boot 推出之后,Spring 逐渐焕发出第二春,随即 Spring Cloud 面世,逐渐占领市场,在中国市场中,和 Dubbo 分庭抗争;gRPC 是 Google 推出的基于 Http2 的端到端的通信工具,逐渐地在 Kubernetes 市场上占据统治地位,如 etcd,Istio 等都采用 gRPC 作为通信工具;Service Mesh 从开始概念上就火热,现在逐渐走向成熟,Istio + Envoy(其他 sidecar)逐渐开始走上舞台。
从功能层面来说,对开发者有感知的功能有:服务实现,服务暴露(注解或配置),服务调用(注解或配置),服务治理等。
从选型角度会关注以下几点:易用性(开发易用性和开箱即用)、性能、功能、扩展性等。
关键流程:服务暴露,服务注册,服务发现,服务调用,服务治理。
关键知识点:序列化,网络通信,服务路由,负载均衡,服务限流,熔断,降级等服务治理。
Dubbo 提供了面向接口的远程方法调用。应用开发者定义接口,编写服务并暴露。
Client 端通过接口进行调用。
Dubbo 注册服务的维度是接口维度,每个接口会在注册中心写入一条数据。
Dubbo 支持条件路由,脚本路由,Tag 路由等。这些路由规则都是强依赖于 IP 地址。
备注:Dubbo 和 HSF 的大部分机制都是相似的,所以下面都以 Dubbo 作为方案进行讨论。
Spring Cloud 通过 Rest 形式进行网络调用。应用开发者可以自己编写暴露 Rest 服务,如 Spring MVC 。
Spring Cloud 里的服务注册是应用维度(Eureka),Client 端和 Server 端通过约定的方式进行通信。
Spring Cloud 提供了一套标准 API ,而其中 Netflix 是其中的佼佼者,对这套 API 进行了实现,对大部分开发者来说,可以回直接依赖和使用 Netflix ,所以可以说是 Netflix 提供成了 Spring Cloud 的核心。但是作为商业公司对开源投入往往会多变,如 Eureka 已经体制维护。
gRPC 是一个基于 HTTP/2 协议设计的 RPC 框架,它采用了 Protobuf 作为 IDL 。gRPC 作为端到端的通信方案,可以解决现在的多语言问题。
gRPC 本身不提供服务注册,服务治理的功能。但现在可以看到 gRpc 有趋势往这方面扩展的野心。
Kubernetes 体系里暂时没有公允的通信框架,一般推荐 gRPC 作为 RPC 框架。
Kubernetes 体系下,默认情况下, Pod 的 IP 是变化的,所以 Pod 和 Pod 之间需要通信的话,有几种方式:
Istio 的控制层会向 Kubernetes 的 Api Server 请求并监听 Pod 信息,Service 信息等信息。这样 Istio 中就有了完整的 Kubernetes 集群中的 Pod,Service 等的完整信息。如果 Kubernetes 集群中有信息变更,Istio 中也可以得到通知并更新对应的信息。
Envoy 作为 Proxy 一个最常见的实现,以 Envoy 作为例子简单介绍。Envoy 通过查询文件或管理服务器来动态发现资源。对应的发现服务及其相应的 Api 被称作 xDS 。协议内容包括 LDS、RDS、CDS 等等。
参考资料:
备注:上述知识是通过查阅资料(Istio 官网),以及和集团 Service Mesh 同学沟通获得。如有问题,欢迎指正。
基础理论可以参考: https://yq.aliyun.com/articles/585461
Dubbo 默认是基于 TCP 通信,Spring Cloud 大部分基于 Rest 请求。在阿里云实施商业化过程中,发现大量公司需要 Spring Cloud 应用和 Dubbo 进行通信,社区主要依靠 Dubbo 上增加一层网关来解决。
是否有方案进行统一服务注册发现,以及服务调用呢?
Kubernetes 下 Pod 的 IP 是变化的(默认),Dubbo 的服务治理高度依赖 IP 。
Kubernetes 的服务注册通过 Pod 定义完成,服务发现其实是寻找 Pod 的过程。Pod 和应用有一定的对应关系,和 Dubbo 里的接口维度的服务注册发现模型不是很匹配。
Dubbo 需要进行支持裁剪,Dubbo 的大部分功能都可以交由 sidecar(proxy)来完成。
如果公司已经在部署了 RPC 框架,这时候如果需要实施 Service Mesh ,有什么好的过渡方案吗?
服务怎么定义呢?需要从应用开发者角度看待怎么定义服务。
服务在功能维度对应某一功能,如查询已买订单详情。在 Dubbo 中,对应某个接口下的方法;在 Spring Cloud 和 gRPC 对应一个 http 请求。如果从面向函数编程角度,一个服务就是一个 function 。在 Java 语言中,class 是一切编程的基础,所以将某些服务按照一定的维度进行聚合,放到某个接口中,就成了一个接口包含了很多的服务。
从 Dubbo 角度来解释下:Dubbo 是面向接口编程的远程通信,所以 Dubbo 是面向服务集的编程,你如果想调用某个服务,必须通过接口的方式引入,然后调用接口中的某个服务。Dubbo Ops 中提供的服务查询功能,其实不是查询单个服务,而是通过查询接口(服务集)之后获得具体的方法(服务)。
而在 Spring Cloud 的世界里,服务提供方会将自己的应用信息(IP + port)注册成应用下的一个实例,服务消费方和服务提供方按照约定的形式进行 Rest 请求。每个请求对应的也是一个服务。
和 Kubernetes 里的 Service 的区别:
Kubernetes 里的 Service 其实是对应到一组 Pod + port 列表,和 DNS 联系紧密;用通俗易懂的方式表达:维护了 Pod 集合的关系映射。和上面讲的服务是属于不同场景下的两个概念。
按照这个方式定义服务,服务治理的粒度其实也是按照服务粒度,可以针对每个服务设置超时时间,设置路由规则等等。但是服务注册的粒度和服务有什么关系呢?
一个应用下包含了很多接口,一个接口下包含了很多服务(Dubbo);或者一个应用包含了很多的服务(Spring Cloud)。分析下应用维度注册和接口维度注册的优缺点。会有一篇独立的文章来阐述应用维度注册的方案。
优点:
缺点:
应用维度:
优点:
缺点:
目标:Dubbo 和 Spring Cloud 的服务发现进行统一;Dubbo 和 Spring Cloud 可以互相调用。
Dubbo 改造成应用维度的服务注册。(具体不展开,后面文章说明)
Dubbo 实现中,支持将以 Rest 协议进行暴露,并且让 Spring Cloud 识别。
在 Kubernetes 已经阐述过,下面的内容也是假设一个应用部署在一个容器里,一个容器部署在一个 Pod 里。
接下来方案的讨论,互相之间其实是有关联的,如服务治理可能会影响到服务注册发现,服务查询也不能依赖于服务注册的内容。整个设计的过程是不断优化的过程。下面所说的内容,以 Dubbo 来举例说明。
Dubbo 原有体系里的服务治理是强依赖于 IP ,当配置了一套服务治理规则的时候,最后都是基于一个或多个 IP 地址。
到 Kubernetes 体系下之后,要考虑的是 Pod 的 IP 不是固定的。所以当前的路由规则不能满足条件,而且会产生很多规则垃圾数据。Kubernetes 体系下,通过 Service 查找 Pod ,是基于 label selector ;通过 deployment 管理 Pod ,其实也是基于 Pod label selector 。所以 Pod label selector 是在 Kubernetes 习题中比较通用的解决方案。
以路由规则为例,需要支持一种新的路由规则:label 路由。通过一定条件匹配之后,将结果定位到以 label selector 查询到的 Pod 列表里,而非原来的 IP 列表。
要支持 label 路由,client 端需要获取到 client 端自己的 Pod label 信息,还需要获取到 server pod 列表中每个 Pod 的 label 信息。
应用获取当前 Pod 的信息方式:
应用获取其他 Pod 的信息方式:
Kubernetes 体系下,RPC 服务发现有几种方式:
通过拿到 Server 端的 IP 或者 host ,Client 端就可以发起 http 或者其他协议的请求。
下面介绍符合 Dubbo 的可行方案:
Dubbo + ZooKeeper Pod Cluster(HSF+CS cluster)
这是最简单的方式,Dubbo 本身不需要做任何改造。
带来的问题是增加了 ZooKeeper 的维护,同时这个方案很不云原生,和 Kubernetes 的体系没有任何关系。
脑暴:
上面方案是将 ZooKeeper 作为注册中心,那么是否可以将 Kubernetes 里 Service 作为注册中心呢?Dubbo 里每个接口去建立一个 Service,每个应用实例启动过程中去更新 Endpoint 信息,建立 Service-> Endpoint-> IP 列表的关系。
这种方案中 Kubernetes Service 的定义被改造了,而且定义了过多的 Service,Service 的维护管理是个难题。
基于 Kubernetes 的场景:
在传统的 RPC 领域,服务分成服务注册和服务发现。在 Kubernetes 领域 Pod 和应用是一对一的关系,Kubernetes 本身就提供了 Pod 查找的能力,所以一定程度上服务注册其实可以不存在,而只需要服务发现。但是这个其实需要一个前提:
Dubbo + Kubernetes DNS
如果 Kubernetes Service 提供了 Cluster IP,那么 Dubbo 只负责调用该集群 IP,路由和负载均衡的逻辑则交给了 Kubernetes 的 Proxy 来完成。此方案削减了 Dubbo 的核心能力。
接下来讨论 Headless Service 提供的能力。
通过请求 <service>.<ns>.svc.<zone>. IN A 的方式发起请求获取 IP 列表,但是需要轮询方式不断获取更新的 IP 列表。
参考: https://github.com/kubernetes/ ... rvice
服务治理相关的功能,需要在上述服务治理部分中独立支持。
Dubbo + API Server
Pod 的容器中部署的 Dubbo 应用,服务注册流程可以直接删除,服务发现功能通过和 API Server 进行交互,获取 Pod 和 Service 信息,同时 watch pod 和 Service 的变更。通过这种方式之后,服务治理相关的信息也可以通过 API Server 直接获取。
Dubbo + Istio + Envoy
Dubbo 可以直接使用指定 IP + 端口的方式调用同一个 Pod 下 Envoy(也可能是同一个 Node 的 Envoy)。Dubbo 将路由规则,负载均衡,熔断等功能交给 Istio 和 Envoy。Envoy 需要支持 Dubbo 协议的转发。
所以 Dubbo 需要完成两个事情:本地 IP 直连(现有功能),多余功能裁剪(暂未实现)。
Dubbo + Istio
Dubbo 应用不再依赖 Envoy 作为 sidecar ,而是直接和 Istio 进行交互,把 Istio 作为注册中心,作为服务治理的配置中心。
Dubbo 需要提供类似的 xDS 协议,在 Pilot 将 Service 的 instance 转换成 Dubbo 的协议格式。
Dubbo 还需要去适配 Istio 的一些功能,如健康检查,安全相关的逻辑。具体实现可以参考 Envoy 的实现。
Dubbo 和 Istio 在 Kubernetes 体系下共存
这个可选择的方案较多,我提供两种思路,供大家思考:
云上和云下环境共存 & 云上多集群环境
Istio 提供了跨集群和云上云下的解决方案, kubeFed 作为 Kubernetes 的跨集群解决方案也能起到一定作用。
这个课题的复杂度更加高,心中有了一些答案,期望大家通过上文也有一定的思考。
抛出三种方式,供大家思考。
Dubbo 原有的服务查询是针对接口的查询,每个接口会有版本号和组别。接口名 + 版本号 + 组别确定唯一的服务集合,这个服务集下有对应的服务提供者和服务消费者(接口级依赖),服务提供者是一组 IP + port 列表,服务消费者也是一组 IP + port 列表。
当做了改造成应用级别的服务注册或者直接使用 Kubernetes 自带的 Pod 发现机制的话,需要做一些改造,这部分改造,和前面提到的一样,放到其他文章里单独说明。
和 Spring Cloud 类似,支持应用维度的查询。查询到具体应用之后,应用详情下包含了 IP + port 列表,每个 IP + port 其实就是一个应用的实例。点击开每个应用实例,可以查看每个应用的详细信息,详细信息包含了该实例提供了哪些服务。
在原来只支持应用查询的基础上,增加一步:支持查询某个接口对应的应用列表,而大部分接口只属于一个应用。
再点击应用列表下具体的应用之后,会跳到应用详情。
上述讨论的是开源的方案,所以相对历史包袱比较少。对一些大公司想从原有的 RPC 方案切换到云原生的支持,需要考虑更多兼容性和性能,需要付出更大的代价。
云原生的趋势已经势不可挡,在 RPC 领域究竟哪种方案最终能够胜出,现在还言之过早。我相信 Service Mesh 和传统的 RPC(Dubbo/gRPC)都会有自己的一席之地,一切让时间给我们答案吧。
作者简介:曹胜利,Apache Dubbo PMC,关注 RPC 领域。在阿里内部负责 Dubbo 开源和 ClassLoader 隔离器 Pandora Boot 。
原文链接: https://mp.weixin.qq.com/s/3e2jgHUKFQXpu-pTltRcZw