轉(zhuǎn)載自：http://www.reibang.com/p/0b6e2c920014

1. 前言

隨著現(xiàn)在互聯(lián)網(wǎng)行業(yè)的發(fā)展，越來越多的框架跃须、中間件蚤吹、容器等開源技術(shù)不斷地涌現(xiàn)，更好地來服務(wù)于業(yè)務(wù)充易，實現(xiàn)業(yè)務(wù)并解決問題梗脾。然而面對眾多的技術(shù)選擇，我們要如何甄別出適合自己團隊業(yè)務(wù)的技術(shù)呢盹靴？對于人來說炸茧，鞋子過大，可能影響奔跑的速度鹉究，鞋子過小宇立，可能影響身體的成長。技術(shù)對于業(yè)務(wù)也是如此的關(guān)系自赔。

所以妈嘹，相對于技術(shù)的學習、搭建绍妨、使用润脸、運維等技能，我們?對技術(shù)的甄別選擇更是重中之重他去。那么本文要講的Dubbox框架毙驯，又是如何在眾多的服務(wù)框架中脫穎而出，被團隊選中踐行服務(wù)之路灾测？

2. 服務(wù)

2.1 為什么要做服務(wù)

技術(shù)為業(yè)務(wù)而生，架構(gòu)也為業(yè)務(wù)而出現(xiàn)媳搪。隨著業(yè)務(wù)的發(fā)展铭段、用戶量的增長，系統(tǒng)數(shù)量增多秦爆，調(diào)用依賴關(guān)系也變得復(fù)雜序愚，為了確保系統(tǒng)高可用、高并發(fā)的要求等限，系統(tǒng)的架構(gòu)也從單體時代慢慢遷移至服務(wù)SOA時代爸吮，根據(jù)不同服務(wù)對系統(tǒng)資源的要求不同，我們可以更合理的配置系統(tǒng)資源望门，使系統(tǒng)資源利用率最大化形娇。

系統(tǒng)架構(gòu)演進

單一應(yīng)用架構(gòu)

當網(wǎng)站流量很小時，只需一個應(yīng)用筹误，將所有功能都部署在一起埂软，以減少部署節(jié)點和成本。

此時，用于簡化增刪改查工作量的?數(shù)據(jù)訪問框架(ORM)?是關(guān)鍵勘畔。

垂直應(yīng)用架構(gòu)

當訪問量逐漸增大所灸，單一應(yīng)用增加機器帶來的加速度越來越小，將應(yīng)用拆成互不相干的幾個應(yīng)用炫七，以提升效率爬立。

此時，用于加速前端頁面開發(fā)的?Web框架(MVC)?是關(guān)鍵万哪。

分布式服務(wù)架構(gòu)

當垂直應(yīng)用越來越多侠驯，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來奕巍，作為獨立的服務(wù)吟策，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求的止。

此時檩坚，用于提高業(yè)務(wù)復(fù)用及整合的?分布式服務(wù)框架(RPC)?是關(guān)鍵。

流動計算架構(gòu)

當服務(wù)越來越多诅福，容量的評估匾委，小服務(wù)資源的浪費等問題逐漸顯現(xiàn)，此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量氓润，提高集群利用率赂乐。

此時，用于提高機器利用率的?資源調(diào)度和治理中心(SOA)?是關(guān)鍵咖气。

平臺隨著業(yè)務(wù)的發(fā)展?從 All in One 環(huán)境?就可以滿足業(yè)務(wù)需求（以Java來說挨措，可能只是一兩個war包就解決了）；發(fā)展到需?要拆分多個應(yīng)用崩溪，并且采用MVC的方式?分離前后端运嗜，加快開發(fā)效率；在發(fā)展到服務(wù)越來越多悯舟，不得不將?一些核心或共用的服務(wù)拆分出來，提供實時流動監(jiān)控計算等砸民，其實發(fā)展到此階段抵怎，如果服務(wù)拆分的足夠精細，并且獨立運行岭参，這個時候至少可以?理解為SOA（Service-Oriented Architecture）架構(gòu)?了反惕。

2.2 服務(wù)帶來的挑戰(zhàn)

當迎來服務(wù)SOA時代，我們面臨要解決的問題會很多演侯，比如：系統(tǒng)的復(fù)雜度上升姿染、服務(wù)依賴關(guān)系、服務(wù)性能監(jiān)控、全鏈路日志悬赏、容災(zāi)狡汉、斷路器、限流等闽颇。那么面對這些問題為什么還要做分布式服務(wù)呢盾戴？因為在未來只有砥礪前行，才能走的更高更遠兵多。不過看到這些問題不要氣餒尖啡，先不管這些問題，讓我們一步步來梳理下現(xiàn)存有什么問題剩膘，我們要完成什么目標衅斩，問題自然會迎刃而解。

根據(jù)現(xiàn)在團隊的業(yè)務(wù)系統(tǒng)情況怠褐，首先我們要梳理出現(xiàn)存的問題是什么：

多種調(diào)用傳輸方式：HTTP方式畏梆、WebService方式；

服務(wù)調(diào)用依賴關(guān)系：人工記錄惫搏，查看代碼分析具温；

服務(wù)調(diào)用性能監(jiān)控：日志記錄，人工查看時間筐赔；

服務(wù)與應(yīng)用緊耦合：服務(wù)掛掉铣猩，應(yīng)用無法可用；

服務(wù)集群負載配置：Nginx配置茴丰，存在單點問題达皿；

那么，在選擇技術(shù)框架時贿肩，技術(shù)框架最基本要解決上面現(xiàn)存問題峦椰，同時我們也要確認出我們的期望，要達到的目標是什么：

支持當前業(yè)務(wù)需求汰规，這是最最基本的條件汤功；

服務(wù)避免單點問題，去中心化溜哮；

服務(wù)高可用滔金、高并發(fā)，解耦服務(wù)依賴茂嗓；

服務(wù)通用化餐茵，支持異構(gòu)系統(tǒng)調(diào)用服務(wù)；

服務(wù)依賴關(guān)系自維護述吸，可視化忿族；

服務(wù)性能監(jiān)控自統(tǒng)計，可視化；

服務(wù)需自帶注冊道批、發(fā)現(xiàn)错英、健康檢查、負載均衡等特性屹徘；

開發(fā)人員關(guān)注度高走趋，上手快，簡單輕量噪伊，低侵入簿煌；

還有最重要一點，這也是往往很多技術(shù)人員進入的誤區(qū)鉴吹，“對于技術(shù)姨伟，不要為了使用而使用，用最簡單合適的技術(shù)實現(xiàn)解決問題才是正道”豆励。架構(gòu)是服務(wù)于業(yè)務(wù)的夺荒，能快速方便的滿足業(yè)務(wù)需求的架構(gòu)才是好的架構(gòu)。

沒有最好的良蒸，只有適合自己的

2.3 服務(wù)未來的趨勢

一談到服務(wù)技扼，可能大家很多聽說過SOA、MSA等服務(wù)的概念名詞嫩痰，近幾年MSA炒的比較火剿吻，其實每一個概念的背后都在解決不同的問題。此類名詞的最大特點就是?一解釋就懂串纺，一問就不知丽旅，一討論就打架。

SOA纺棺、MSA兩者說到底都是對外提供接口的一種架構(gòu)設(shè)計方式榄笙。微服務(wù)其實就是隨著互聯(lián)網(wǎng)的發(fā)展，復(fù)雜的平臺祷蝌、業(yè)務(wù)的出現(xiàn)茅撞，導致SOA架構(gòu)向更細粒度、更通用化程度發(fā)展巨朦，就成了所謂的微服務(wù)了米丘。以這種說法做為根據(jù)，我覺得SOA與微服務(wù)的區(qū)別在于如下幾個方面：

微服務(wù)相比于SOA更加精細罪郊，微服務(wù)更多的以獨立的進程的方式存在，互相之間并無影響尚洽；

微服務(wù)提供的接口方式更加通用化瓦宜，例如HTTP RESTful方式蝶锋，各種終端都可以調(diào)用儿咱，無關(guān)語言边器、平臺限制；

微服務(wù)更傾向于分布式去中心化的部署方式江解，在互聯(lián)網(wǎng)業(yè)務(wù)場景下更適合；

微服務(wù)與SOA有很多相同之處。兩者都屬于典型的邪蛔、包含松耦合分布式組件的系統(tǒng)結(jié)構(gòu)。在圍繞著服務(wù)的概念創(chuàng)建架構(gòu)這一方面扎狱，微服務(wù)提供了一種更清晰侧到、定義更良好的方式。微服務(wù)的原則與敏捷軟件開發(fā)思想是高度一致的淤击，而它與SOA原則的演化的目標也是相同的匠抗，則減少傳統(tǒng)的企業(yè)服務(wù)總線開發(fā)的高復(fù)雜性。兩者之間最關(guān)鍵的區(qū)別在于污抬，微服務(wù)專注于以自治的方式產(chǎn)生價值汞贸。但是兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應(yīng)用集成，一般采用中央管理模式來確保各應(yīng)用能夠交互運作印机。微服務(wù)嘗試部署新功能矢腻，快速有效地擴展開發(fā)團隊。它著重于分散管理射赛、代碼再利用與自動化執(zhí)行多柑。

功能SOA微服務(wù)

組件大小大塊業(yè)務(wù)邏輯單獨任務(wù)或小塊業(yè)務(wù)邏輯

耦合通常松耦合總是松耦合

公司架構(gòu)任何類型小型、專注于功能交叉的團隊

管理著重中央管理著重分散管理

目標確保應(yīng)用能夠交互操作執(zhí)行新功能咒劲，快速拓展開發(fā)團隊

微服務(wù)并不是一種新思想的方法顷蟆。它更像是一種思想的精煉，一種SOA的精細化演進腐魂，并且更好地利用了先進的技術(shù)以解決問題帐偎，例如容器與自動化等。所以對于我們?去選擇服務(wù)技術(shù)框架時蛔屹，并不是非黑即白削樊，而是針對SOA、MSA兩種架構(gòu)設(shè)計同時要考慮到兼容性兔毒，對于現(xiàn)有平臺情況架構(gòu)設(shè)計漫贞，退則守SOA，進則攻MSA育叁，階段性選擇適合的迅脐。

3. 框架

現(xiàn)在業(yè)界比較成熟的服務(wù)框架有很多，比如：Hessian豪嗽、CXF谴蔑、Dubbo豌骏、Dubbox、Spring Cloud隐锭、gRPC窃躲、thrift等技術(shù)實現(xiàn)，都可以進行遠程調(diào)用钦睡，具體技術(shù)實現(xiàn)優(yōu)劣參考以下分析蒂窒，這也是具體在技術(shù)方案選擇過程中的重要依據(jù)。

3.1 服務(wù)框架對比

Dubbo?是阿里巴巴公司開源的一個Java高性能優(yōu)秀的服務(wù)框架荞怒，使得應(yīng)用可通過高性能的 RPC 實現(xiàn)服務(wù)的輸出和輸入功能洒琢，可以和 Spring框架無縫集成。不過挣输，略有遺憾的是纬凤，據(jù)說在淘寶內(nèi)部，dubbo由于跟淘寶另一個類似的框架HSF（非開源）有競爭關(guān)系撩嚼，導致dubbo團隊已經(jīng)解散停士，反到是當當網(wǎng)的擴展版本Dubbox仍在持續(xù)發(fā)展，墻內(nèi)開花墻外香完丽。其它的一些知名電商如當當恋技、國美維護了自己的分支或者在dubbo的基礎(chǔ)開發(fā)，但是官方的庫缺乏維護逻族，相關(guān)的依賴類比如Spring蜻底，Netty還是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些網(wǎng)友寫了升級Spring和Netty的插件。

Dubbox和Dubbo本質(zhì)上沒有區(qū)別聘鳞，名字的含義擴展了Dubbo而已薄辅，以下擴展出來的功能，也是選擇Dubbox很重要的考察點抠璃。

支持REST風格遠程調(diào)用（HTTP + JSON/XML)站楚；

支持基于Kryo和FST的Java高效序列化實現(xiàn)；

支持基于Jackson的JSON序列化搏嗡；

支持基于嵌入式Tomcat的HTTP remoting體系窿春；

升級Spring至3.x；

升級ZooKeeper客戶端采盒；

支持完全基于Java代碼的Dubbo配置旧乞；

Spring Cloud完全基于Spring Boot，是一個非常新的項目磅氨，2016年推出1.0的release版本尺栖，目前Github上更新速度很快. 雖然Spring Cloud時間最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系統(tǒng)解決方案。Spring Cloud 為開發(fā)者提供了在分布式系統(tǒng)（配置管理烦租，服務(wù)發(fā)現(xiàn)延赌，熔斷货徙，路由，微代理皮胡，控制總線，一次性token赏迟，全局瑣屡贺，leader選舉，分布式session锌杀，集群狀態(tài)）中快速構(gòu)建的工具甩栈，使用Spring Cloud的開發(fā)者可以快速的啟動服務(wù)或構(gòu)建應(yīng)用。它們將在任何分布式環(huán)境中工作糕再，包括開發(fā)人員自己的筆記本電腦量没，裸物理機的數(shù)據(jù)中心，和像Cloud Foundry云管理平臺突想。在未來引領(lǐng)這微服務(wù)架構(gòu)的發(fā)展殴蹄，提供業(yè)界標準的一套微服務(wù)架構(gòu)解決方案。

缺點是項目很年輕猾担，很少見到國內(nèi)業(yè)界有人在生產(chǎn)上成套使用袭灯，一般都是只有其中一兩個組件。相關(guān)的技術(shù)文檔大部分是英文的绑嘹，案例也相對較少稽荧，使用的話需要摸索的時間會長一些。

下圖是Spring Cloud和Dubbo對比：

Spring Cloud和Dubbo對比

Motan是新浪微博開源的一個Java 框架工腋。它誕生的比較晚姨丈，起于2013年，2016年5月開源擅腰。Motan 在微博平臺中已經(jīng)廣泛應(yīng)用蟋恬，每天為數(shù)百個服務(wù)完成近千億次的調(diào)用。與Dubbo相比惕鼓，Motan在功能方面并沒有那么全面筋现，也沒有實現(xiàn)特別多的擴展。用的人比較少箱歧，功能和穩(wěn)定性有待觀望矾飞。對跨語言調(diào)用支持較差，主要支持java呀邢。

Hessian采用的是?二進制RPC協(xié)議洒沦，適用于發(fā)送二進制數(shù)據(jù)。但本身也是一個Web Service框架對RPC調(diào)用提供支持价淌，功能簡單申眼，使用起來也方便瞒津。基于Http協(xié)議進行傳輸。通過Servlet提供遠程服務(wù)括尸。通過Hessain本身提供的API來發(fā)起請求巷蚪。響應(yīng)端根據(jù)Hessian提供的API來接受請求。

Hessian優(yōu)點：

整個jar很小濒翻，輕量屁柏；

配置簡單；

功能強大有送，拋開了soap(simple object access protocal 簡單對象訪問協(xié)議)淌喻、ejb，采用二進制來傳遞對象雀摘；

rpcx是Go語言生態(tài)圈的Dubbo裸删， 比Dubbo更輕量，實現(xiàn)了Dubbo的許多特性阵赠，借助于?Go語言優(yōu)秀的并發(fā)特性和簡潔語法涯塔，可以使用較少的代碼實現(xiàn)分布式的RPC服務(wù)。

gRPC是Google開發(fā)的高性能清蚀、通用的開源RPC框架伤塌，其由Google主要面向移動應(yīng)用開發(fā)并基于HTTP/2協(xié)議標準而設(shè)計，基于ProtoBuf(Protocol Buffers)序列化協(xié)議開發(fā)轧铁，且支持眾多開發(fā)語言每聪。本身它不是分布式的，所以要實現(xiàn)上面的框架的功能需要進一步的開發(fā)齿风。

thrift是Apache的一個跨語言的高性能的服務(wù)框架药薯，也得到了廣泛的應(yīng)用。

以上RPC框架功能比較：

功能HessianMontanrpcxgRPCThriftDubboDubboxSpring Cloud

開發(fā)語言跨語言JavaGo跨語言跨語言JavaJavaJava

分布式(服務(wù)治理)×√√××√√√

多序列化框架支持hessian√(支持Hessian2救斑、Json,可擴展)√× 只支持protobuf)×(thrift格式)√√√

多種注冊中心×√√××√√√

管理中心×√√××√√√

跨編程語言√×(支持php client和C server)×√√×××

支持REST××××××√√

關(guān)注度低中低中中中高中

上手難度低低中中中低低中

運維成本低中中中低中中中

開源機構(gòu)CauchoWeiboApacheGoogleApacheAlibabaDangdangApache

實際場景中的選擇

Spring Cloud：Spring全家桶童本，用起來很舒服，只有你想不到脸候，沒有它做不到穷娱。可惜因為發(fā)布的比較晚运沦，國內(nèi)還沒出現(xiàn)比較成功的案例泵额，大部分都是試水，不過畢竟有Spring作背書携添，還是比較看好嫁盲。

Dubbox：相對于Dubbo支持了REST，估計是很多公司選擇Dubbox的一個重要原因之一烈掠，但如果使用Dubbo的RPC調(diào)用方式羞秤，服務(wù)間仍然會存在API強依賴缸托，各有利弊，懂的取舍吧瘾蛋。

Thrift：如果你比較高冷俐镐，完全可以基于Thrift自己搞一套抽象的自定義框架吧。

Montan：可能因為出來的比較晚哺哼，目前除了新浪微博16年初發(fā)布的京革，

Hessian：如果是初創(chuàng)公司或系統(tǒng)數(shù)量還沒有超過5個，推薦選擇這個幸斥，畢竟在開發(fā)速度、運維成本咬扇、上手難度等都是比較輕量甲葬、簡單的，即使在以后遷移至SOA懈贺，也是無縫遷移经窖。

rpcx/gRPC：在服務(wù)沒有出現(xiàn)嚴重性能的問題下，或技術(shù)棧沒有變更的情況下梭灿，可能一直不會引入画侣，即使引入也只是小部分模塊優(yōu)化使用。

3.2 RPC vs REST(JAX-RS)

由于Dubbo是基礎(chǔ)框架堡妒，其實現(xiàn)的內(nèi)容對于我們實施微服務(wù)架構(gòu)是否合理配乱，也需要我們根據(jù)自身需求去考慮是否要修改，比如Dubbo的服務(wù)調(diào)用是通過RPC實現(xiàn)的皮迟，但是如果仔細拜讀過Martin Fowler的microservices一文搬泥，其定義的服務(wù)間通信是HTTP協(xié)議的REST API。那么這兩種有何區(qū)別呢伏尼？

服務(wù)提供方與調(diào)用方接口依賴方式太強

我們?yōu)槊總€微服務(wù)定義了各自的service抽象接口忿檩，并通過持續(xù)集成發(fā)布到私有倉庫中，調(diào)用方應(yīng)用對微服務(wù)提供的抽象接口存在強依賴關(guān)系爆阶，因此不論開發(fā)燥透、測試、集成環(huán)境都需要嚴格的管理版本依賴辨图，才不會出現(xiàn)服務(wù)方與調(diào)用方的不一致導致應(yīng)用無法編譯成功等一系列問題班套，以及這也會直接影響本地開發(fā)的環(huán)境要求，往往一個依賴很多服務(wù)的上層應(yīng)用故河，每天都要更新很多代碼并install之后才能進行后續(xù)的開發(fā)孽尽。若沒有嚴格的版本管理制度或開發(fā)一些自動化工具，這樣的依賴關(guān)系會成為開發(fā)團隊的一大噩夢忧勿。而REST接口相比RPC更為輕量化杉女，服務(wù)提供方和調(diào)用方的依賴只是依靠一紙契約瞻讽，不存在代碼級別的強依賴，當然REST接口也有痛點熏挎，因為接口定義過輕速勇，很容易導致定義文檔與實際實現(xiàn)不一致導致服務(wù)集成時的問題，但是該問題很好解決坎拐，只需要通過每個服務(wù)整合swagger烦磁，讓每個服務(wù)的代碼與文檔一體化，就能解決哼勇。所以在分布式環(huán)境下都伪，REST方式的服務(wù)依賴要比RPC方式的依賴更為靈活。

服務(wù)對平臺敏感积担，難以簡單復(fù)用

通常我們在提供對外服務(wù)時陨晶，都會?以REST的方式提供出去，這樣可以實現(xiàn)跨平臺的特點帝璧，任何一個語言的調(diào)用方都可以根據(jù)接口定義來實現(xiàn)先誉。那么在Dubbo中我們要提供REST接口時，不得不實現(xiàn)一層代理的烁，用來將RPC接口轉(zhuǎn)換成REST接口進行對外發(fā)布褐耳。若我們每個服務(wù)本身就以REST接口方式存在，當要對外提供服務(wù)時渴庆，主要在API網(wǎng)關(guān)中配置映射關(guān)系和權(quán)限控制就可實現(xiàn)服務(wù)的復(fù)用了铃芦。

相信這些痛點也是為什么當當網(wǎng)在dubbox（基于Dubbo的開源擴展）中增加了對REST支持的原因之一。

Dubbo實現(xiàn)了服務(wù)治理的基礎(chǔ)襟雷，但是要完成一個完備的微服務(wù)架構(gòu)杨帽，還需要在各環(huán)節(jié)去擴展和完善以保證集群的健康，以減輕開發(fā)嗤军、測試以及運維各個環(huán)節(jié)上增加出來的壓力注盈，這樣才能讓各環(huán)節(jié)人員真正的專注于業(yè)務(wù)邏輯。

而Spring Cloud依然發(fā)揚了Spring Source整合一切的作風叙赚，以標準化的姿態(tài)將一些微服務(wù)架構(gòu)的成熟產(chǎn)品與框架揉為一體老客，并繼承了Spring Boot簡單配置、快速開發(fā)震叮、輕松部署的特點胧砰，讓原本復(fù)雜的架構(gòu)工作變得相對容易上手一些。

所以苇瓣，如果選擇Dubbo請務(wù)必在各個環(huán)節(jié)做好整套解決方案的準備尉间，不然很可能隨著服務(wù)數(shù)量的增長，整個團隊都將疲于應(yīng)付各種架構(gòu)上不足引起的困難。而如果選擇Spring Cloud哲嘲，相對來說每個環(huán)節(jié)都已經(jīng)有了對應(yīng)的組件支持贪薪，可能有些也不一定能滿足你所有的需求，但是其活躍的社區(qū)與高速的迭代進度也會是你可以依靠的強大后盾眠副。

微服務(wù)結(jié)構(gòu)圖

4. Dubbox帶來什么

4.1 Dubbo服務(wù)治理

Dubbo服務(wù)治理

特性描述

透明遠程調(diào)用就像調(diào)用本地方法一樣調(diào)用遠程方法画切；只需簡單配置，沒有任何API侵入囱怕；

負載均衡機制Client端LB霍弹，可在內(nèi)網(wǎng)替代F5等硬件負載均衡器；

容錯重試機制服務(wù)Mock數(shù)據(jù)娃弓，重試次數(shù)典格、超時機制等；

自動注冊發(fā)現(xiàn)注冊中心基于接口名查詢服務(wù)提 供者的IP地址台丛，并且能夠平滑添加或刪除服務(wù)提供者耍缴；

性能日志監(jiān)控Monitor統(tǒng)計服務(wù)的調(diào)用次調(diào)和調(diào)用時間的監(jiān)控中心；

服務(wù)治理中心路由規(guī)則齐佳，動態(tài)配置，服務(wù)降級债沮，訪問控制炼吴，權(quán)重調(diào)整，負載均衡疫衩，等手動配置硅蹦。

自動治理中心無，比如：熔斷限流機制闷煤、自動權(quán)重調(diào)整等童芹；

4.2 Dubbox擴展特性

支持REST風格遠程調(diào)用（HTTP + JSON/XML)；

支持基于Kryo和FST的Java高效序列化實現(xiàn)鲤拿；

支持基于Jackson的JSON序列化假褪；

支持基于嵌入式Tomcat的HTTP remoting體系；

升級Spring至3.x近顷；

升級ZooKeeper客戶端生音；

支持完全基于Java代碼的Dubbo配置；