2个维度5大方法，让你的微服务在K8s上跑起来
嘉宾 |赵新（于雨） 整理 | 雷济慈
出品 | CSDN（ID：CSDNnews）
蚂蚁集团可信原生部(TNT)，dubbogo社区负责人于雨在2022云原生超级英雄会上做了Apache/Dubbogo的K8s解决方案分享。
点击看完整版视频
云原生时代的微服务如何在K8s上进行部署和使用？Dubbogo社区负责人于雨从Dubbogo的K8s解决方案为你解答！#云原生#微服务#技术#K8s#开发者
K8s VS 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里获取自己的信息。
云原生时代，怎么在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
《》全面上市，对话世界级大师，报道中国IT行业创新创造
— 推荐阅读 —
一键三连 「分享」「点赞」「在看」
成就一亿技术人