dubbo k8s 服务发现_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 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<