服務化改造實踐（二）| 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...

閒淡
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的相關插件。