Dubbo 在 K8s 下的思考

序言

Dubbo在2011开源以后，一直是国内最受欢迎的RPC框架，以后spring boot和Spring Cloud的面世，助推了微服务的火热程度。计算机的世界变化很快，自从容器和K8s登上舞台以后，给原有的RPC领域带来了很大的挑战。这个文章主要讲述RPC领域遇到的问题，以及RPC怎么去拥抱K8s怀抱的一些思考。

K8S介绍

kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单而且高效,Kubernetes提供了应用部署，规划，更新，维护的一种机制。kubernetes简称K8s。

在Kubernetes中，最小的管理元素不是一个个独立的容器，而是Pod。Pod的生命周期须要注意如下几点：

• 容器和应用可能随时被杀死
• Pod Ip和主机名可能变化 (除非使用StatefulSet进行定制)
• 写到本地的磁盘的文件可能消失，若是想不失效，须要用存储卷

应用，容器，Pod的关系

• 应用部署在容器中，通常状况下一个应用只部署在一个容器中
• 一个Pod下能够包含一个或多个容器，通常状况下一个Pod只建议部署一个容器。下列场景除外：
• side car
• 一个容器的运行以来与本地另一个容器。如一个容器下应用负责下载数据，另一个容器下应用向外提供服务

Service

若是一些Pods 提供了一些功能供其它的Pod使用，在kubernete集群中是如何实现让这些前台可以持续的追踪到这些后台的？答案是：Service。

Kubernete Service 是一个定义了一组 Pod的策略的抽象，这些被服务标记的Pod通常都是经过label Selector决定的。Service抽象了对Pod的访问。

默认的Service，经过一个集群Ip获取A Record。可是有时须要返回全部知足条件的Pod Ip列表，这时候能够直接使用 Headless Services。

参考： kubernetes.io/

推荐书籍：kubernetes in action

RPC介绍和分析

随着微服务的普及，应用之间的通讯有了足够多的成熟方案。Dubbo在2011年开源以后，被大量的中小型公司采用；在Spring Boot推出以后，Spring逐渐焕发出第二春，随即Spring Cloud面世，逐渐占领市场，在中国市场中，和Dubbo分庭抗争；gRPC是google推出的基于Http2的端到端的通讯工具，逐渐地在K8s市场上占据统治地位，如etcd，istio等都采用gRPC做为通讯工具；Service Mesh从开始概念上就火热，如今逐渐走向成熟，Istio + Envoy(其余sidecar)逐渐开始走上舞台。

应用开发者视角

从功能层面来讲，对开发者有感知的功能有：服务实现，服务暴露(注解或配置)，服务调用(注解或配置)，服务治理等。

从选型角度会关注如下几点：易用性(开发易用性和开箱即用)，性能，功能，扩展性等。

框架开发者视角

关键流程：服务暴露，服务注册，服务发现，服务调用，服务治理。

关键知识点：序列化，网络通讯，服务路由，负载均衡，服务限流，熔断，降级等服务治理。

主流技术实现

DUBBO/HSF

Dubbo提供了面向接口的远程方法调用。应用开发者定义接口，编写服务并暴露；Client端经过接口进行调用。

Dubbo注册服务的维度是接口维度，每一个接口会在注册中心写入一条数据。

Dubbo支持条件路由，脚本路由，Tag路由等。这些路由规则都是强依赖于IP地址。

备注：Dubbo和HSF的大部分机制都是类似的，因此下面都以Dubbo做为方案进行讨论。

SpringCloud

Spring Cloud经过Rest形式进行网络调用。应用开发者能够本身编写暴露Rest服务，如springmvc。

Spring Cloud里的服务注册是应用维度(Eureka)，Client端和Server端经过约定的方式进行通讯。

Spring Cloud提供了一套标准API，而其中Netflix是其中的佼佼者，对这套API进行了实现，对大部分开发者来讲，能够回直接依赖和使用Netflix，因此能够说是Netflix提供成了Spring Cloud的核心。可是做为商业公司对开源投入每每会多变，如Eureka已经体制维护。

gRPC

gRPC 是一个 基于 HTTP/2 协议设计的 RPC 框架，它采用了 Protobuf 做为 IDL。gRPC做为端到端的通讯方案，能够解决如今的多语言问题。

gRPC自己不提供服务注册，服务治理的功能。但如今能够看到gRPC有趋势往这方面扩展的野心。

K8s

K8s体系里暂时没有公允的通讯框架，通常推荐gRPC做为RPC框架。

K8s体系下，默认状况下，Pod的Ip是变化的，因此Pod和Pod之间须要通讯的话，有几种方式:

• Service+DNS：新建一个Service，能够经过标签选择到一组Pod列表，这个service对应一个不变的集群Ip；Client端经过DNS方式或者直接访问集群Ip。这个集群Ip，约等于实现了负载均衡 (Iptable方式)。
• headless service：headless service和上面的service的区别是，它不提供集群Ip，经过主机名的形式获取一组Ip列表，Client端本身决定访问哪一个Pod。

Istio + Envoy

Istio的控制层会向K8s的api server请求并监听Pod信息，service信息等信息。这样Istio中就有了完整的K8s集群中的Pod，service等的完整信息。若是K8s集群中有信息变动，istio中也能够获得通知并更新对应的信息。

Envoy做为Proxy一个最多见的实现，以Envoy做为例子简单介绍。Envoy 经过查询文件或管理服务器来动态发现资源。对应的发现服务及其相应的 API 被称做 xDS。协议内容包括LDS，RDS，CDS等等。

参考资料：

servicemesh介绍

Istio路由规则

备注：上述知识是经过查阅资料(Istio官网)，以及和集团service mesh同窗沟通得到。若有问题，欢迎指正。

总结

遇到的问题和挑战

Spring Cloud和Dubbo的共生

基础理论能够 参考.

Dubbo默认是基于TCP通讯，Spring Cloud大部分基于Rest请求。在阿里云实施商业化过程当中，发现大量公司须要Spring Cloud应用和Dubbo进行通讯，社区主要依靠Dubbo上增长一层网关来解决。

是否有方案进行统一服务注册发现，以及服务调用呢？

Dubbo在K8s场景下的挑战

K8s下Pod的IP是变化的 (默认)，dubbo的服务治理高度依赖IP。

K8s的服务注册经过Pod定义完成，服务发现实际上是寻找Pod的过程。Pod和应用有必定的对应关系，和dubbo里的接口维度的服务注册发现模型不是很匹配。

Dubbo在Service mesh场景下的生存空间

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请求。每一个请求对应的也是一个服务。

和K8s里的service的区别

K8s里的service实际上是对应到一组Pod+port列表，和DNS联系紧密；用通俗易懂的方式表达：维护了Pod集合的关系映射。和上面讲的服务是属于不一样场景下的两个概念。

按照这个方式定义服务，服务治理的粒度其实也是按照服务粒度，能够针对每一个服务设置超时时间，设置路由规则等等。可是服务注册的粒度和服务有什么关系呢？

服务注册粒度

一个应用下包含了不少接口，一个接口下包含了不少服务(Dubbo)；或者一个应用包含了不少的服务(Spring Cloud)。分析下应用维度注册和接口维度注册的优缺点。会有一篇独立的文章来阐述应用维度注册的方案。

接口维度注册

优势：

• 服务查询按照接口维度查询很是方便，实现难度低
• 应用拆分或者合并的时候，Client端(消费者)无需关心，作到了让用户无感

缺点：

• 和K8s等主流平台的模型对应关系不匹配
• 注册的数据量很是大，有必定的性能风险

应用维度

优势：

• 和K8s，Spring Cloud等模型对应关系一致
• 性能上能够获得很大缓解

缺点：

• 应用拆分或者合并的时候，Client端须要感知 (若是想作到不感知,须要框架开发者维护一份接口和应用映射关系的存储)
• 若是想对用户保持Dubbo原有的接口维度的查询，须要较多的工做量来保证。
• 对用户透明度有所减小，须要在OPS上提供其余一些工具。如供应用开发者能够查看具体某个Ip是否提供了某个服务等等。

Dubbo 和 Spring Cloud

目标：Dubbo和Spring Cloud的服务发现进行统一；Dubbo和Spring Cloud能够互相调用。

服务发现统一

Dubbo改形成应用维度的服务注册。（具体不展开，后面文章说明）

打通调用

Dubbo实现中，支持将以Rest协议进行暴露，而且让Spring Cloud识别。@桃谷

Dubbo + K8S

在K8s已经阐述过，下面的内容也是假设一个应用部署在一个容器里，一个容器部署在一个Pod里。

接下来方案的讨论，互相之间实际上是有关联的，如服务治理可能会影响到服务注册发现，服务查询也不能依赖于服务注册的内容。整个设计的过程是不断优化的过程。下面所说的内容，以Dubbo来举例说明。

服务治理

Dubbo原有体系里的服务治理是强依赖于IP，当配置了一套服务治理规则的时候，最后都是基于一个或多个Ip地址。

到K8s体系下以后，要考虑的是Pod的Ip不是固定的。因此当前的路由规则不能知足条件，并且会产生不少规则垃圾数据。K8s体系下，经过service查找Pod，是基于label selector； 经过deployment管理Pod，其实也是基于Pod label selector。因此Pod label selector是在K8s习题中比较通用的解决方案。

以路由规则为例，须要支持一种新的路由规则：label路由。经过必定条件匹配以后，将结果定位到以label selector查询到的Pod列表里，而非原来的Ip列表。

要支持label路由，Client端须要获取到Client端本身的Pod label信息，还须要获取到server Pod列表中每一个Pod的label信息。

应用获取当前Pod的信息方式

1. Pod定义环境变量，应用获取

Dubbo提供对环境变量读取的支持，Pod中须要按照Dubbo定义的环境变量设置具体的Pod信息。

1. 经过Downward Api传递Pod信息

Dubbo须要提供对Downward的目录读取，Pod中须要定制downward的对应配置。

1. 经过Api server获取数据

最强大的方式，可是应用须要强依赖于Api server。

应用获取其余Pod的信息方式

1. 经过调用其余Pod的服务获取

依赖于应用能获取自身的Pod信息，同时将自身的Pod信息暴露成服务(rest或dubbo协议)

Client端经过调用对用的Pod获取到对应Pod的完整信息。

1. 经过api server获取数据

很强大，但增长了对api server的依赖。

服务注册和发现

K8s体系下，RPC服务发现有几种方式:

• 注册机制：将Ip写入注册中心，用心跳保持链接；小心跳中止，从注册中心删除。
• 利用Service+DNS：新建一个Service，能够经过标签选择到一组Pod列表，这个service对应一个不变的集群Ip；Client端经过DNS方式或者直接访问集群Ip。这个集群Ip，约等于实现了负载均衡 (Iptable方式)。
• 利用headless service(DNS)：headless service和上面的service的区别是，它不提供集群Ip，经过主机名的形式获取一组Ip列表，Client端本身决定访问哪一个Pod。
• api server： Client端直接请求Api server，获取到Pod的列表，Client本身决定访问Pod的逻辑。同时获取的时候增长watch，api server会将Pod的变化信息同步Client。

经过拿到Server端的Ip或者host，Client端就能够发起Http或者其余协议的请求。

下面介绍符合Dubbo的可行方案：

1. Dubbo + Zookeeper Pod cluster (HSF+CS cluster)

这是最简单的方式，Dubbo自己不须要作任何改造。

带来的问题是增长了ZooKeeper的维护，同时这个方案很不云原生，和K8s的体系没有任何关系。

脑暴

上面方案是将ZooKeeper做为注册中心，那么是否能够将K8s里service做为注册中心呢？dubbo里每一个接口去创建一个service，每一个应用实例启动过程当中去更新Endpoint信息，创建Service-> Endpoint-> Ip列表的关系。

这种方案中K8s service的定义被改造了，并且定义了过多的service，service的维护管理是个难题。

基于K8s的场景

在传统的RPC领域，服务分红服务注册和服务发现。在K8s领域Pod和应用是一对一的关系，K8s自己就提供了Pod查找的能力，因此必定程度上服务注册其实能够不存在，而只须要服务发现。可是这个其实须要一个前提：

dubbo须要将服务注册发现的粒度改形成应用维度。 在运维层面，将app=xxx (应用名)写入到Pod的label中。

2. Dubbo + K8s DNS

若是K8s service提供了cluster Ip，那么Dubbo只负责调用该集群Ip，路由和负载均衡的逻辑则交给了K8s的proxy来完成。此方案削减了Dubbo的核心能力。

接下来讨论headless service提供的能力。

经过请求<service>.<ns>.svc.<zone>. IN A 的方式发起请求获取Ip列表，可是须要轮询方式不断获取更新的Ip列表。 参考

服务治理相关的功能，须要在上述服务治理部分中独立支持。

3. Dubbo + Api Server

Pod的容器中部署的dubbo应用，服务注册流程能够直接删除，服务发现功能经过和Api Server进行交互，获取Pod和service信息，同时watch Pod和service的变动。经过这种方式以后，服务治理相关的信息也能够经过Api Server直接获取。

4. Dubbo + Istio + Envoy

Dubbo能够直接使用指定Ip+端口的方式调用同一个Pod下Envoy (也多是同一个node的Envoy)。Dubbo将路由规则，负载均衡，熔断等功能交给Istio和Envoy。Envoy须要支持Dubbo协议的转发。

因此Dubbo须要完成两个事情：本地IP直连(现有功能)， 多余功能裁剪(暂未实现)。

5. Dubbo + Istio

Dubbo 应用再也不依赖 Envoy 做为 sidecar ，而是直接和 Istio 进行交互，把 Istio 做为注册中心，做为服务治理的配置中心。

Dubbo 须要提供相似的 xDS 协议，在pilot将service的instance转换成dubbo的协议格式。

Dubbo 还须要去适配 istio 的一些功能，如健康检查，安全相关的逻辑。具体实现能够参考 Envoy 的实现。

6. Dubbo和 Istio 在 K8s 体系下共存

这个可选择的方案较多，我提供两种思路，供你们思考：

全部的服务注册经过K8s的机制完成，全部的服务发现经过 Headless service 完成。sidecar 在建立过程当中，须要对原有的 K8s service 进行 update 。

Nacos 做为 Dubbo 的注册中心，而且须要将 K8s 中的数据进行部分中转。Dubbo 应用，将服务注册以应用维度注册到 Nacos ，Istio Pilot 须要识别 Nacos 数据；Istio 的运行机制基本不变，须要将 K8s service instance 的数据写入到 nacos ，供 Dubbo 调用。

7. 云上和云下环境共存 & 云上多集群环境

Istio 提供了跨集群和云上云下的解决方案， kubeFed 做为 K8s 的跨集群解决方案也能起到必定做用。

这个课题的复杂度更加高，心中有了一些答案，指望你们经过上文也有必定的思考。

服务查询

抛出三种方式，供你们思考。

Dubbo原有方式

Dubbo原有的服务查询是针对接口的查询，每一个接口会有版本号和组别。接口名+版本号+组别肯定惟一的服务集合，这个服务集下有对应的服务提供者和服务消费者(接口级依赖)，服务提供者是一组Ip+port列表，服务消费者也是一组Ip+port列表。

当作了改形成应用级别的服务注册或者直接使用K8s自带的Pod发现机制的话，须要作一些改造，这部分改造，和前面提到的同样，放到其余文章里单独说明。

只支持应用查询

和Spring Cloud相似，支持应用维度的查询。查询到具体应用以后，应用详情下包含了Ip+port列表，每一个Ip+port其实就是一个应用的实例。点击开每一个应用实例，能够查看每一个应用的详细信息，详细信息包含了该实例提供了哪些服务。

接口+应用查询均衡

在原来只支持应用查询的基础上，增长一步：支持查询某个接口对应的应用列表，而大部分接口只属于一个应用。

再点击应用列表下具体的应用以后，会跳到应用详情。

总结

上述讨论的是开源的方案，因此相对历史包袱比较少。对一些大公司想从原有的RPC方案切换到云原生的支持，须要考虑更多兼容性和性能，须要付出更大的代价。

云原生的趋势已经势不可挡，在RPC领域究竟哪一种方案最终可以胜出，如今还言之过早。我相信Service Mesh 和传统的RPC (Dubbo/ gRPC) 都会有本身的一席之地，一切让时间给咱们答案吧。

做者简介：曹胜利，Apache Dubbo PMC，关注RPC领域。在阿里内部负责Dubbo开源和ClassLoader隔离器Pandora Boot。

原文连接

本文为云栖社区原创内容，未经容许不得转载。