本系列文章將為大家介紹當(dāng)下最流行的服務(wù)治理、微服務(wù)等相關(guān)內(nèi)容，從服務(wù)治理、SOA、微服務(wù)到最新的服務(wù)網(wǎng)格（Service Mesh）進(jìn)行綜合介紹和分析。易商阜極自2017年開始積極引進(jìn)微服務(wù)的理念，并運用于多個項目實踐中，為項目升級改造帶來了顯著效果。本文將以Dubbo為例，向大家介紹SOA、服務(wù)治理等概念，以及Dubbo的基礎(chǔ)知識和最新發(fā)展情況。

SOA與服務(wù)治理

SOA（面向服務(wù)的體系結(jié)構(gòu)）概念由來已久，在10多年前便開始進(jìn)入到我們廣大軟件開發(fā)者的視線中。SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口進(jìn)行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、Web Service技術(shù)之后的自然延伸。

服務(wù)治理，也稱為SOA治理，是指用來管理SOA的采用和實現(xiàn)的過程。以下是在2006年時IBM對于服務(wù)治理要點的總結(jié)：

• 服務(wù)定義（服務(wù)的范圍、接口和邊界）

• 服務(wù)部署生命周期（各個生命周期階段）

• 服務(wù)版本治理（包括兼容性）

• 服務(wù)遷移（啟用和退役）

• 服務(wù)注冊中心（依賴關(guān)系）

• 服務(wù)消息模型（規(guī)范數(shù)據(jù)模型）

• 服務(wù)監(jiān)視（進(jìn)行問題確定）

• 服務(wù)所有權(quán)（企業(yè)組織）

• 服務(wù)測試（重復(fù)測試）

• 服務(wù)安全（包括可接受的保護(hù)范圍）

限于當(dāng)時的技術(shù)發(fā)展水平，廣大軟件設(shè)計與開發(fā)人員對于SOA和服務(wù)治理的技術(shù)認(rèn)知還主要停留在Web Service和ESB總線等技術(shù)和規(guī)范上，并沒有真正在軟件開發(fā)中得以充分落地。

Dubbo開源

直到2011年10月27日，阿里巴巴開源了自己的SOA服務(wù)化治理方案的核心框架Dubbo，服務(wù)治理和SOA的設(shè)計理念開始逐漸在國內(nèi)軟件行業(yè)中落地，并被廣泛應(yīng)用。

Dubbo作為阿里巴巴內(nèi)部的SOA服務(wù)化治理方案的核心框架，在2012年時已經(jīng)每天為2000+個服務(wù)提供3,000,000,000+次訪問量支持，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點。Dubbo自2011年開源后，已被許多非阿里系公司使用，其中既有當(dāng)當(dāng)網(wǎng)、網(wǎng)易考拉等互聯(lián)網(wǎng)公司，也有中國人壽、青島海爾等傳統(tǒng)企業(yè)。

Dubbo簡介

Dubbo是一個高性能服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案，使得應(yīng)用可通過高性能RPC實現(xiàn)服務(wù)的輸出和輸入功能，和Spring框架可以無縫集成。

作為一個分布式服務(wù)框架，以及SOA治理方案，Dubbo其功能主要包括：高性能NIO通訊及多協(xié)議集成，服務(wù)動態(tài)尋址與路由，軟負(fù)載均衡與容錯，依賴分析與服務(wù)降級等。Dubbo最大的特點是按照分層的方式來架構(gòu)，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。從服務(wù)模型的角度來看，Dubbo采用的是一種非常簡單的模型，要么是提供方提供服務(wù)，要么是消費方消費服務(wù)，所以基于這一點可以抽象出服務(wù)提供方（Provider）和服務(wù)消費方（Consumer）兩個角色。

Dubbo包含遠(yuǎn)程通訊、集群容錯和自動發(fā)現(xiàn)三個核心部分。提供透明化的遠(yuǎn)程方法調(diào)用，實現(xiàn)像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，只需簡單配置，沒有任何API侵入。同時具備軟負(fù)載均衡及容錯機制，可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器，降低成本，減少單點。可以實現(xiàn)服務(wù)自動注冊與發(fā)現(xiàn)，不再需要寫死服務(wù)提供方地址，注冊中心基于接口名查詢服務(wù)提供者的IP地址，并且能夠平滑添加或刪除服務(wù)提供者。

下圖來自Dubbo官網(wǎng)，描述了服務(wù)注冊中心、服務(wù)提供方、服務(wù)消費方、服務(wù)監(jiān)控中心之間的調(diào)用關(guān)系，具體如下圖所示：

節(jié)點角色說明：

調(diào)用關(guān)系說明：

1. 服務(wù)容器負(fù)責(zé)啟動，加載，運行服務(wù)提供者。

2. 服務(wù)提供者在啟動時，向注冊中心注冊自己提供的服務(wù)。

3. 服務(wù)消費者在啟動時，向注冊中心訂閱自己所需的服務(wù)。

4. 注冊中心返回服務(wù)提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。

5. 服務(wù)消費者，從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺提供者進(jìn)行調(diào)用，如果調(diào)用失敗，再選另一臺調(diào)用。

6. 服務(wù)消費者和提供者，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

Dubbo總體架構(gòu)

Dubbo框架設(shè)計共劃分了10層，最上面的Service層是留給實際使用Dubbo開發(fā)分布式服務(wù)的開發(fā)者實現(xiàn)業(yè)務(wù)邏輯的接口層。圖中左邊淡藍(lán)背景的為服務(wù)消費方使用的接口，右邊淡綠色背景的為服務(wù)提供方使用的接口，位于中軸線上的為雙方都用到的接口。

各層說明：

● Config配置層：對外配置接口，以ServiceConfig、ReferenceConfig為中心，可以直接初始化配置類，也可以通過Spring解析配置生成配置類。
● Proxy服務(wù)代理層：服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心，擴展接口為ProxyFactory。
● Registry注冊中心層：封裝服務(wù)地址的注冊與發(fā)現(xiàn)，以服務(wù)URL為中心，擴展接口為RegistryFactory、Registry、RegistryService。
● Cluster路由層：封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心，以Invoker為中心，擴展接口為Cluster、Directory、Router、LoadBalance。
● Monitor監(jiān)控層：RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以Statistics為中心，擴展接口為MonitorFactory、Monitor、MonitorService。
● Protocol遠(yuǎn)程調(diào)用層：封將RPC調(diào)用，以Invocation、Result為中心，擴展接口為Protocol、Invoker、Exporter。
● Exchange信息交換層：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以Request、Response為中心，擴展接口為Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
● Transport網(wǎng)絡(luò)傳輸層：抽象MINA和Netty為統(tǒng)一接口，以Message為中心，擴展接口為Channel、Transporter、Client、Server、Codec。
● Serialize數(shù)據(jù)序列化層：可復(fù)用的一些工具，擴展接口為Serialization、ObjectInput、ObjectOutput、ThreadPool。

模塊分包

各模塊說明：

● dubbo-common公共邏輯模塊：包括Util類和通用模型。
● dubbo-remoting遠(yuǎn)程通訊模塊：相當(dāng)于Dubbo協(xié)議的實現(xiàn)，如果RPC用 RMI協(xié)議則不需要使用此包。
● dubbo-rpc遠(yuǎn)程調(diào)用模塊：抽象各種協(xié)議，以及動態(tài)代理，只包含一對一的調(diào)用，不關(guān)心集群的管理。
● dubbo-cluster集群模塊：將多個服務(wù)提供方偽裝為一個提供方，包括：負(fù)載均衡、容錯、路由等，集群的地址列表可以是靜態(tài)配置的，也可以是由注冊中心下發(fā)。
● dubbo-registry注冊中心模塊：基于注冊中心下發(fā)地址的集群方式，以及對各種注冊中心的抽象。
● dubbo-monitor監(jiān)控模塊：統(tǒng)計服務(wù)調(diào)用次數(shù)、調(diào)用時間的、調(diào)用鏈跟蹤的服務(wù)。
● dubbo-config配置模塊：是Dubbo對外的API，用戶通過Config使用Dubbo，隱藏Dubbo所有細(xì)節(jié)。
● dubbo-container容器模塊：是一個Standlone的容器，以簡單的Main加載Spring啟動，因為服務(wù)通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去加載服務(wù)。

協(xié)議支持

● Dubbo協(xié)議（默認(rèn)協(xié)議）
● Hessian協(xié)議
● HTTP協(xié)議
● RMI協(xié)議
● WebService協(xié)議
● Thrift協(xié)議
● Memcached協(xié)議
● Redis協(xié)議

注冊中心

1、Multicast注冊中心：

Multicast注冊中心不需要啟動任何中心節(jié)點，只要廣播地址一樣，就可以互相發(fā)現(xiàn)。組播受網(wǎng)絡(luò)結(jié)構(gòu)限制，只適合小規(guī)模應(yīng)用或開發(fā)階段使用。組播地址段：224.0.0.0 - 239.255.255.255。

2、ZooKeeper注冊中心（推薦）：

ZooKeeper是Apacahe子項目，是一個樹型的目錄服務(wù)，支持變更推送，適合作為Dubbo服務(wù)的注冊中心，可用于生產(chǎn)環(huán)境。

對上圖流程說明如下：

1. 服務(wù)提供者（Provider）啟動時，向/dubbo/com.foo.BarService/providers目錄下寫入URL。

2. 服務(wù)消費者（Consumer）啟動時，訂閱/dubbo/com.foo.BarService/providers目錄下的URL，向/dubbo/com.foo.BarService/consumers目錄下寫入自己的URL。

3. 監(jiān)控中心（Monitor）啟動時，訂閱/dubbo/com.foo.BarService目錄下的所有提供者和消費者URL。

3、Redis注冊中心：

阿里內(nèi)部并沒有采用Redis做為注冊中心，而是使用自己實現(xiàn)的基于數(shù)據(jù)庫的注冊中心，即：Redis注冊中心并沒有在阿里內(nèi)部長時間運行的可靠性保障，此Redis橋接實現(xiàn)只為開源版本提供，其可靠性依賴于Redis本身的可靠性。

4、Simple注冊中心：

Simple注冊中心本身就是一個普通的Dubbo服務(wù)，可以減少第三方依賴，使整體通訊方式一致。只是簡單實現(xiàn)，不支持集群，可作為自定義注冊中心的參考，但不適合直接用于生產(chǎn)環(huán)境。

遠(yuǎn)程通信與信息交換

遠(yuǎn)程通信需要指定通信雙方所約定的協(xié)議，在保證通信雙方理解協(xié)議語義的基礎(chǔ)上，還要保證高效、穩(wěn)定的消息傳輸。Dubbo繼承了當(dāng)前主流的網(wǎng)絡(luò)通信框架，主要包括如下幾個：

● Mina
● Netty（默認(rèn)）
● Grizzly

停止維護(hù)

從2012年10月23日Dubbo 2.5.3發(fā)布后，在Dubbo開源將滿一周年之際，阿里基本停止了對Dubbo的主要升級。只在之后的2013年和2014年更新過2次對Dubbo 2.4的維護(hù)版本，然后停止了所有維護(hù)工作。Dubbo對Srping的支持也停留在了Spring 2.5.6版本上。

分支出現(xiàn)

在阿里停止維護(hù)和升級Dubbo期間，當(dāng)當(dāng)網(wǎng)開始維護(hù)自己的Dubbo分支版本Dubbox，支持了新版本的Spring，并對外開源了Dubbox。同時，網(wǎng)易考拉也維護(hù)了自己的獨立分支Dubbok，可惜并未對外開源。

重獲新生

經(jīng)過多年漫長的等待，隨著微服務(wù)的火熱興起，在國內(nèi)外開發(fā)者對阿里不再升級維護(hù)Dubbo的吐槽聲中，阿里終于開始重新對Dubbo的升級和維護(hù)工作。在2017年9月7日 ，阿里發(fā)布了Dubbo的2.5.4版本，距離上一個版本2.5.3發(fā)布已經(jīng)接近快5年時間了。在隨后的幾個月中，阿里Dubbo開發(fā)團(tuán)隊以差不多每月一版本的速度開始快速升級迭代，修補了Dubbo老版本多年來存在的諸多bug，并對Spring等組件的支持進(jìn)行了全面升級。

分支合并

在2018年1月8日，Dubbo 2.6.0版本發(fā)布，新版本將之前當(dāng)當(dāng)網(wǎng)開源的Dubbo分支Dubbox進(jìn)行了合并，實現(xiàn)了Dubbo版本的統(tǒng)一整合。

Dubbo與Spring Cloud

阿里巴巴負(fù)責(zé)主導(dǎo)了 Dubbo 重啟維護(hù)的研發(fā)工程師劉軍在接受采訪時表示：當(dāng)前由于 RPC 協(xié)議、注冊中心元數(shù)據(jù)不匹配等問題，在面臨微服務(wù)基礎(chǔ)框架選型時Dubbo與Spring Cloud是只能二選一，這也是為什么大家總是拿Dubbo和Spring Cloud做對比的原因之一。Dubbo之后會積極尋求適配到Spring Cloud生態(tài)，比如作為Spring Cloud的二進(jìn)制通信方案來發(fā)揮Dubbo的性能優(yōu)勢，或者Dubbo通過模塊化以及對http的支持適配到Spring Cloud。

未來展望

2018年1月8日，Dubbo創(chuàng)始人之一梁飛在Dubbo交流群里透露了Dubbo 3.0正在動工的消息。Dubbo 3.0內(nèi)核與Dubbo 2.0完全不同，但兼容Dubbo 2.0。Dubbo 3.0將以Streaming為內(nèi)核，不再是Dubbo時代的RPC，但是RPC會在Dubbo 3.0中變成遠(yuǎn)程Streaming對接的一種可選形態(tài)。Dubbo 3.0將支持可選Service Mesh，多加一層IPC，這主要是為了兼容老系統(tǒng)，而內(nèi)部則會優(yōu)先嘗試內(nèi)嵌模式。代理模式Ops可獨立升級框架，減少業(yè)務(wù)侵入，而內(nèi)嵌模式可以帶業(yè)務(wù)測試、部署節(jié)點少、穩(wěn)定性檢測方便。同時，可以將Dubbo 3.0啟動為獨立進(jìn)程，由dubbo-mesh進(jìn)行IPC，路由、負(fù)載均衡和熔斷機制將由獨立進(jìn)程控制。

總結(jié)

從 Dubbo 新版本的路線規(guī)劃上可以看出，新版本的Dubbo在原有服務(wù)治理的功能基礎(chǔ)上，將全面擁抱微服務(wù)和Service Mesh。同時，考慮到在阿里云已經(jīng)有了Dubbo的商業(yè)版本，在未來一段時間內(nèi)，Dubbo的更新與維護(hù)應(yīng)該不會再長時間中斷。在我們進(jìn)行服務(wù)治理以及微服務(wù)架構(gòu)設(shè)計時，新版本Dubbo對我們廣大開發(fā)者來說都將會是一個不錯的選擇。