徐員外＃阿里巴巴Dubbo開源服務框架
一、為什麼要介紹dubbo?
目前互聯網分散式服務框架有很多，例如我上次介紹spring cloud技術時提到的Netflix公司eureka等，但從實戰的角度講，Dubbo無疑是目前最好的選擇。
Dubbo是阿里巴巴SOA服務化治理方案的核心框架，每天為2000+個服務提供30+億次訪問量支持，廣泛應用於阿里集團的各成員站點。從上述數據來看，世界範圍內也沒有那家互聯網企業的技術能夠支撐到這麼高的數據，可以說Dubbo是經歷了淘寶雙11秒殺生產環境檢驗的而留下來的優秀技術框架。阿里在幾年前已經選擇將此項技術進行了開源，我們可以通過https://github.com/apache/incubator-dubbo獲取源代碼或相關文檔。
這篇文章的主要內容是基於梁飛的《Dubbo用戶指南》進行總結的，當然這麼強大的技術也不是通過這篇小文能介紹清楚的，這裡主要介紹的閱讀的思路及梳理關鍵技術點。
二、為什麼會是dubbo?
我們從文檔中會發現下面這張圖，這既是一張技術演變的路線圖，也是互聯網項目業務膨脹後的優化圖，從圖中來看，單一ORM框架及傳統的MVC框架，無論怎麼優化，它所支持的並發數量都是有限的，1000已經是一個瓶頸，SOA框架才能支持到10000+的並發
在互聯網領域，你所在的項目，如果所有的伺服器加起來不到100台，那都稱不上互聯網項目，`一個高可用、高性能的互聯網項目，下面兩項大的關鍵技術是必須要考慮的。
1、集群
分為應用、資料庫、資源文件等伺服器的集群，也就是把同樣的系統部署到多台機器上，統一對外提供服務。由此引發了如何調度、數據一致性等一系列問題，在單一的架構裡面，數據、控制邏輯、頁面全在一個項目裡面，耦合性太高，根本無法去做集群，即使做了集群，性能也上不去，我們知道如在數據層面IO讀寫是性能的關鍵，在邏輯層面計算能力是關鍵，在文層面存儲磁碟大小傳輸速度是關鍵，都捆綁在一起，怎麼可能做到高性能高可用。
2、負載均衡
集群帶來的統一分批和管理調度的問題，此時出現了負載均衡的解決方案，如負載均衡的硬體伺服器F5、軟體Nginx等
當我們的系統的邏輯、頁面、數據、文件等分層解耦後，此時將系統裡面不同的業務邏輯封裝成API,通過介面對外提供服務，每個業務邏輯能夠單獨運行部署，能夠獨立存在，存在依賴關係但又互不干涉，但是在系統集群和負載部署後，這麼多的服務如何進行對接、管理和監控，Dubbo技術的出現，專門解決了互聯網分散式項目服務的治理問題。
三、dubbo如何使用?
從上面這張圖可以看出，不同的服務首先要在註冊中心進行註冊，才能夠通過服務治理中心實現服務的調度和監控，由此引發下述概念。
依賴關係圖
1、服務提供者（provider）
將業務邏輯代碼封裝好，供其它服務或系統調用。
2、服務消費者(consumer)
調用服務提供者提供的業務邏輯代碼。
3、服務註冊（Registry）
服務提供者和消費者都需要在此登記。
4、監聽器（monitor）
統計監控雙方之間的調用情況。
在了解上述基本概念後，可以通過下面這張圖從整體上了解dubbo所涉及到的技術及它們之間的關係。
整體設計圖
圖例說明：
·圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面，位於中軸線上的為雙方都用到的介面。
·圖中從下至上分為十層，各層均為單向依賴，右邊的黑色箭頭代表層之間的依賴關係，每一層都可以剝離上層被複用，其中，Service和Config層為API，其它各層均為SPI。
·圖中綠色小塊的為擴展介面，藍色小塊為實現類，圖中只顯示用於關聯各層的實現類。
·圖中藍色虛線為初始化過程，即啟動時組裝鏈，紅色實線為方法調用過程，即運行時調時鏈，紫色三角箭頭為繼承，可以把子類看作父類的同一個節點，線上的文字為調用的方法。
各層說明
·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
關係說明
·在RPC中，Protocol是核心層，也就是只要有Protocol + Invoker +Exporter就可以完成非透明的RPC調用，然後在Invoker的主過程上Filter攔截點。
·圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的了解哪些類分屬於客戶端與伺服器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider, Consumer, Registry, Monitor劃分邏輯拓普節點，保持統一概念。
·而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。
·Proxy層封裝了所有介面的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成介面，或將介面實現轉成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那麼透明，不那麼看起來像調本地服務一樣調遠程服務。
·而Remoting實現是Dubbo協議的實現，如果你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃為Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina, Netty, Grizzly的抽象，它也可以擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
·Registry和Monitor實際上不算一層，而是一個獨立的節點，只是為了全局概覽，用層的方式畫在一起。
調用鏈圖
這部分內容的技術細節不在此文中做描述，感興趣的讀者可以查看《開發者文檔》http://dubbo.apache.org/books/dubbo-dev-book/design.html，如果能夠把整體設計圖和調用鏈圖對照著講清楚，那麼從理解技術的邏輯上來看，對於dubbo技術的技術路線在理解上應該沒有什麼問題了，剩下的具體技術細節，配置參數也沒有必要去死記硬背，知道去翻手冊和github上的源代碼就可以了。
對於後面的章節，主要圍繞著集群和負載均衡，在測試環境、正式環境下怎樣去配置和使用、性能如何提升和優化，此處涉及到zookeeper和redis的使用和集群，在實際的工作中會常用到，大家可以通過手冊中提供的案例源代碼進行試驗。
最後像dubbo這樣優秀的SOA服務治理框架，在項目實際的測試、發布和分散式部署都要實現自動化，所以在實際的生產環境會寫很多自動化的腳本文件來啟動或停止和監控，結合管理控制台如hudson來實現項目的開發和上線。
TAG:xuyuanwai |