感謝2020雲原生微服務給我帶來了雲原生的希望！
Dubbo3擁抱雲原生更新總體路線
我們會側重于下面紅色填充的部分，針對于Dubbo3雲原生技術的領域的探索和研究：
看Dubbo3帶來了什麼？
要是說到Dubbo想必大家應該知道，它是一個Java技術領域的RPC架構，但是為什麼今天要把它和雲原生挂鈎了呢？因為迎接着雲原生的不斷更新和更新，Dubbo沒有停滞不前，創造了Dubbo3，它摒棄了之前的缺點，進而創造了更多更多的奇迹，特别是相容了雲原生技術。
“鼠”年給雲原生建立好的開端
摘自官網資料中的Dubbo3的虎年的發展計劃：
“牛”年完美收官和中肯評價
Dubbo3是Apache頂級項目Dubbo的一個非常具有裡程碑性質的版本，它是讓Dubbo服務體系全面擁抱雲原生的一個重要節點。
去年的11月會官方又釋出了Dubbo3.1版本，同時社群也組織了相關的Dubbo在Mesh 場景下部署的實作與實踐的案例分享沙龍
“虎”年Dubbo3虎虎生威！
官方計劃在今年3月會釋出Dubbo3.2版本：這個版本中将帶來全新的大規模應用部署下智能流量排程機制，提高系統穩定性與資源使用率。
Dubbo3目前已經和阿裡巴巴集團内部的 RPC 架構實作了融合，期望用它來解決内部落地問題，做到技術棧統一。（官方介紹）
直奔主題，邁向雲原生時代
如果你看到了這裡，那麼接下來你将會認識Dubbo3的誕生将如何引領微服務領域更進一步，進而邁入雲原生的領域，這當然不僅僅是Dubbo3，之前也介紹了Java生态另外一個雲原生領域的技術Quarkus等技術，而本文内容側重點去介紹Dubbo3邁向雲原生的技術分析和探索，如果有不正确的地方，還需要大家多多指正。
如何轉型微服務到雲原生？
如今已經全面得到全面發展的雲原生技術時代，Dubbo3全面擁抱雲原生，将Dubbo原本的架構進行了更新，形成 【全新的服務發現模型】、 【下一代雲原生服務通信協定】 和 【完美支援雲原生基礎設施】 的方案。
- （取其精華）Dubbo3依然會保留之前已有的開箱即用和落地實踐的優點。
- （去其糟粕）Dubbo3将會剔除不符合雲原生架構理念，将會更好的複用底層雲原生基礎設施并且将會更加支援雲原生的微服務架構。
去其糟粕，重新整頓治理模型
雲原生走出的重要一步
了解Dubbo的開發者都知道，Dubbo之前的服務治理都是接口層級的。同一個應用釋出的多個服務會在注冊中心注冊多份資料，注冊服務的中繼資料互相獨立。但是存儲在注冊中心中的資料會在很大程度上存在重複的内容，其實浪費了一部分的存儲。
對超大規模的影響
當整個叢集的規模足夠大的時候，由于服務注冊發現是服務次元的，注冊中心的資料量就會爆發式地增長。
在2020年雲原生微服務大會上，Dubbo已經出現了服務治理層面的改造更新的雛形，它将原本的接口層級的服務治理模型改造成為了應用層級，同時也引入了其他的核心元件，完美的解決了接口以及應用指令層面的都相容的場景！下圖就是兩種不同方式的服務治理機制：
左邊圖是Dubbo早起版本的架構模型，右邊圖是Dubbo3的服務治理架構圖。
主要總體和新的服務治理機制劃分了兩個狀态：
- 部署态：接口應用的映射，主要通過了上面的中繼資料中心，可進行管理接口到應用的映射以及應用級的中繼資料。Dubbo架構會自動上報這個關系到中繼資料中心。
- 運作态：會将Dubbo側的配置以及運作使用者側的配置和服務治理則通過這份映射關系重新将應用粒度映射到接口粒度，此部分同時也會上報的中繼資料中心
- 會将作為應用服務執行個體和應用綁定關系進行上報，應用級選址和接口級選址同時存在，友善進行服務治理。
存儲的模型結構案例
{
"name": "provider-service",
"id": "192.168.1.1:20880",
"address": "192.168.0.102",
"port": 20880,
"sslPort": null,
"payload": {
"id": null,
"name": "provider-service",
"metadata": {
"metadataService": "{\"dubbo\":{\"version\":\"1.0.0\",\"dubbo\":\"2.0.2\",\"release\":\"2.7.5\",\"port\":\"20881\"}}",
"endpoints": "[{\"port\":20880,\"protocol\":\"dubbo\"}]",
"storage-type": "local",
"revision": "6785535733750099598",
}
},
"registrationTimeUTC": 1583461240877,
"serviceType": "DYNAMIC",
"uriSpec": null
} 異構化體系或者語言通信
Dubbo與其他服務生态的通信
目前Spring cloud和K8s 都是基于執行個體，也就是應用級别進行的注冊發現，Dubbo要成為連接配接異構系統最好用的RPC架構就需要支援執行個體粒度；
應用級别治理機制，打通了與其他微服務體系之間在位址發現層面的鴻溝，也成為适配 Kubernetes Native Service 等基礎設施的技術理論基礎。
去其糟粕，開創跨生态協定
如果想要完成對雲原生的轉化出了上述解決了的問題之外，仍然還要有兩個需要攻克的難題：
協定不夠标準和通用化，導緻語言生态無法互通
Dubbo原有的協定提供了RPC技術體系的核心骨架組成。其中，協定頭、标志位、請求 ID 以及請求/響應資料，如下圖所示。
Dubbo協定基于二進制流定制了與 RPC 強綁定的核心語義：上圖所示就是之前Dubbo版本的協定組成部分，其結構分布會讓使用者很難直接了解，基本上都屬于Dubbo自定義以及非标準的格式組成部分。細節不多說，大家可以看到有16位的高魔術頭和低魔術頭組成、資料包協定類型，事件類型、序列化方式等。而對于越來越多的雲原生治理設施，比如Kubernete Service。
協定頭包含的原始資料資訊過多，對雲原生的介入造成阻礙
Dubbo協定的協定頭已無法再承載更多的中繼資料資訊。Service Mesh元件，需要對資料進行治理那麼需要對更加完整的資料包進行解析才能擷取到必要的中繼資料資訊（如 RPC 上下文），從性能到易用性方面都會面臨挑戰。
協定層面需要做的改進和更新要點
- 需要一個統一格式和标準的跨語言
- 采用Grpc和Http2的協定格式，作為統一的标準化格式協定基礎，并且支援原生的grpc協定模式
- 此外還可以支援平滑的支援遷移到protobuf協定機制
- 需要較為完整的服務治理的功能機制
- 采用了較為符合雲原生服務架構機制，應用層級的服務治理體系。
- 協定應該提供更完善的請求模型，除了 Request/Response 模型，還應該支援 Streaming 和 Bidirectional；
下一代雲原生協定——Triple協定機制
Triple協定是Dubbo3新時代産物協定，它可以相容gRPC和HTTP/2，并在協定層面擴充了負載均衡和流量控制相關機制，以及可以在原有的基礎上進行對protobuf協定的平滑遷移處理。
- （與GRPC的互通性）Dubbo3新協定是基于GRPC擴充的協定，這也保證了在生态系統上新協定和 GRPC 是能夠互通和共享的；
- （與Protobuf遷移性）在序列化方面，新協定會在序列化方面給予足夠的支援，平滑的适配現有序列化，友善遷移到Protobuf；
更多内容可以參考文章：https://dubbo.apache.org/zh/docs/v3.0/references/tri/
相容Kubernetes基礎設施元件
針對于Kubernetes的基礎設施的相容和介入，主要包含兩個部分：Kubernetes 生命周期對齊探針和Mesh的支援。
對齊 K8s 的生命周期
能夠讓 Dubbo 服務原生的在 K8s 體系内注冊和發現，這都要歸功于自身所帶的探針技術。K8s的Pod的生命周期與服務排程息息相關，通過對 Kubernetes 官方探針的實作，能夠使 Dubbo乃至整個應用的生命周期與 Pod 的生命周期對齊。
通過Dubbo的SPI機制，在内部實作多種“探針”，基于Dubbo QOS運維子產品的HTTP服務，使容器探針能夠擷取到應用内對應探針的狀态。另外，SPI 的實作機制也利于使用者自行拓展内部“探針”，使整個應用的生命周期更有效的進行管控。
- Startup 啟動探針
- Liveness 存活探針
- Readiness 就緒探針
Triple協定通過使用HTTP2進行 header/payload分離解決了網關需要解析完整協定的問題。
Mesh的xDS的機制體系
服務注冊發現和治理，注冊發現需要 Dubbo 能夠在 Mesh的xDS體系内作為資料面打通。
治理則需要将原有的規則逐漸遷移至基于 YAML 的剔除 IP 依賴的規則。最終的形态将是原生的 Dubbo 服務能夠和基于 thin SDK 的 Dubbo + Mesh 完美互通和進行服務治理。
Service Name - > Dubbo RPC Service，Kubernetes要維護排程的服務與應用内建 RPC 服務綁定，維護的服務數量變多，而對于Kubernetes Service 作為一個抽象概念，Service Name - > Application Name，Dubbo應用和Kubernetes 服務一一對應，對于微服務運維和建設環節透明，與開發階段解耦，例如service配置一樣。
apiVersion: v1
kind: Service
metadata:
name: rpc-service-1
spec:
selector:
app: provider-app-name
ports: ##
---
apiVersion: v1
kind: Service
metadata:
name: rpc-service-2
spec:
selector:
app: provider-app-name
ports: ##
---
apiVersion: v1
kind: Service
metadata:
name: rpc-service-N
spec:
selector:
app: provider-app-name
ports: ##
... Dubbo3的架構分布
摘自官網的Dubbo3的架構分布，細思極恐，多麼完整和龐大的生态，祝願Dubbo3，虎年蒸蒸日上，光彩奪目，為雲原生時代，提供更多的力量和能源。