原標(biāo)題：服務(wù)化改造實(shí)踐(二)| Dubbo + Kubernetes

摘要： “沒有最好的技術(shù)，只有最合適的技術(shù)。”我想這句話也同樣適用于微服務(wù)領(lǐng)域，沒有最好的服務(wù)框架，只有最適合自己的服務(wù)改造。在Dubbo的未來規(guī)劃中，除了保持自身技術(shù)上的領(lǐng)先性，關(guān)注性能，大流量，大規(guī)模集群領(lǐng)域的挑戰(zhàn)外，圍繞Dubbo核心來發(fā)展生態(tài)，將Dubbo打造成一個(gè)服務(wù)化改造的整體方案也是重點(diǎn)之一。

“沒有最好的技術(shù)，只有最合適的技術(shù)。”我想這句話也同樣適用于微服務(wù)領(lǐng)域，沒有最好的服務(wù)框架，只有最適合自己的服務(wù)改造。在Dubbo的未來規(guī)劃中，除了保持自身技術(shù)上的領(lǐng)先性，關(guān)注性能，大流量，大規(guī)模集群領(lǐng)域的挑戰(zhàn)外，圍繞Dubbo核心來發(fā)展生態(tài)，將Dubbo打造成一個(gè)服務(wù)化改造的整體方案也是重點(diǎn)之一。這是我們將推出“服務(wù)化改造”系列文章的第二篇，通過在一些外圍系統(tǒng)和服務(wù)化基礎(chǔ)組件上的開發(fā)實(shí)踐，分享Dubbo生態(tài)下的服務(wù)化改造收獲和總結(jié)。

第一篇回顧：Dubbo + ZooKeeper

大體目標(biāo)

大體上：Dubbo的provider不在關(guān)心服務(wù)注冊的事宜，只需要把其Dubbo服務(wù)端口打開，由kubernetes來進(jìn)行服務(wù)的聲明和發(fā)布；Dubbo的consumer在服務(wù)發(fā)現(xiàn)時(shí)直接發(fā)現(xiàn)kubernetes的對應(yīng)服務(wù)endpoints，從而復(fù)用Dubbo已有的微服務(wù)通道能力。好處是無需依賴三方的軟負(fù)載注冊中心；同時(shí)無縫融入kubernetes的多租戶安全體系。Demo的代碼參照： http://gitlab.alibaba-inc.com/kongming.lrq/dubbo-kubernetes/tree/master

閑淡

Kubernates是建立在擴(kuò)展性的具備二次開發(fā)的功能層次豐富的體系化系統(tǒng)

首先其最核心的功能是管理容器集群，能管理容器化的集群(包括存儲，計(jì)算)，當(dāng)然這個(gè)是建立在對容器運(yùn)行時(shí)(CRI)，網(wǎng)絡(luò)接口(CNI),存儲服務(wù)接口(CSI/FV)的基礎(chǔ)上；

其次是面向應(yīng)用(包括無狀態(tài)/有狀態(tài),批處理/服務(wù)型應(yīng)用)的部署和路由能力，特別是基于微服務(wù)架構(gòu)的應(yīng)用管理，具備了其服務(wù)定義和服務(wù)發(fā)現(xiàn)，以及基于configmap的統(tǒng)一配置能力；

在基礎(chǔ)資源(主要是抽象底層IaaS的資源)和應(yīng)用層的抽象模型之上是治理層，包含彈性擴(kuò)容，命名空間/租戶，等。當(dāng)然，基于其原子內(nèi)核的基礎(chǔ)能力，在Kubernetes的核心之上搭建統(tǒng)一的日志中心和全方位監(jiān)控等服務(wù)是水到渠成的，CNCF更是有其認(rèn)定推薦。

來張Kubernetes Architecture的一張圖解釋下上述描述。在2018年Kubernetes往事實(shí)的paas底座的標(biāo)配邁出質(zhì)的一步，有人說原因在于基于擴(kuò)展的二次開發(fā)能力，有人說在于其聲明式編程和背靠Google和Redhat的強(qiáng)大社區(qū)運(yùn)作，我覺得回歸本質(zhì)是在于下圖中的__Layered架構(gòu)和其問題域的領(lǐng)域建模抽象__。

以微服務(wù)架構(gòu)視角，Kubernetes在一定意義上是微服務(wù)框架(這時(shí)較叫微服務(wù)平臺或toolkit集更合適)，支持微服務(wù)的服務(wù)發(fā)現(xiàn)/注冊的基本能力。借用如下圖做一個(gè)簡單描述。

話題再展開一下，微服務(wù)領(lǐng)域涉及眾多問題，大概可以用下圖說明。

kubernetes解決得只是少部分，而像動態(tài)路由，穩(wěn)定性控制(斷路器，隔水艙等)，分布式服務(wù)追蹤等是個(gè)空白，這也就是servicemesh要解決的，是在CNCF的Trail Map占有重要一席；當(dāng)然Dubbo是基本具備完備的微服務(wù)，也就是使得其集成到k8s體系下具有相當(dāng)?shù)囊饬x。Dubbo在serviemesh中基于sidecar的方案是解決跨語言訴求的通用servicemesh方案，需要新開一個(gè)話題來展開說；而引用serviemsh的原始定義：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application.

首先服務(wù)網(wǎng)格是一個(gè)云原生環(huán)境下基礎(chǔ)設(shè)施層，功能在于處理服務(wù)間通信，職責(zé)是負(fù)責(zé)實(shí)現(xiàn)請求的可靠傳遞，被使得被監(jiān)控跟蹤，被治理，最終使得微服務(wù)架構(gòu)被賦予高可控的穩(wěn)定性和快速的問題定位排查能力。

可以得出現(xiàn)有Dubbo集成云原生基礎(chǔ)設(shè)施kubernetes的基礎(chǔ)能力而并解決微服務(wù)相關(guān)核心問題也算是一種狹義上的servicemesh方案，只是是Java領(lǐng)域的罷了；當(dāng)玩笑理解也行，哈哈。

思路/方案

kubernetes是天然可作為微服務(wù)的地址注冊中心，類似于zookeeper， 阿里巴巴內(nèi)部用到的VIPserver，Configserver。 具體來說，kubernetes中的Pod是對于應(yīng)用的運(yùn)行實(shí)例，Pod的被調(diào)度部署/啟停都會調(diào)用API-Server的服務(wù)來保持其狀態(tài)到ETCD；kubernetes中的service是對應(yīng)微服務(wù)的概念，定義如下

A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.

概括來說kubernetes service具有如下特點(diǎn)

每個(gè)Service都有一個(gè)唯一的名字，及對應(yīng)IP。IP是kubernetes自動分配的，名字是開發(fā)者自己定義的。

Service的IP有幾種表現(xiàn)形式，分別是ClusterIP，NodePort,LoadBalance,Ingress。 ClusterIP主要用于集群內(nèi)通信；NodePort，Ingress，LoadBalance用于暴露服務(wù)給集群外的訪問入口。

乍一看，kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思維下：Dubbo/HSF的service是有整個(gè)服務(wù)集群的IP聚合而成，貌似是有本質(zhì)區(qū)別的，細(xì)想下來差別不大，因?yàn)閗ubernetes下的唯一IP只是一個(gè)VIP，背后掛在了多個(gè)endpoint，那才是事實(shí)上的處理節(jié)點(diǎn)。

此處只討論集群內(nèi)的Dubbo服務(wù)在同一個(gè)kubernetes集群內(nèi)訪問；至于kubernetes外的consumer訪問kubernetes內(nèi)的provider，涉及到網(wǎng)絡(luò)地址空間的問題，一般需要GateWay/loadbalance來做映射轉(zhuǎn)換，不展開討論。針對kubernetes內(nèi)有兩種方案可選：

DNS： 默認(rèn)kubernetes的service是靠DNS插件(最新版推薦是coreDNS)， Dubbo上有個(gè)proposal是關(guān)于這個(gè)的。我的理解是static resolution的機(jī)制是最簡單最需要支持的一種service discovery機(jī)制，具體也可以參考Envoy在此的觀點(diǎn)，由于HSF/Dubbo一直突出其軟負(fù)載的地址發(fā)現(xiàn)能力，反而忽略Static的策略。同時(shí)螞蟻的SOFA一直是支持此種策略，那一個(gè)SOFA工程的工程片段做一個(gè)解釋。這樣做有兩個(gè)好處，1)當(dāng)軟負(fù)載中心crash不可用造成無法獲取地址列表時(shí)，有一定的機(jī)制Failover到此策略來處理一定的請求。 2)在LDC/單元化下，螞蟻的負(fù)載中心集群是機(jī)房/區(qū)域內(nèi)收斂部署的，首先保證軟負(fù)載中心的LDC化了進(jìn)而穩(wěn)定可控，當(dāng)單元需要請求中心時(shí)，此VIP的地址發(fā)現(xiàn)就排上用場了。

API：DNS是依靠DNS插件進(jìn)行的，相當(dāng)于額外的運(yùn)維開銷，所以考慮直接通過kubernetes的client來獲取endpoint。事實(shí)上，通過訪問kubernetes的API server接口是可以直接獲取某個(gè)servie背后的endpoint列表，同時(shí)可以監(jiān)聽其地址列表的變化。從而實(shí)現(xiàn)Dubbo/HSF所推薦的軟負(fù)載發(fā)現(xiàn)策略。具體可以參考代碼：

以上兩種思路都需要考慮以下兩點(diǎn)

kubernetes和Dubbo對于service的名字是映射一致的。Dubbo的服務(wù)是由serviename，group，version三個(gè)來確定其唯一性，而且servicename一般其服務(wù)接口的包名稱，比較長。需要映射kubernetes的servie名與dubbo的服務(wù)名。要么是像SOFA那樣增加一個(gè)屬性來進(jìn)行定義，這個(gè)是改造大點(diǎn)，但最合理；要么是通過固定規(guī)則來引用部署的環(huán)境變量，可用于快速驗(yàn)證。

端口問題。默認(rèn)Pod與Pod的網(wǎng)絡(luò)互通算是解決了。需要驗(yàn)證。

Demo驗(yàn)證

下面通過阿里云的容器鏡像服務(wù)和EDAS中的kubernetes服務(wù)來做一次Demo部署。

訪問阿里云-》容器鏡像服務(wù)，創(chuàng)建鏡像倉庫并綁定github代碼庫。如下圖

點(diǎn)擊管理進(jìn)行創(chuàng)建好的倉庫，通過鏡像服務(wù)下的構(gòu)建功能，把demo構(gòu)建成image，并發(fā)布到指定倉庫。如下圖。

切換到企業(yè)級分布式應(yīng)用服務(wù)(EDAS)產(chǎn)品，在資源管理 - 》集群 下創(chuàng)建kubernetes集群并綁定ECS，如下圖.

應(yīng)用管理 -》創(chuàng)建應(yīng)用，類型為kubernetes應(yīng)用 并且指定在容器鏡像服務(wù)中的鏡像。如下圖。

創(chuàng)建完成后，進(jìn)行應(yīng)用部署。如下圖

補(bǔ)充

應(yīng)用名不能有大寫字母，是要小寫，否則有部署失敗的問題。

在創(chuàng)建應(yīng)用時(shí)，選中鏡像后，下一步的按鈕無法點(diǎn)擊，需要點(diǎn)擊選擇繼續(xù)。

EDAS有兩套獨(dú)立的kubernetes服務(wù)，一套是基于阿里云的容器服務(wù)，一套是Lark自己搞的。本人體驗(yàn)的是后者。

Docker與IDE集成的開發(fā)聯(lián)調(diào)，需要考慮集成IDEA的相關(guān)插件。

作者：中間件小哥

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。返回搜狐，查看更多

責(zé)任編輯：

總結(jié)

以上是生活随笔為你收集整理的dubbo k8s 服务发现_服务化改造实践（二）| Dubbo + Kubernetes的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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