2个维度5大方法，让你的微服务在K8s上跑起来

嘉宾 |赵新（于雨）  整理 | 雷济慈

出品 | CSDN（ID：CSDNnews）

蚂蚁集团可信原生部(TNT)，dubbogo社区负责人于雨在2022云原生超级英雄会上做了Apache/Dubbogo的K8s解决方案分享。

点击看完整版视频

 

K8s VS Dubbogo

K8s提供最基础的功能就是管理Pod，浅显来说就是卖服务器的节点。基于对Pod的管理，K8s也提供了service，对一组Pod进行服务管理，可以认为是非常简单的服务管理体系，但达不到服务治理的目的。

在微服务从业者看来K8s service跟标准的微服务体系差异还是很大的。它仅提供了一套服务发现机制，在此之上进行服务治理还有很多额外的工作需要做，而这些都要求相关从业者对K8s代码非常熟悉，而且它自身的扩展功能并不强。大公司对K8s的使用仅是用来管理Pod/容器/虚机，向上提供服务资源，很少直接使用service。所以在云原生时代，不会因为K8s提供了service，大家就抛弃了传统的微服务基础设施。

话题转到微服务框架如Dubbo/Dubbogo，Dubbo v2时代提供了一套完整的基于接口粒度的微服务治理体系。在云原生时代，可以认为K8s的service大概等于Dubbogo某些部分，但整体来说，它的功能并没有生产级微服务设施那么完善。

Dubbogo v1 解决方案

如何在K8s之上使用微服务，如何让你的微服务在K8s平台之上run起来？大概有这么几个方案：

1.endpoint维度

在微服务平台之上，每个endpoint把自己的信息注册到K8s的API server里面，把API server当做微服务的注册中心，进行服务的监听调用。

2.operator维度

每个角色使用K8s的扩展机制，自己的信息通过API server注册到etcd之内，它仍然是把K8s的master节点（APIServer + etcd）当做自己的注册中心，又额外扩展了一个operator。这个方案的优点是高度可定制，但需要你对K8s有一定的掌控力度，当然还需额外的operator的维护成本。把K8s的API server当做注册中心来使用，如果在中小公司，这个方案基本上不会有什么问题，但在大公司的话，很少有人会这么做。

如果微服务平台也把K8s的master节点当做注册中心，不管是底层K8s自身的kubelet节点或者Paas平台把Master节点打挂了，还说上层应用因为数据太多流量太大把K8s的master的节点打跨，整个系统就会瘫痪了，无论是K8s还是应用自身都不可用，这是极大的风险。所以，个人建议只把K8s当做pod的管理平台，也就是资源提供角色。把K8s的API server也就是master节点暴露给微服务基础设施层，显得并不明智。

这个方案本质是endpoint维度的方案，把K8s的API server当成注册中心，它的好处是比较简单。

微服务基础设施里面有两个经典的角色：服务的提供者provider和服务的使用者consumer，这两个角色启动时从pod里获取自己的信息。

 

Dubbogo 3.0的K8s解决方案

云原生时代，怎么在K8s之上运行基于微服务基础设施的应用?

它的方案其实很多，先说是Dubbo3里面几个概念。Dubbo/Dubbogo 3.0里面有三大注册中心:

1. 注册中心

2. 元数据中心

3. 配置中心

三个节点在K8s这个平台上并不都需要部署。

Dubbogo 3.0注册有两种模式，根据元数据中心是否在这里面进行部署，分为local模式和remote模式。

如果使用传统注册中心，元数据中心在云平台层面进行部署之后，provider在启动时把信息注册到元数据中心里，当consumer启动时，就去远程元数据中心拉取元数据，这是 remote 模式。

但是如果不部署元数据中心，provider自动启动metadata线程，充当伪装的元数据中心，其服务启动的时候先把服务元数据注册到metadata线程上面，我们称为meta data service。然后consumer发现provider之后，第一个先调用的服务就是meta data service，拉取整个元数据，这种模式之下在平台上就可以只部署一个注册中心，无需配置中心，它也是最简单最方便的部署模式。

除此之外还有三种部署模式：

第一种，无需注册中心，把K8s的API server当作注册中心，但是这种方式有它的利弊。

第二种，只部署元数据中心，不要注册中心，但是consumer怎么拉取 provider列表？有K8s service/CoreDNS/API server等解决方案。这种模式使用的通讯方式是通信直连模式，基本上大部分的微服务框架都是支持的。

第三种，注册中心加元数据中心都不要，注册中心依然使用K8s的service，或者是借助于CoreDNS实现服务的注册，consumer寻找provider的元数据时，使用local模式，启动时去调用 getMetaDataService，拉取元数据。这种通信直联方式下，也无需配置中心。

而配置中心的好处，相当于可以在微服务基础设施 Dubbogo这个平台下，拉取一些动态的配置参数，动态拉取路由条件进行灰度发布、蓝绿发布，非常灵活。

微服务基础设施的使用和部署，需要根据各个技术特点来保证我们的服务的稳定性，这中间除了我们开发人员，需要运维以及测试等各个方面通力合作。通过考虑公司的规模以及各种特点，综合决策使用哪种技术方案。

END

《新程序员001-004》全面上市，对话世界级大师，报道中国IT行业创新创造

— 推荐阅读 —
☞俄罗斯 IT 存储空间告急，未来 2 月或将耗尽？
☞代码投毒、删库跑路，开源生态链安全该如何保证？
☞大厂螺丝钉还是开源极客？开源新手该怎么选？

一键三连 「分享」「点赞」「在看」

成就一亿技术人