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

资讯 作者:CSDN 2022-03-18 13:15:38 阅读:356

嘉宾 |赵新(于雨)  整理 | 雷济慈

出品 | 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 月或将耗尽?
☞代码投毒、删库跑路,开源生态链安全该如何保证?
☞大厂螺丝钉还是开源极客?开源新手该怎么选?

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

成就一亿技术人

在线申请SSL证书行业最低 =>立即申请

[广告]赞助链接:

关注数据与安全,洞悉企业级服务市场:https://www.ijiandao.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

#
公众号 关注KnowSafe微信公众号
随时掌握互联网精彩
赞助链接