原標題：服務化改造實踐(二)| Dubbo + Kubernetes

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

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

第一篇回顧：Dubbo + ZooKeeper

大體目標

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

閑淡

Kubernates是建立在擴展性的具備二次開發的功能層次豐富的體系化系統

首先其最核心的功能是管理容器集群，能管理容器化的集群(包括存儲，計算)，當然這個是建立在對容器運行時(CRI)，網絡接口(CNI),存儲服務接口(CSI/FV)的基礎上；

其次是面向應用(包括無狀態/有狀態,批處理/服務型應用)的部署和路由能力，特別是基于微服務架構的應用管理，具備了其服務定義和服務發現，以及基于configmap的統一配置能力；

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

來張Kubernetes Architecture的一張圖解釋下上述描述。在2018年Kubernetes往事實的paas底座的標配邁出質的一步，有人說原因在于基于擴展的二次開發能力，有人說在于其聲明式編程和背靠Google和Redhat的強大社區運作，我覺得回歸本質是在于下圖中的__Layered架構和其問題域的領域建模抽象__。

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

話題再展開一下，微服務領域涉及眾多問題，大概可以用下圖說明。

kubernetes解決得只是少部分，而像動態路由，穩定性控制(斷路器，隔水艙等)，分布式服務追蹤等是個空白，這也就是servicemesh要解決的，是在CNCF的Trail Map占有重要一席；當然Dubbo是基本具備完備的微服務，也就是使得其集成到k8s體系下具有相當的意義。Dubbo在serviemesh中基于sidecar的方案是解決跨語言訴求的通用servicemesh方案，需要新開一個話題來展開說；而引用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.

首先服務網格是一個云原生環境下基礎設施層，功能在于處理服務間通信，職責是負責實現請求的可靠傳遞，被使得被監控跟蹤，被治理，最終使得微服務架構被賦予高可控的穩定性和快速的問題定位排查能力。

可以得出現有Dubbo集成云原生基礎設施kubernetes的基礎能力而并解決微服務相關核心問題也算是一種狹義上的servicemesh方案，只是是Java領域的罷了；當玩笑理解也行，哈哈。

思路/方案

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

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具有如下特點

每個Service都有一個唯一的名字，及對應IP。IP是kubernetes自動分配的，名字是開發者自己定義的。

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

乍一看，kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思維下：Dubbo/HSF的service是有整個服務集群的IP聚合而成，貌似是有本質區別的，細想下來差別不大，因為kubernetes下的唯一IP只是一個VIP，背后掛在了多個endpoint，那才是事實上的處理節點。

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

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

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

以上兩種思路都需要考慮以下兩點

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

端口問題。默認Pod與Pod的網絡互通算是解決了。需要驗證。

Demo驗證

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

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

點擊管理進行創建好的倉庫，通過鏡像服務下的構建功能，把demo構建成image，并發布到指定倉庫。如下圖。

切換到企業級分布式應用服務(EDAS)產品，在資源管理 - 》集群 下創建kubernetes集群并綁定ECS，如下圖.

應用管理 -》創建應用，類型為kubernetes應用 并且指定在容器鏡像服務中的鏡像。如下圖。

創建完成后，進行應用部署。如下圖

補充

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

在創建應用時，選中鏡像后，下一步的按鈕無法點擊，需要點擊選擇繼續。

EDAS有兩套獨立的kubernetes服務，一套是基于阿里云的容器服務，一套是Lark自己搞的。本人體驗的是后者。

Docker與IDE集成的開發聯調，需要考慮集成IDEA的相關插件。

作者：中間件小哥

本文為云棲社區原創內容，未經允許不得轉載。返回搜狐，查看更多

責任編輯：

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。