Dubbo-go k8s注冊(cè)中心設(shè)計(jì)方案與實(shí)現(xiàn)
隨著云原生的推廣，越來越多的公司或組織將服務(wù)容器化，并將容器化后的服務(wù)部署在k8s集群中。

今天這篇文章將會(huì)介紹dubbo-go將k8s作為服務(wù)注冊(cè)中心的方案設(shè)計(jì)，以及具體實(shí)現(xiàn)。到目前為止該方案的實(shí)現(xiàn)已經(jīng)被合并到dubbo-go的master分支。具體實(shí)現(xiàn)為關(guān)于Kubernetes的PullRequest。

k8s管理資源的哲學(xué)
k8s作為容器集群化管理方案可以將管理資源的維度可主觀的分為服務(wù)實(shí)例管理和服務(wù)接入管理。

服務(wù)實(shí)例管理，主要體現(xiàn)方式為Pod設(shè)計(jì)模式加控制器模式。控制器保證具有特定標(biāo)簽（Label）的Pod保持在恒定的數(shù)量（多刪，少補(bǔ)）。
服務(wù)接入管理，主要為Service，該Service默認(rèn)為具有特定標(biāo)簽（Label）的一批Pod提供一個(gè)VIP（ClusterIP）作為服務(wù)的接入點(diǎn)，默認(rèn)會(huì)按照round-robin的負(fù)載均衡策略將請(qǐng)求轉(zhuǎn)發(fā)到真正提供服務(wù)的Pod。并且CoreDNS為該Service提供集群內(nèi)唯一的域名。
k8s服務(wù)發(fā)現(xiàn)模型
為了明確k8s在服務(wù)接入管理提供的解決方案，我們以kube-apiserver 提供的API(HTTPS)服務(wù)為例。k8s集群為該服務(wù)分配了一個(gè)集群內(nèi)有效的ClusterIP，并通過CoreDNS為其分配了唯一的域名 kubernetes 。如果集群內(nèi)的Pod需要訪問該服務(wù)時(shí)直接通過https://kubernetes:443即可完成。

lADPD2eDMWswXhPNBEXNBEs_1099_1093_jpg_720x720q90g

具體流程如上圖所示(紅色為客戶端，綠色為kube-apiserver)：

首先客戶端通過CoreDNS解析域名為kubernetes的服務(wù)獲得對(duì)應(yīng)的ClusterIP為10.96.0.1。
客戶端向10.96.0.1發(fā)起HTTPS請(qǐng)求。
HTTPS之下的TCP連接被kube-proxy創(chuàng)建的iptables的PREROUTING鏈攔截并DNAT 為 10.0.2.16或10.0.2.15。
Client與最終提供服務(wù)的Pod建立連接并交互。
由此可見，k8s提供的服務(wù)發(fā)現(xiàn)為域名解析級(jí)別。

Dubbo服務(wù)發(fā)現(xiàn)模型
同樣為了明確Dubbo服務(wù)發(fā)現(xiàn)的模型，以一個(gè)簡單的Dubbo-Consumer發(fā)現(xiàn)并訪問Provider的具體流程為例。

lALPD4Bhp_yd3sTNAarNA_A_992_426_png_720x720q90g

具體流程如上圖所示：

Provider將本進(jìn)程的元數(shù)據(jù)注冊(cè)到Registry中，包括IP，Port，以及服務(wù)名稱等。
Consumer通過Registry獲取Provider的接入信息，直接發(fā)起請(qǐng)求
由此可見，Dubbo當(dāng)前的服務(wù)發(fā)現(xiàn)模型是針對(duì)Endpoint級(jí)別的，并且注冊(cè)的信息不只IP和端口還包括其他的一些元數(shù)據(jù)。

K8s service vs dubbo-go 服務(wù)
通過上述兩個(gè)小節(jié)，答案基本已經(jīng)比較清晰了。總結(jié)一下，無法直接使用k8s的服務(wù)發(fā)現(xiàn)模型的原因主要為以下幾點(diǎn):

k8s的Service標(biāo)準(zhǔn)的資源對(duì)象具有的服務(wù)描述字段 中并未提供完整的Dubbo進(jìn)程元數(shù)據(jù)字段因此，無法直接使用該標(biāo)準(zhǔn)對(duì)象進(jìn)行服務(wù)注冊(cè)與發(fā)現(xiàn)。
dubbo-do的服務(wù)注冊(cè)是基于每個(gè)進(jìn)程的，每個(gè)Dubbo進(jìn)程均需進(jìn)行獨(dú)立的注冊(cè)。
k8s的Service默認(rèn)為服務(wù)創(chuàng)建VIP，提供round-robin的負(fù)載策略也與Dubbo-go自有的Cluster模塊的負(fù)載策略形成了沖突。
Dubbo-go 當(dāng)前的方案
服務(wù)注冊(cè)
K8s基于Service對(duì)象實(shí)現(xiàn)服務(wù)注冊(cè)/發(fā)現(xiàn)。可是dubbo現(xiàn)有方案為每個(gè)dubbo-go進(jìn)程獨(dú)立注冊(cè)，因此dubbo-go選擇將該進(jìn)程具有的獨(dú)有的元數(shù)據(jù)寫入運(yùn)行該dubbo-go進(jìn)程的Pod在k8s中的Pod資源對(duì)象的描述信息中。每個(gè)運(yùn)行dubbo進(jìn)程的Pod將本進(jìn)程的元數(shù)據(jù)寫入Pod的Annotations字段。為了避免與其他使用Annotations字段的Operator或者其他類型的控制器（istio）的字段沖突。dubbo-go使用Key為 dubbo.io/annotation value為具體存儲(chǔ)的K/V對(duì)的數(shù)組的json編碼后的base64編碼。

樣例為：

apiVersion: v1
kind: Pod
metadata:
? annotations:
? ? dubbo.io/annotation: W3siayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJibyIsInYiOiIifSx7ImsiOiIvZHViYm8vY29tLmlrdXJlbnRvLnVzZXIuVXNlclByb3ZpZGVyIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvcHJvdmlkZXJzIiwidiI6IiJ9LHsiayI6Ii9kdWJiby9jb20uaWt1cmVudG8udXNlci5Vc2VyUHJvdmlkZXIvY29uc3VtZXJzL2NvbnN1bWVyJTNBJTJGJTJGMTcyLjE3LjAuOCUyRlVzZXJQcm92aWRlciUzRmNhdGVnb3J5JTNEY29uc3VtZXJzJTI2ZHViYm8lM0RkdWJib2dvLWNvbnN1bWVyLTIuNi4wJTI2cHJvdG9jb2wlM0RkdWJibyIsInYiOiIifV0=
由于每個(gè)dubbo-go的Pod均只負(fù)責(zé)注冊(cè)本進(jìn)程的元數(shù)據(jù)，因此Annotations字段長度也不會(huì)因?yàn)檫\(yùn)行dubbo-go進(jìn)程的Pod數(shù)量增加而增加。

服務(wù)發(fā)現(xiàn)
依賴kube-apiserver 提供了WATCH的功能。可以觀察特定namespace內(nèi)各Pod對(duì)象的變化。dubbo-go為了避免dubbo-go進(jìn)程WATCH到與dubbo-go進(jìn)程無關(guān)的Pod的變化，dubbo-go將WATCH的條件限制在當(dāng)前Pod所在的namespace，以及僅WATCH具有Key為 dubbo.io/label Value為 dubbo.io-value 的Pod。在WATCH到對(duì)應(yīng)Pod的變化后實(shí)時(shí)更新本地Cache，并通過Registry提供的Subscribe接口通知建立在注冊(cè)中心之上的服務(wù)集群管理其他模塊。

總體設(shè)計(jì)圖
lALPD4d8pTZEENfNA1PNBQA_1280_851_png_720x720q90g

具體流程如上圖所示：

啟動(dòng)dubbo-go的Deployment或其他類型控制器使用k8s Downward-Api將本Pod所在namespace通過環(huán)境變量的形式注入dubbo-go進(jìn)程。
Consumer/Provider進(jìn)程所在的Pod啟動(dòng)后通過環(huán)境變量獲得當(dāng)前的namespace以及該P(yáng)od名稱， 調(diào)用kube-apiserver PATCH 功能為本Pod添加Key為dubbo.io/label Value為 dubbo.io-value 的label。
Consumer/Provider進(jìn)程所在的Pod啟動(dòng)后調(diào)用kube-apiserver將本進(jìn)程的元數(shù)據(jù)通過PATCH接口寫入當(dāng)前Pod的Annotations字段。
Consumer進(jìn)程通過kube-apiserver LIST 當(dāng)前namespace下其他具有同樣標(biāo)簽的Pod，并解碼對(duì)應(yīng)的Annotations字段獲取Provider的信息。
Consumer進(jìn)程通過kube-apiserver WATCH 當(dāng)前namespace下其他具有同樣label的Pod的Annotations的字段變化，動(dòng)態(tài)更新本地Cache。
總結(jié)
k8s已經(jīng)為其承載的服務(wù)提供了一套服務(wù)發(fā)現(xiàn)，服務(wù)注冊(cè)，以及服務(wù)集群管理機(jī)制。而dubbo-go的同時(shí)也擁有自成體系的服務(wù)集群管理。這兩個(gè)功能點(diǎn)形成了沖突，在無法調(diào)諧兩者的情況，dubbo-go團(tuán)隊(duì)決定保持dubbo自有的服務(wù)集群管理系，而選擇性的放棄了Service功能，將元數(shù)據(jù)直接寫入到Pod對(duì)象的Annotations中。

當(dāng)然這只是dubbo-go在將k8s作為服務(wù)注冊(cè)中心的方案之一，后續(xù)社區(qū)會(huì)以更加“云原生”的形式對(duì)接k8s，讓我們拭目以待吧。

dubbo-go 社區(qū)釘釘群 :23331795 ,歡迎你的加入。

作者信息：王翔，GithubID: sxllwx，就職于成都達(dá)闥科技有限公司，golang開發(fā)工程師。

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的Dubbo-gok8s注册中心设计方案与实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。