本篇內(nèi)容介紹了“Dubbo能帶來(lái)什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、微信小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了富陽(yáng)免費(fèi)建站歡迎大家使用！

1. 前言

隨著現(xiàn)在互聯(lián)網(wǎng)行業(yè)的發(fā)展，越來(lái)越多的框架、中間件、容器等開(kāi)源技術(shù)不斷地涌現(xiàn)，更好地來(lái)服務(wù)于業(yè)務(wù)，實(shí)現(xiàn)業(yè)務(wù)并解決問(wèn)題。然而面對(duì)眾多的技術(shù)選擇，我們要如何甄別出適合自己團(tuán)隊(duì)業(yè)務(wù)的技術(shù)呢？對(duì)于人來(lái)說(shuō)，鞋子過(guò)大，可能影響奔跑的速度，鞋子過(guò)小，可能影響身體的成長(zhǎng)。技術(shù)對(duì)于業(yè)務(wù)也是如此的關(guān)系。

所以，相對(duì)于技術(shù)的學(xué)習(xí)、搭建、使用、運(yùn)維等技能，我們 對(duì)技術(shù)的甄別選擇更是重中之重。那么本文要講的Dubbox框架，又是如何在眾多的服務(wù)框架中脫穎而出，被團(tuán)隊(duì)選中踐行服務(wù)之路？

2. 服務(wù)

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

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

1. 單一應(yīng)用架構(gòu)當(dāng)網(wǎng)站流量很小時(shí)，只需一個(gè)應(yīng)用，將所有功能都部署在一起，以減少部署節(jié)點(diǎn)和成本。 此時(shí)，用于簡(jiǎn)化增刪改查工作量的 數(shù)據(jù)訪問(wèn)框架(ORM)是關(guān)鍵。

2. 垂直應(yīng)用架構(gòu)當(dāng)訪問(wèn)量逐漸增大，單一應(yīng)用增加機(jī)器帶來(lái)的加速度越來(lái)越小，將應(yīng)用拆成互不相干的幾個(gè)應(yīng)用，以提升效率。 此時(shí)，用于加速前端頁(yè)面開(kāi)發(fā)的 Web框架(MVC)是關(guān)鍵。

3. 分布式服務(wù)架構(gòu)當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求。 此時(shí)，用于提高業(yè)務(wù)復(fù)用及整合的 分布式服務(wù)框架(RPC)是關(guān)鍵。

4. 流動(dòng)計(jì)算架構(gòu)當(dāng)服務(wù)越來(lái)越多，容量的評(píng)估，小服務(wù)資源的浪費(fèi)等問(wèn)題逐漸顯現(xiàn)，此時(shí)需增加一個(gè)調(diào)度中心基于訪問(wèn)壓力實(shí)時(shí)管理集群容量，提高集群利用率。 此時(shí)，用于提高機(jī)器利用率的 資源調(diào)度和治理中心(SOA)是關(guān)鍵。

平臺(tái)隨著業(yè)務(wù)的發(fā)展 從 All in One 環(huán)境就可以滿足業(yè)務(wù)需求（以Java來(lái)說(shuō)，可能只是一兩個(gè)war包就解決了）；發(fā)展到需 要拆分多個(gè)應(yīng)用，并且采用MVC的方式分離前后端，加快開(kāi)發(fā)效率；在發(fā)展到服務(wù)越來(lái)越多，不得不將 一些核心或共用的服務(wù)拆分出來(lái)，提供實(shí)時(shí)流動(dòng)監(jiān)控計(jì)算等，其實(shí)發(fā)展到此階段，如果服務(wù)拆分的足夠精細(xì)，并且獨(dú)立運(yùn)行，這個(gè)時(shí)候至少可以 理解為SOA（Service Oriented Architecture面向服務(wù)的體系結(jié)構(gòu)）架構(gòu)了。

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

當(dāng)迎來(lái)服務(wù)SOA時(shí)代，我們面臨要解決的問(wèn)題會(huì)很多，比如：系統(tǒng)的復(fù)雜度上升、服務(wù)依賴關(guān)系、服務(wù)性能監(jiān)控、全鏈路日志、容災(zāi)、斷路器、限流等。那么面對(duì)這些問(wèn)題為什么還要做分布式服務(wù)呢？因?yàn)樵谖磥?lái)只有砥礪前行，才能走的更高更遠(yuǎn)。不過(guò)看到這些問(wèn)題不要?dú)怵H，先不管這些問(wèn)題，讓我們一步步來(lái)梳理下現(xiàn)存有什么問(wèn)題，我們要完成什么目標(biāo)，問(wèn)題自然會(huì)迎刃而解。

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

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

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

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

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

5. 服務(wù)集群負(fù)載配置：Nginx配置，存在單點(diǎn)問(wèn)題；

在去選擇技術(shù)框架時(shí)，技術(shù)框架最基本要解決上面現(xiàn)存問(wèn)題，同時(shí)我們也要確認(rèn)出我們的期望，要達(dá)到的目標(biāo)是什么：

1. 支持當(dāng)前業(yè)務(wù)需求，這是最最基本的條件；

2. 服務(wù)避免單點(diǎn)問(wèn)題，去中心化；

3. 服務(wù)高可用、高并發(fā)，解耦服務(wù)依賴；

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

5. 服務(wù)依賴關(guān)系自維護(hù)，可視化；

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

7. 服務(wù)需自帶注冊(cè)、發(fā)現(xiàn)、健康檢查、負(fù)載均衡等特性；

8. 開(kāi)發(fā)人員關(guān)注度高，上手快，簡(jiǎn)單輕量，低侵入；

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

2.3 服務(wù)未來(lái)的趨勢(shì)

一談到服務(wù)，可能大家很多聽(tīng)說(shuō)過(guò)SOA、MSA等服務(wù)的概念名詞，近幾年MSA炒的比較火，其實(shí)每一個(gè)概念的背后都在解決不同的問(wèn)題。此類(lèi)名詞的最大特點(diǎn)就是 一解釋就懂，一問(wèn)就不知，一討論就打架。

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

1. 微服務(wù)相比于SOA更加精細(xì)，微服務(wù)更多的以獨(dú)立的進(jìn)程的方式存在，互相之間并無(wú)影響；

2. 微服務(wù)提供的接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調(diào)用，無(wú)關(guān)語(yǔ)言、平臺(tái)限制；

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

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

微服務(wù)并不是一種新思想的方法。它更像是一種思想的精煉，一種SOA的精細(xì)化演進(jìn)，并且更好地利用了先進(jìn)的技術(shù)以解決問(wèn)題，例如容器與自動(dòng)化等。所以對(duì)于我們 去選擇服務(wù)技術(shù)框架時(shí)，并不是非黑即白，而是針對(duì)SOA、MSA兩種架構(gòu)設(shè)計(jì)同時(shí)要考慮到兼容性，對(duì)于現(xiàn)有平臺(tái)情況架構(gòu)設(shè)計(jì)，退則守SOA，進(jìn)則攻MSA，階段性選擇適合的。

3. 框架

現(xiàn)在業(yè)界比較成熟的服務(wù)框架有很多，比如：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技術(shù)實(shí)現(xiàn)，都可以進(jìn)行遠(yuǎn)程調(diào)用，具體技術(shù)實(shí)現(xiàn)優(yōu)劣參考以下分析，這也是具體在技術(shù)方案選擇過(guò)程中的重要依據(jù)。

3.1 服務(wù)框架對(duì)比

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

Dubbox和Dubbo本質(zhì)上沒(méi)有區(qū)別，名字的含義擴(kuò)展了Dubbo而已，以下擴(kuò)展出來(lái)的功能，也是選擇Dubbox很重要的考察點(diǎn)。

1. 支持REST風(fēng)格遠(yuǎn)程調(diào)用（HTTP + JSON/XML)；

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

3. 支持基于Jackson的JSON序列化；

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

5. 升級(jí)Spring至3.x；

6. 升級(jí)ZooKeeper客戶端；

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

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

缺點(diǎn)是項(xiàng)目很年輕，很少見(jiàn)到國(guó)內(nèi)業(yè)界有人在生產(chǎn)上成套使用，一般都是只有其中一兩個(gè)組件。相關(guān)的技術(shù)文檔大部分是英文的，案例也相對(duì)較少，使用的話需要摸索的時(shí)間會(huì)長(zhǎng)一些。

下圖是Spring Cloud和Dubbo對(duì)比：

Motan是新浪微博開(kāi)源的一個(gè)Java 框架。它誕生的比較晚，起于2013年，2016年5月開(kāi)源。Motan 在微博平臺(tái)中已經(jīng)廣泛應(yīng)用，每天為數(shù)百個(gè)服務(wù)完成近千億次的調(diào)用。與Dubbo相比，Motan在功能方面并沒(méi)有那么全面，也沒(méi)有實(shí)現(xiàn)特別多的擴(kuò)展。用的人比較少，功能和穩(wěn)定性有待觀望。對(duì)跨語(yǔ)言調(diào)用支持較差，主要支持java。

Hessian采用的是 二進(jìn)制RPC協(xié)議，適用于發(fā)送二進(jìn)制數(shù)據(jù)。但本身也是一個(gè)Web Service框架對(duì)RPC調(diào)用提供支持，功能簡(jiǎn)單，使用起來(lái)也方便。基于Http協(xié)議進(jìn)行傳輸。通過(guò)Servlet提供遠(yuǎn)程服務(wù)。通過(guò)Hessain本身提供的API來(lái)發(fā)起請(qǐng)求。響應(yīng)端根據(jù)Hessian提供的API來(lái)接受請(qǐng)求。

Hessian優(yōu)點(diǎn)：

1. 整個(gè)jar很小，輕量；

2. 配置簡(jiǎn)單；

3. 功能強(qiáng)大，拋開(kāi)了soap(simple object access protocal 簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議)、ejb，采用二進(jìn)制來(lái)傳遞對(duì)象；

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

gRPC是Google開(kāi)發(fā)的高性能、通用的開(kāi)源RPC框架，其由Google主要面向移動(dòng)應(yīng)用開(kāi)發(fā)并基于HTTP/2協(xié)議標(biāo)準(zhǔn)而設(shè)計(jì)，基于ProtoBuf(Protocol Buffers)序列化協(xié)議開(kāi)發(fā)，且支持眾多開(kāi)發(fā)語(yǔ)言。本身它不是分布式的，所以要實(shí)現(xiàn)上面的框架的功能需要進(jìn)一步的開(kāi)發(fā)。

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

以上RPC框架功能比較：

實(shí)際場(chǎng)景中的選擇

1. Spring Cloud：Spring全家桶，用起來(lái)很舒服，只有你想不到，沒(méi)有它做不到?？上б?yàn)榘l(fā)布的比較晚，國(guó)內(nèi)還沒(méi)出現(xiàn)比較成功的案例，大部分都是試水，不過(guò)畢竟有Spring作背書(shū)，還是比較看好。

2. Dubbox：相對(duì)于Dubbo支持了REST，估計(jì)是很多公司選擇Dubbox的一個(gè)重要原因之一，但如果使用Dubbo的RPC調(diào)用方式，服務(wù)間仍然會(huì)存在API強(qiáng)依賴，各有利弊，懂的取舍吧。

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

4. Montan：可能因?yàn)槌鰜?lái)的比較晚，目前除了新浪微博16年初發(fā)布的，

5. Hessian：如果是初創(chuàng)公司或系統(tǒng)數(shù)量還沒(méi)有超過(guò)5個(gè)，推薦選擇這個(gè)，畢竟在開(kāi)發(fā)速度、運(yùn)維成本、上手難度等都是比較輕量、簡(jiǎn)單的，即使在以后遷移至SOA，也是無(wú)縫遷移。

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

3.2 RPC vs REST(JAX-RS)

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

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

   我們?yōu)槊總€(gè)微服務(wù)定義了各自的service抽象接口，并通過(guò)持續(xù)集成發(fā)布到私有倉(cāng)庫(kù)中，調(diào)用方應(yīng)用對(duì)微服務(wù)提供的抽象接口存在強(qiáng)依賴關(guān)系，因此不論開(kāi)發(fā)、測(cè)試、集成環(huán)境都需要嚴(yán)格的管理版本依賴，才不會(huì)出現(xiàn)服務(wù)方與調(diào)用方的不一致導(dǎo)致應(yīng)用無(wú)法編譯成功等一系列問(wèn)題，以及這也會(huì)直接影響本地開(kāi)發(fā)的環(huán)境要求，往往一個(gè)依賴很多服務(wù)的上層應(yīng)用，每天都要更新很多代碼并install之后才能進(jìn)行后續(xù)的開(kāi)發(fā)。若沒(méi)有嚴(yán)格的版本管理制度或開(kāi)發(fā)一些自動(dòng)化工具，這樣的依賴關(guān)系會(huì)成為開(kāi)發(fā)團(tuán)隊(duì)的一大噩夢(mèng)。而REST接口相比RPC更為輕量化，服務(wù)提供方和調(diào)用方的依賴只是依靠一紙契約，不存在代碼級(jí)別的強(qiáng)依賴，當(dāng)然REST接口也有痛點(diǎn)，因?yàn)榻涌诙x過(guò)輕，很容易導(dǎo)致定義文檔與實(shí)際實(shí)現(xiàn)不一致導(dǎo)致服務(wù)集成時(shí)的問(wèn)題，但是該問(wèn)題很好解決，只需要通過(guò)每個(gè)服務(wù)整合swagger，讓每個(gè)服務(wù)的代碼與文檔一體化，就能解決。所以在分布式環(huán)境下，REST方式的服務(wù)依賴要比RPC方式的依賴更為靈活。

2. 服務(wù)對(duì)平臺(tái)敏感，難以簡(jiǎn)單復(fù)用

   通常我們?cè)谔峁?duì)外服務(wù)時(shí)，都會(huì) 以REST的方式提供出去，這樣可以實(shí)現(xiàn)跨平臺(tái)的特點(diǎn)，任何一個(gè)語(yǔ)言的調(diào)用方都可以根據(jù)接口定義來(lái)實(shí)現(xiàn)。那么在Dubbo中我們要提供REST接口時(shí)，不得不實(shí)現(xiàn)一層代理，用來(lái)將RPC接口轉(zhuǎn)換成REST接口進(jìn)行對(duì)外發(fā)布。若我們每個(gè)服務(wù)本身就以REST接口方式存在，當(dāng)要對(duì)外提供服務(wù)時(shí)，主要在API網(wǎng)關(guān)中配置映射關(guān)系和權(quán)限控制就可實(shí)現(xiàn)服務(wù)的復(fù)用了。

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

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

而Spring Cloud依然發(fā)揚(yáng)了Spring Source整合一切的作風(fēng)，以標(biāo)準(zhǔn)化的姿態(tài)將一些微服務(wù)架構(gòu)的成熟產(chǎn)品與框架揉為一體，并繼承了Spring Boot簡(jiǎn)單配置、快速開(kāi)發(fā)、輕松部署的特點(diǎn)，讓原本復(fù)雜的架構(gòu)工作變得相對(duì)容易上手一些。所以，如果選擇Dubbo請(qǐng)務(wù)必在各個(gè)環(huán)節(jié)做好整套解決方案的準(zhǔn)備，不然很可能隨著服務(wù)數(shù)量的增長(zhǎng)，整個(gè)團(tuán)隊(duì)都將疲于應(yīng)付各種架構(gòu)上不足引起的困難。而如果選擇Spring Cloud，相對(duì)來(lái)說(shuō)每個(gè)環(huán)節(jié)都已經(jīng)有了對(duì)應(yīng)的組件支持，可能有些也不一定能滿足你所有的需求，但是其活躍的社區(qū)與高速的迭代進(jìn)度也會(huì)是你可以依靠的強(qiáng)大后盾。

4. Dubbox帶來(lái)什么

4.1 Dubbo服務(wù)治理

4.2 Dubbox擴(kuò)展特性

1. 支持REST風(fēng)格遠(yuǎn)程調(diào)用（HTTP + JSON/XML)；

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

3. 支持基于Jackson的JSON序列化；

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

5. 升級(jí)Spring至3.x；

6. 升級(jí)ZooKeeper客戶端；

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

“Dubbo能帶來(lái)什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！