Dubbo 在 K8s 下的思考

云计算
作者 | 曹胜利apache dubbo pmc
导读：dubbo 作为高性能 java rpc 框架的刻板印象早已深入人心，在 cloud native 的架构选型上，spring cloud 或许才是业界的优先选择。实际上，dubbo 已经悄然地衍进为 cloud native 基础设施，不仅承袭过去 rpc 时代的荣耀，而且也完善了现有基础设施的缺失。自从容器和 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 。
参考：https://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 等等。
参考资料：
service mesh 介绍：https://www.infoq.cn/article/pattern-service-mesh[istio]
路由规则：https://istio.io/docs/tasks/traffic-management/request-routing/
备注：上述知识是通过查阅资料( istio 官网)，以及和集团 service mesh 同学沟通获得。如有问题，欢迎指正。
小结
遇到的问题和挑战
spring cloud 和 dubbo 的共生
dubbo 默认是基于 tcp 通信，spring cloud 大部分基于 rest 请求。在阿里云实施商业化过程中，发现大量公司需要 spring cloud 应用和 dubbo 进行通信，社区主要依靠 dubbo 上增加一层网关来解决。
是否有方案进行统一服务注册发现，以及服务调用呢？
基础理论可以参考：
https://yq.aliyun.com/articles/585461
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 是一切编程的基础，所以将某些服务按

怎么选择网站空间
微软将为全球2500万人提供数字技能培训
【六安seo】营销的五种方法哪个更有价值
网站策划：帮你掌握图文排版的5个小技巧
服务器是什么?有什么功能
如何建站 这些要点不容忽视
h5网站制作的报价是怎样的 如何制作h5页面比较好
网页游戏云服务器的价格