聊聊Dubbo（一）：爲什麼選擇

1. 前言

隨着如今互聯網行業的發展，愈來愈多的框架、中間件、容器等開源技術不斷地涌現，更好地來服務於業務，實現業務並解決問題。然而面對衆多的技術選擇，咱們要如何甄別出適合本身團隊業務的技術呢？對於人來講，鞋子過大，可能影響奔跑的速度，鞋子太小，可能影響身體的成長。技術對於業務也是如此的關係。

因此，相對於技術的學習、搭建、使用、運維等技能，咱們 對技術的甄別選擇更是重中之重。那麼本文要講的Dubbox框架，又是如何在衆多的服務框架中脫穎而出，被團隊選中踐行服務之路？

2. 服務

2.1 爲何要作服務

技術爲業務而生，架構也爲業務而出現。隨着業務的發展、用戶量的增加，系統數量增多，調用依賴關係也變得複雜，爲了確保系統高可用、高併發的要求，系統的架構也從單體時代慢慢遷移至服務SOA時代，根據不一樣服務對系統資源的要求不一樣，咱們能夠更合理的配置系統資源，使系統資源利用率最大化。

1. 單一應用架構 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
2. 垂直應用架構 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
3. 分佈式服務架構 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
4. 流動計算架構 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。 此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

平臺隨着業務的發展 從 All in One 環境 就能夠知足業務需求（以Java來講，可能只是一兩個war包就解決了）；發展到需 要拆分多個應用，而且採用MVC的方式 分離先後端，加快開發效率；在發展到服務愈來愈多，不得不將 一些核心或共用的服務拆分出來，提供實時流動監控計算等，其實發展到此階段，若是服務拆分的足夠精細，而且獨立運行，這個時候至少能夠 理解爲SOA（Service-Oriented Architecture）架構 了。

2.2 服務帶來的挑戰

當迎來服務SOA時代，咱們面臨要解決的問題會不少，好比：系統的複雜度上升、服務依賴關係、服務性能監控、全鏈路日誌、容災、斷路器、限流等。那麼面對這些問題爲何還要作分佈式服務呢？由於在將來只有砥礪前行，才能走的更高更遠。不過看到這些問題不要氣餒，先無論這些問題，讓咱們一步步來梳理下現存有什麼問題，咱們要完成什麼目標，問題天然會迎刃而解。

根據如今團隊的業務系統狀況，首先咱們要梳理出現存的問題是什麼：

1. 多種調用傳輸方式：HTTP方式、WebService方式；
2. 服務調用依賴關係：人工記錄，查看代碼分析；
3. 服務調用性能監控：日誌記錄，人工查看時間；
4. 服務與應用緊耦合：服務掛掉，應用沒法可用；
5. 服務集羣負載配置：Nginx配置，存在單點問題；

在去選擇技術框架時，技術框架最基本要解決上面現存問題，同時咱們也要確認出咱們的指望，要達到的目標是什麼：

1. 支持當前業務需求，這是最最基本的條件；
2. 服務避免單點問題，去中心化；
3. 服務高可用、高併發，解耦服務依賴；
4. 服務通用化，支持異構系統調用服務；
5. 服務依賴關係自維護，可視化；
6. 服務性能監控自統計，可視化；
7. 服務需自帶註冊、發現、健康檢查、負載均衡等特性；
8. 開發人員關注度高，上手快，簡單輕量，低侵入；

還有最重要一點，這也是每每不少技術人員進入的誤區，「對於技術，不要爲了使用而使用，用最簡單合適的技術實現解決問題纔是正道」。架構是服務於業務的，能快速方便的知足業務需求的架構纔是好的架構。

2.3 服務將來的趨勢

一談到服務，可能你們不少據說過SOA、MSA等服務的概念名詞，近幾年MSA炒的比較火，其實每個概念的背後都在解決不一樣的問題。此類名詞的最大特色就是 一解釋就懂，一問就不知，一討論就打架。

SOA、MSA二者說到底都是對外提供接口的一種架構設計方式。我倒以爲微服務其實就是隨着互聯網的發展，複雜的平臺、業務的出現，致使SOA架構向更細粒度、更通用化程度發展，就成了所謂的微服務了。以這種說法作爲根據，我以爲SOA與微服務的區別在於以下幾個方面：

1. 微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並沒有影響；
2. 微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各類終端均可以調用，無關語言、平臺限制；
3. 微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合；

微服務與SOA有不少相同之處。二者都屬於典型的、包含鬆耦合分佈式組件的系統結構。在圍繞着服務的概念建立架構這一方面，微服務提供了一種更清晰、定義更良好的方式。微服務的原則與敏捷軟件開發思想是高度一致的，而它與SOA原則的演化的目標也是相同的，則減小傳統的企業服務總線開發的高複雜性。二者之間最關鍵的區別在於，微服務專一於以自治的方式產生價值。可是兩種架構背後的意圖是不一樣的：SOA嘗試將應用集成，通常採用中央管理模式來確保各應用可以交互運做。微服務嘗試部署新功能，快速有效地擴展開發團隊。它着重於分散管理、代碼再利用與自動化執行。

功能	SOA	微服務
組件大小	大塊業務邏輯	單獨任務或小塊業務邏輯
耦合	一般鬆耦合	老是鬆耦合
公司架構	任何類型	小型、專一於功能交叉的團隊
管理	着重中央管理	着重分散管理
目標	確保應用可以交互操做	執行新功能，快速拓展開發團隊

微服務並非一種新思想的方法。它更像是一種思想的精煉，一種SOA的精細化演進，而且更好地利用了先進的技術以解決問題，例如容器與自動化等。因此對於咱們 去選擇服務技術框架時，並非非黑即白，而是針對SOA、MSA兩種架構設計同時要考慮到兼容性，對於現有平臺狀況架構設計，退則守SOA，進則攻MSA，階段性選擇適合的。

3. 框架

如今業界比較成熟的服務框架有不少，好比：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技術實現，均可以進行遠程調用，具體技術實現優劣參考如下分析，這也是具體在技術方案選擇過程當中的重要依據。

3.1 服務框架對比

Dubbo 是阿里巴巴公司開源的一個Java高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和 Spring框架無縫集成。不過，略有遺憾的是，聽說在淘寶內部，dubbo因爲跟淘寶另外一個相似的框架HSF（非開源）有競爭關係，致使dubbo團隊已經解散，反到是噹噹網的擴展版本Dubbox仍在持續發展，牆內開花牆外香。其它的一些知名電商如噹噹、國美維護了本身的分支或者在dubbo的基礎開發，可是官方的庫缺少維護，相關的依賴類好比Spring，Netty仍是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),卻是有些網友寫了升級Spring和Netty的插件。

Dubbox和Dubbo本質上沒有區別，名字的含義擴展了Dubbo而已，如下擴展出來的功能，也是選擇Dubbox很重要的考察點。

1. 支持REST風格遠程調用（HTTP + JSON/XML)；
2. 支持基於Kryo和FST的Java高效序列化實現；
3. 支持基於Jackson的JSON序列化；
4. 支持基於嵌入式Tomcat的HTTP remoting體系；
5. 升級Spring至3.x；
6. 升級ZooKeeper客戶端；
7. 支持徹底基於Java代碼的Dubbo配置；

Spring Cloud徹底基於Spring Boot，是一個很是新的項目，2016年推出1.0的release版本，目前Github上更新速度很快. 雖然Spring Cloud時間最短, 可是相比Dubbo等RPC框架, Spring Cloud提供的全套的分佈式系統解決方案。Spring Cloud 爲開發者提供了在分佈式系統（配置管理，服務發現，熔斷，路由，微代理，控制總線，一次性token，全局瑣，leader選舉，分佈式session，集羣狀態）中快速構建的工具，使用Spring Cloud的開發者能夠快速的啓動服務或構建應用。它們將在任何分佈式環境中工做，包括開發人員本身的筆記本電腦，裸物理機的數據中心，和像Cloud Foundry雲管理平臺。在將來引領這微服務架構的發展，提供業界標準的一套微服務架構解決方案。

缺點是項目很年輕，不多見到國內業界有人在生產上成套使用，通常都是隻有其中一兩個組件。相關的技術文檔大部分是英文的，案例也相對較少，使用的話須要摸索的時間會長一些。

下圖是Spring Cloud和Dubbo對比：

Motan是新浪微博開源的一個Java 框架。它誕生的比較晚，起於2013年，2016年5月開源。Motan 在微博平臺中已經普遍應用，天天爲數百個服務完成近千億次的調用。與Dubbo相比，Motan在功能方面並無那麼全面，也沒有實現特別多的擴展。用的人比較少，功能和穩定性有待觀望。對跨語言調用支持較差，主要支持java。

Hessian採用的是 二進制RPC協議，適用於發送二進制數據。但自己也是一個Web Service框架對RPC調用提供支持，功能簡單，使用起來也方便。基於Http協議進行傳輸。經過Servlet提供遠程服務。經過Hessain自己提供的API來發起請求。響應端根據Hessian提供的API來接受請求。

Hessian優勢：

1. 整個jar很小，輕量；
2. 配置簡單；
3. 功能強大，拋開了soap(simple object access protocal 簡單對象訪問協議)、ejb，採用二進制來傳遞對象；

rpcx是Go語言生態圈的Dubbo， 比Dubbo更輕量，實現了Dubbo的許多特性，藉助於 Go語言優秀的併發特性和簡潔語法，可使用較少的代碼實現分佈式的RPC服務。

gRPC是Google開發的高性能、通用的開源RPC框架，其由Google主要面向移動應用開發並基於HTTP/2協議標準而設計，基於ProtoBuf(Protocol Buffers)序列化協議開發，且支持衆多開發語言。自己它不是分佈式的，因此要實現上面的框架的功能須要進一步的開發。

thrift是Apache的一個跨語言的高性能的服務框架，也獲得了普遍的應用。

以上RPC框架功能比較：

功能	Hessian	Montan	rpcx	gRPC	Thrift	Dubbo	Dubbox	Spring Cloud
開發語言	跨語言	Java	Go	跨語言	跨語言	Java	Java	Java
分佈式(服務治理)	×	√	√	×	×	√	√	√
多序列化框架支持	hessian	√(支持Hessian二、Json,可擴展)	√	× 只支持protobuf)	×(thrift格式)	√	√	√
多種註冊中心	×	√	√	×	×	√	√	√
管理中心	×	√	√	×	×	√	√	√
跨編程語言	√	×(支持php client和C server)	×	√	√	×	×	×
支持REST	×	×	×	×	×	×	√	√
關注度	低	中	低	中	中	中	高	中
上手難度	低	低	中	中	中	低	低	中
運維成本	低	中	中	中	低	中	中	中
開源機構	Caucho	Weibo	Apache	Google	Apache	Alibaba	Dangdang	Apache

實際場景中的選擇

1. Spring Cloud：Spring全家桶，用起來很舒服，只有你想不到，沒有它作不到。惋惜由於發佈的比較晚，國內還沒出現比較成功的案例，大部分都是試水，不過畢竟有Spring做背書，仍是比較看好。
2. Dubbox：相對於Dubbo支持了REST，估計是不少公司選擇Dubbox的一個重要緣由之一，但若是使用Dubbo的RPC調用方式，服務間仍然會存在API強依賴，各有利弊，懂的取捨吧。
3. Thrift：若是你比較高冷，徹底能夠基於Thrift本身搞一套抽象的自定義框架吧。
4. Montan：可能由於出來的比較晚，目前除了新浪微博16年初發布的，
5. Hessian：若是是初創公司或系統數量尚未超過5個，推薦選擇這個，畢竟在開發速度、運維成本、上手難度等都是比較輕量、簡單的，即便在之後遷移至SOA，也是無縫遷移。
6. rpcx/gRPC：在服務沒有出現嚴重性能的問題下，或技術棧沒有變動的狀況下，可能一直不會引入，即便引入也只是小部分模塊優化使用。

3.2 RPC vs REST(JAX-RS)

因爲Dubbo是基礎框架，其實現的內容對於咱們實施微服務架構是否合理，也須要咱們根據自身需求去考慮是否要修改，好比Dubbo的服務調用是經過RPC實現的，可是若是仔細拜讀過Martin Fowler的microservices一文，其定義的服務間通訊是HTTP協議的REST API。那麼這兩種有何區別呢？

1. 服務提供方與調用方接口依賴方式太強

   咱們爲每一個微服務定義了各自的service抽象接口，並經過持續集成發佈到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關係，所以不論開發、測試、集成環境都須要嚴格的管理版本依賴，纔不會出現服務方與調用方的不一致致使應用沒法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，每每一個依賴不少服務的上層應用，天天都要更新不少代碼並install以後才能進行後續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關係會成爲開發團隊的一大噩夢。而REST接口相比RPC更爲輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，固然REST接口也有痛點，由於接口定義太輕，很容易致使定義文檔與實際實現不一致致使服務集成時的問題，可是該問題很好解決，只須要經過每一個服務整合swagger，讓每一個服務的代碼與文檔一體化，就能解決。因此在分佈式環境下，REST方式的服務依賴要比RPC方式的依賴更爲靈活。

2. 服務對平臺敏感，難以簡單複用

   一般咱們在提供對外服務時，都會 以REST的方式提供出去，這樣能夠實現跨平臺的特色，任何一個語言的調用方均可以根據接口定義來實現。那麼在Dubbo中咱們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發布。若咱們每一個服務自己就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關係和權限控制就可實現服務的複用了。

相信這些痛點也是爲何當當網在dubbox（基於Dubbo的開源擴展）中增長了對REST支持的緣由之一。

Dubbo實現了服務治理的基礎，可是要完成一個完備的微服務架構，還須要在各環節去擴展和完善以保證集羣的健康，以減輕開發、測試以及運維各個環節上增長出來的壓力，這樣才能讓各環節人員真正的專一於業務邏輯。

而Spring Cloud依然發揚了Spring Source整合一切的做風，以標準化的姿態將一些微服務架構的成熟產品與框架揉爲一體，並繼承了Spring Boot簡單配置、快速開發、輕鬆部署的特色，讓本來複雜的架構工做變得相對容易上手一些。因此，若是選擇Dubbo請務必在各個環節作好整套解決方案的準備，否則極可能隨着服務數量的增加，整個團隊都將疲於應付各類架構上不足引發的困難。而若是選擇Spring Cloud，相對來講每一個環節都已經有了對應的組件支持，可能有些也不必定能知足你全部的需求，可是其活躍的社區與高速的迭代進度也會是你能夠依靠的強大後盾。

4. Dubbox帶來什麼

4.1 Dubbo服務治理

特性	描述
透明遠程調用	就像調用本地方法同樣調用遠程方法；只需簡單配置，沒有任何API侵入；
負載均衡機制	Client端LB，可在內網替代F5等硬件負載均衡器；
容錯重試機制	服務Mock數據，重試次數、超時機制等；
自動註冊發現	註冊中心基於接口名查詢服務提 供者的IP地址，而且可以平滑添加或刪除服務提供者；
性能日誌監控	Monitor統計服務的調用次調和調用時間的監控中心；
服務治理中心	路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡，等手動配置。
自動治理中心	無，好比：熔斷限流機制、自動權重調整等；

4.2 Dubbox擴展特性

1. 支持REST風格遠程調用（HTTP + JSON/XML)；
2. 支持基於Kryo和FST的Java高效序列化實現；
3. 支持基於Jackson的JSON序列化；
4. 支持基於嵌入式Tomcat的HTTP remoting體系；
5. 升級Spring至3.x；
6. 升級ZooKeeper客戶端；
7. 支持徹底基於Java代碼的Dubbo配置；

5. 參考資料與推薦閱讀

1. 分佈式RPC框架性能大比拼
2. 實施微服務，咱們須要哪些基礎框架？
3. 微服務（Microservice）那點事
4. Spring Cloud微服務框架主要子項目和RPC框架的對比
5. 微服務、SOA 和 API：是敵是友？
6. 微服務與SOA的實踐應用對比
7. 微服務架構的基礎框架選擇：Spring Cloud仍是Dubbo？
8. 微服務與SOA架構
9. Web Service實踐之REST vs RPC
10. RPC好，仍是RESTful好？
11. Rpc和Rest接口，微服務之Rpc
12. WEB開發中，使用JSON-RPC好，仍是RESTful API好？