本系列文章將為大家介紹當下最流行的服務治理、微服務等相關內容，從服務治理、SOA、微服務到最新的服務網格（Service Mesh）進行綜合介紹和分析。易商阜極自2017年開始積極引進微服務的理念，並運用於多個專案實踐中，為專案升級改造帶來了顯著效果。本文將以Dubbo為例，向大家介紹SOA、服務治理等概念，以及Dubbo的基礎知識和最新發展情況。
SOA（面向服務的體系結構）概念由來已久，在10多年前便開始進入到我們廣大軟體開發者的視線中。SOA是一種粗粒度、松耦合服務架構，服務之間透過簡單、精確定義介面進行通訊，不涉及底層程式設計介面和通訊模型。SOA可以看作是B/S模型、Web Service技術之後的自然延伸。
服務治理，也稱為SOA治理，是指用來管理SOA的採用和實現的過程。以下是在2006年時IBM對於服務治理要點的總結：
-
服務定義（服務的範圍、介面和邊界）
-
服務部署生命週期（各個生命週期階段）
-
服務版本治理（包括相容性）
-
服務遷移（啟用和退役）
-
服務註冊中心（依賴關係）
-
服務訊息模型（規範資料模型）
-
服務監視（進行問題確定）
-
服務所有權（企業組織）
-
服務測試（重覆測試）
-
服務安全（包括可接受的保護範圍）
限於當時的技術發展水平，廣大軟體設計與開發人員對於SOA和服務治理的技術認知還主要停留在Web Service和ESB匯流排等技術和規範上，並沒有真正在軟體開發中得以充分落地。
直到2011年10月27日，阿裡巴巴開源了自己的SOA服務化治理方案的核心框架Dubbo，服務治理和SOA的設計理念開始逐漸在國內軟體行業中落地，並被廣泛應用。
Dubbo作為阿裡巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經每天為2000+個服務提供3,000,000,000+次訪問量支援，並被廣泛應用於阿裡巴巴集團的各成員站點。Dubbo自2011年開源後，已被許多非阿裡系公司使用，其中既有噹噹網、網易考拉等網際網路公司，也有中國人壽、青島海爾等傳統企業。
Dubbo是一個高效能服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案，使得應用可透過高效能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫整合。
作為一個分散式服務框架，以及SOA治理方案，Dubbo其功能主要包括：高效能NIO通訊及多協議整合，服務動態定址與路由，軟負載均衡與容錯，依賴分析與服務降級等。Dubbo最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。從服務模型的角度來看，Dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。
Dubbo包含遠端通訊、叢集容錯和自動發現三個核心部分。提供透明化的遠端方法呼叫，實現像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何API侵入。同時具備軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。可以實現服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者。
下圖來自Dubbo官網，描述了服務註冊中心、服務提供方、服務消費方、服務監控中心之間的呼叫關係，具體如下圖所示：
| 節點 |
角色說明 |
| Provider |
暴露服務的服務提供方。 |
| Consumer |
呼叫遠端服務的服務消費方。 |
| Registry |
服務註冊與發現的註冊中心。 |
| Monitor |
統計服務的呼叫次數和呼叫時間的監控中心。 |
-
服務容器負責啟動，載入，執行服務提供者。
-
服務提供者在啟動時，向註冊中心註冊自己提供的服務。
-
服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
-
註冊中心傳回服務提供者地址串列給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
-
服務消費者，從提供者地址串列中，基於軟負載均衡演演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
-
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
Dubbo框架設計共劃分了10層，最上面的Service層是留給實際使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面，位於中軸線上的為雙方都用到的介面。
-
Config配置層：對外配置介面，以ServiceConfig、ReferenceConfig為中心，可以直接初始化配置類，也可以透過Spring解析配置生成配置類。
-
Proxy服務代理層：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充套件介面為ProxyFactory。
-
Registry註冊中心層：封裝服務地址的註冊與發現，以服務URL為中心，擴充套件介面為RegistryFactory、Registry、RegistryService。
-
Cluster路由層：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心，擴充套件介面為Cluster、Directory、Router、LoadBalance。
-
Monitor監控層：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴充套件介面為MonitorFactory、Monitor、MonitorService。
-
Protocol遠端呼叫層：封將RPC呼叫，以Invocation、Result為中心，擴充套件介面為Protocol、Invoker、Exporter。
-
Exchange資訊交換層：封裝請求響應樣式，同步轉非同步，以Request、Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
-
Transport網路傳輸層：抽象MINA和Netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server、Codec。
-
Serialize資料序列化層：可復用的一些工具，擴充套件介面為Serialization、ObjectInput、ObjectOutput、ThreadPool。
-
dubbo-common公共邏輯模組：包括Util類和通用模型。
-
dubbo-remoting遠端通訊模組：相當於Dubbo協議的實現，如果RPC用 RMI協議則不需要使用此包。
-
dubbo-rpc遠端呼叫模組：抽象各種協議，以及動態代理，只包含一對一的呼叫，不關心叢集的管理。
-
dubbo-cluster叢集模組：將多個服務提供方偽裝為一個提供方，包括：負載均衡、容錯、路由等，叢集的地址串列可以是靜態配置的，也可以是由註冊中心下發。
-
dubbo-registry註冊中心模組：基於註冊中心下發地址的叢集方式，以及對各種註冊中心的抽象。
-
dubbo-monitor監控模組：統計服務呼叫次數、呼叫時間的、呼叫鏈跟蹤的服務。
-
dubbo-config配置模組：是Dubbo對外的API，使用者透過Config使用Dubbo，隱藏Dubbo所有細節。
-
dubbo-container容器模組：是一個Standlone的容器，以簡單的Main載入Spring啟動，因為服務通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去載入服務。
-
Dubbo協議（預設協議）
-
Hessian協議
-
HTTP協議
-
RMI協議
-
WebService協議
-
Thrift協議
-
Memcached協議
-
Redis協議
Multicast註冊中心不需要啟動任何中心節點，只要廣播地址一樣，就可以互相發現。組播受網路結構限制，只適合小規模應用或開發階段使用。組播地址段：224.0.0.0 – 239.255.255.255。
ZooKeeper是Apacahe子專案，是一個樹型的目錄服務，支援變更推送，適合作為Dubbo服務的註冊中心，可用於生產環境。
-
服務提供者（Provider）啟動時，向/dubbo/com.foo.BarService/providers目錄下寫入URL。
-
服務消費者（Consumer）啟動時，訂閱/dubbo/com.foo.BarService/providers目錄下的URL，向/dubbo/com.foo.BarService/consumers目錄下寫入自己的URL。
-
監控中心（Monitor）啟動時，訂閱/dubbo/com.foo.BarService目錄下的所有提供者和消費者URL。
阿裡內部並沒有採用Redis做為註冊中心，而是使用自己實現的基於資料庫的註冊中心，即：Redis註冊中心並沒有在阿裡內部長時間執行的可靠性保障，此Redis橋接實現只為開源版本提供，其可靠性依賴於Redis本身的可靠性。
Simple註冊中心本身就是一個普通的Dubbo服務，可以減少第三方依賴，使整體通訊方式一致。只是簡單實現，不支援叢集，可作為自定義註冊中心的參考，但不適合直接用於生產環境。
遠端通訊需要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語意的基礎上，還要保證高效、穩定的訊息傳輸。Dubbo繼承了當前主流的網路通訊框架，主要包括如下幾個：
從2012年10月23日Dubbo 2.5.3釋出後，在Dubbo開源將滿一週年之際，阿裡基本停止了對Dubbo的主要升級。只在之後的2013年和2014年更新過2次對Dubbo 2.4的維護版本，然後停止了所有維護工作。Dubbo對Srping的支援也停留在了Spring 2.5.6版本上。
在阿裡停止維護和升級Dubbo期間，噹噹網開始維護自己的Dubbo分支版本Dubbox，支援了新版本的Spring，並對外開源了Dubbox。同時，網易考拉也維護了自己的獨立分支Dubbok，可惜並未對外開源。
經過多年漫長的等待，隨著微服務的火熱興起，在國內外開發者對阿裡不再升級維護Dubbo的吐槽聲中，阿裡終於開始重新對Dubbo的升級和維護工作。在2017年9月7日 ，阿裡釋出了Dubbo的2.5.4版本，距離上一個版本2.5.3釋出已經接近快5年時間了。在隨後的幾個月中，阿裡Dubbo開發團隊以差不多每月一版本的速度開始快速升級迭代，修補了Dubbo老版本多年來存在的諸多bug，並對Spring等元件的支援進行了全面升級。
在2018年1月8日，Dubbo 2.6.0版本釋出，新版本將之前噹噹網開源的Dubbo分支Dubbox進行了合併，實現了Dubbo版本的統一整合。
阿裡巴巴負責主導了 Dubbo 重啟維護的研發工程師劉軍在接受採訪時表示：當前由於 RPC 協議、註冊中心元資料不匹配等問題，在面臨微服務基礎框架選型時Dubbo與Spring Cloud是隻能二選一，這也是為什麼大家總是拿Dubbo和Spring Cloud做對比的原因之一。Dubbo之後會積極尋求適配到Spring Cloud生態，比如作為Spring Cloud的二進位制通訊方案來發揮Dubbo的效能優勢，或者Dubbo透過模組化以及對http的支援適配到Spring Cloud。
2018年1月8日，Dubbo創始人之一梁飛在Dubbo交流群裡透露了Dubbo 3.0正在動工的訊息。Dubbo 3.0核心與Dubbo 2.0完全不同，但相容Dubbo 2.0。Dubbo 3.0將以Streaming為核心，不再是Dubbo時代的RPC，但是RPC會在Dubbo 3.0中變成遠端Streaming對接的一種可選形態。Dubbo 3.0將支援可選Service Mesh，多加一層IPC，這主要是為了相容老系統，而內部則會優先嘗試內嵌樣式。代理樣式Ops可獨立升級框架，減少業務侵入，而內嵌樣式可以帶業務測試、部署節點少、穩定性檢測方便。同時，可以將Dubbo 3.0啟動為獨立行程，由dubbo-mesh進行IPC，路由、負載均衡和熔斷機制將由獨立行程控制。
從 Dubbo 新版本的路線規劃上可以看出，新版本的Dubbo在原有服務治理的功能基礎上，將全面擁抱微服務和Service Mesh。同時，考慮到在阿裡雲已經有了Dubbo的商業版本，在未來一段時間內，Dubbo的更新與維護應該不會再長時間中斷。在我們進行服務治理以及微服務架構設計時，新版本Dubbo對我們廣大開發者來說都將會是一個不錯的選擇。
-
http://dubbo.io
-
https://github.com/alibaba/dubbo
-
http://shiyanjun.cn/archives/325.html
-
http://mp.weixin.qq.com/s/eVYx-tUIMYtAk5wP-qkdkw
本次培訓包含：Kubernetes核心概念；Kubernetes叢集的安裝配置、運維管理、架構規劃；Kubernetes元件、監控、網路；針對於Kubernetes API介面的二次開發；DevOps基本理念；微服務架構；微服務的容器化等，點選識別下方二維碼加微信好友瞭解具體培訓內容。
2月1日正式開課，還有最後3個名額，點選閱讀原文連結即可報名。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
知識星球
