整合營銷服務(wù)商

          電腦端+手機端+微信端=數(shù)據(jù)同步管理

          免費咨詢熱線:

          終極對決!Dubbo 和 Spring Cloud

          終極對決!Dubbo 和 Spring Cloud 微服務(wù)架構(gòu)到底孰優(yōu)孰劣?

          服務(wù)架構(gòu)是互聯(lián)網(wǎng)很熱門的話題,是互聯(lián)網(wǎng)技術(shù)發(fā)展的必然結(jié)果。它提倡將單一應(yīng)用程序劃分成一組小的服務(wù),服務(wù)之間互相協(xié)調(diào)、互相配合,為用戶提供最終價值。雖然微服務(wù)架構(gòu)沒有公認(rèn)的技術(shù)標(biāo)準(zhǔn)和規(guī)范或者草案,但業(yè)界已經(jīng)有一些很有影響力的開源微服務(wù)架構(gòu)框架提供了微服務(wù)的關(guān)鍵思路,例如Dubbo和Spring Cloud。各大互聯(lián)網(wǎng)公司也有自研的微服務(wù)框架,但其模式都于這二者相差不大。

          微服務(wù)主要的優(yōu)勢如下:

          1、降低復(fù)雜度

          將原來偶合在一起的復(fù)雜業(yè)務(wù)拆分為單個服務(wù),規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能,并通過定義良好的接口清晰表述服務(wù)邊界。每個服務(wù)開發(fā)者只專注服務(wù)本身,通過使用緩存、DAL等各種技術(shù)手段來提升系統(tǒng)的性能,而對于消費方來說完全透明。

          2、可獨立部署

          由于微服務(wù)具備獨立的運行進(jìn)程,所以每個微服務(wù)可以獨立部署。當(dāng)業(yè)務(wù)迭代時只需要發(fā)布相關(guān)服務(wù)的迭代即可,降低了測試的工作量同時也降低了服務(wù)發(fā)布的風(fēng)險。

          3、容錯

          在微服務(wù)架構(gòu)下,當(dāng)某一組件發(fā)生故障時,故障會被隔離在單個服務(wù)中。 通過限流、熔斷等方式降低錯誤導(dǎo)致的危害,保障核心業(yè)務(wù)正常運行。

          4、擴展

          單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展,就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴展需求上存在差異時,微服務(wù)架構(gòu)便體現(xiàn)出其靈活性,因為每個服務(wù)可以根據(jù)實際需求獨立進(jìn)行擴展。

          本文主要圍繞微服務(wù)的技術(shù)選型、通訊協(xié)議、服務(wù)依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發(fā)框架。架構(gòu)師可以根據(jù)公司的技術(shù)實力并結(jié)合項目的特點來選擇某個合適的微服務(wù)架構(gòu)平臺,以此穩(wěn)妥地實施項目的微服務(wù)化改造或開發(fā)進(jìn)程。

          一、核心部件

          微服務(wù)的核心要素在于服務(wù)的發(fā)現(xiàn)、注冊、路由、熔斷、降級、分布式配置,基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。

          1、總體架構(gòu)

          • Dubbo 核心部件(如下圖):
          • Provider: 暴露服務(wù)的提供方,可以通過jar或者容器的方式啟動服務(wù)
          • Consumer:調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。
          • Registry: 服務(wù)注冊中心和發(fā)現(xiàn)中心。
          • Monitor: 統(tǒng)計服務(wù)和調(diào)用次數(shù),調(diào)用時間監(jiān)控中心。(dubbo的控制臺頁面中可以顯示,目前只有一個簡單版本)
          • Container:服務(wù)運行的容器。



          ▲Dubbo 總體架構(gòu)

          Spring Cloud總體架構(gòu)如下圖

          • Service Provider: 暴露服務(wù)的提供方。
          • Service Consumer:調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。
          • EureKa Server: 服務(wù)注冊中心和服務(wù)發(fā)現(xiàn)中心。



          ▲Spring Cloud總體架構(gòu)

          點評:從整體架構(gòu)上來看,二者模式接近,都需要需要服務(wù)提供方,注冊中心,服務(wù)消費方。

          2、微服務(wù)架構(gòu)核心要素


          Dubbo只是實現(xiàn)了服務(wù)治理,而Spring Cloud子項目分別覆蓋了微服務(wù)架構(gòu)下的眾多部件,而服務(wù)治理只是其中的一個方面。Dubbo提供了各種Filter,對于上述中“無”的要素,可以通過擴展Filter來完善。

          例如

          1.分布式配置:可以使用淘寶的diamond、百度的disconf來實現(xiàn)分布式配置管理

          2.服務(wù)跟蹤:可以使用京東開源的Hydra,或者擴展Filter用Zippin來做服務(wù)跟蹤

          3.批量任務(wù):可以使用當(dāng)當(dāng)開源的Elastic-Job、tbschedule

          點評:從核心要素來看,Spring Cloud 更勝一籌,在開發(fā)過程中只要整合Spring Cloud的子項目就可以順利的完成各種組件的融合,而Dubbo缺需要通過實現(xiàn)各種Filter來做定制,開發(fā)成本以及技術(shù)難度略高。

          二、通訊協(xié)議

          基于通訊協(xié)議層面對2種框架支持的協(xié)議類型以及運行效率方面進(jìn)行比較;

          (一)、支持協(xié)議

          1、Dubbo:dubbo使用RPC通訊協(xié)議,提供序列化方式如下:

          dubbo:Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊,適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用,以及服務(wù)消費者機器數(shù)遠(yuǎn)大于服務(wù)提供者機器數(shù)的情況

          rmi:RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實現(xiàn),采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式

          Hessian:Hessian協(xié)議用于集成Hessian的服務(wù),Hessian底層采用Http通訊,采用Servlet暴露服務(wù),Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實現(xiàn)

          http:采用Spring的HttpInvoker實現(xiàn)

          Webservice:基于CXF的frontend-simple和transports-http實現(xiàn)

          2、Spring Cloud:Spring Cloud 使用HTTP協(xié)議的REST API

          (二)、性能比較

          使用一個Pojo對象包含10個屬性,請求10萬次,Dubbo和Spring Cloud在不同的線程數(shù)量下,每次請求耗時(ms)如下:


          說明:客戶端和服務(wù)端配置均采用阿里云的ECS服務(wù)器,4核8G配置,dubbo采用默認(rèn)的dubbo協(xié)議

          點評:dubbo支持各種通信協(xié)議,而且消費方和服務(wù)方使用長鏈接方式交互,通信速度上略勝Spring Cloud,如果對于系統(tǒng)的響應(yīng)時間有嚴(yán)格要求,長鏈接更合適。

          三、服務(wù)依賴方式

          Dubbo:服務(wù)提供方與消費方通過接口的方式依賴,服務(wù)調(diào)用設(shè)計如下:

          • interface層:服務(wù)接口層,定義了服務(wù)對外提供的所有接口
          • Molel層:服務(wù)的DTO對象層,
          • business層:業(yè)務(wù)實現(xiàn)層,實現(xiàn)interface接口并且和DB交互

          因此需要為每個微服務(wù)定義了各自的interface接口,并通過持續(xù)集成發(fā)布到私有倉庫中,調(diào)用方應(yīng)用對微服務(wù)提供的抽象接口存在強依賴關(guān)系,開發(fā)、測試、集成環(huán)境都需要嚴(yán)格的管理版本依賴。

          通過maven的install & deploy命令把interface和Model層發(fā)布到倉庫中,服務(wù)調(diào)用方只需要依賴interface和model層即可。在開發(fā)調(diào)試階段只發(fā)布Snapshot版本。等到服務(wù)調(diào)試完成再發(fā)布Release版本,通過版本號來區(qū)分每次迭代的版本。通過xml配置方式即可方面接入dubbo,對程序無入侵。



          ▲Dubbo接口依賴方式

          Spring Cloud:服務(wù)提供方和服務(wù)消費方通過json方式交互,因此只需要定義好相關(guān)json字段即可,消費方和提供方無接口依賴。通過注解方式來實現(xiàn)服務(wù)配置,對于程序有一定入侵。


          點評:Dubbo服務(wù)依賴略重,需要有完善的版本管理機制,但是程序入侵少。而Spring Cloud通過Json交互,省略了版本管理的問題,但是具體字段含義需要統(tǒng)一管理,自身Rest API方式交互,為跨平臺調(diào)用奠定了基礎(chǔ)。

          四、組件運行流程

          下圖中的每個組件都是需要部署在單獨的服務(wù)器上,gateway用來接受前端請求、聚合服務(wù),并批量調(diào)用后臺原子服務(wù)。每個service層和單獨的DB交互。



          ▲Dubbo組件運行流程

          • gateWay:前置網(wǎng)關(guān),具體業(yè)務(wù)操作,gateWay通過dubbo提供的負(fù)載均衡機制自動完成
          • Service:原子服務(wù),只提供該業(yè)務(wù)相關(guān)的原子服務(wù)
          • Zookeeper:原子服務(wù)注冊到zk上



          ▲Spring Cloud 組件運行

          Spring Cloud

          • 所有請求都統(tǒng)一通過 API 網(wǎng)關(guān)(Zuul)來訪問內(nèi)部服務(wù)。
          • 網(wǎng)關(guān)接收到請求后,從注冊中心(Eureka)獲取可用服務(wù)。
          • 由 Ribbon 進(jìn)行均衡負(fù)載后,分發(fā)到后端的具體實例。
          • 微服務(wù)之間通過 Feign 進(jìn)行通信處理業(yè)務(wù)。

          點評:業(yè)務(wù)部署方式相同,都需要前置一個網(wǎng)關(guān)來隔絕外部直接調(diào)用原子服務(wù)的風(fēng)險。Dubbo需要自己開發(fā)一套API 網(wǎng)關(guān),而Spring Cloud則可以通過Zuul配置即可完成網(wǎng)關(guān)定制。使用方式上Spring Cloud略勝一籌。

          五、微服務(wù)架構(gòu)組成以及注意事項

          到底使用是dubbo還是Spring Cloud其實并不重要,重點在于如何合理的利用微服務(wù)。下面是一張互聯(lián)網(wǎng)通用的架構(gòu)圖,其中每個環(huán)節(jié)都是微服務(wù)的核心部分。


          (一)、架構(gòu)分解

          • 網(wǎng)關(guān)集群:數(shù)據(jù)的聚合、實現(xiàn)對接入客戶端的身份認(rèn)證、防報文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制等
          • 業(yè)務(wù)集群:一般情況下移動端訪問和瀏覽器訪問的網(wǎng)關(guān)需要隔離,防止業(yè)務(wù)耦合
          • Local Cache:由于客戶端訪問業(yè)務(wù)可能需要調(diào)用多個服務(wù)聚合,所以本地緩存有效的降低了服務(wù)調(diào)用的頻次,同時也提示了訪問速度。本地緩存一般使用自動過期方式,業(yè)務(wù)場景中允許有一定的數(shù)據(jù)延時。
          • 服務(wù)層:原子服務(wù)層,實現(xiàn)基礎(chǔ)的增刪改查功能,如果需要依賴其他服務(wù)需要在Service層主動調(diào)用
          • Remote Cache:訪問DB前置一層分布式緩存,減少DB交互次數(shù),提升系統(tǒng)的TPS
          • DAL:數(shù)據(jù)訪問層,如果單表數(shù)據(jù)量過大則需要通過DAL層做數(shù)據(jù)的分庫分表處理。
          • MQ:消息隊列用來解耦服務(wù)之間的依賴,異步調(diào)用可以通過MQ的方式來執(zhí)行
          • 數(shù)據(jù)庫主從:服務(wù)化過程中畢竟的階段,用來提升系統(tǒng)的TPS

          (二)注意事項

          • 服務(wù)啟動方式建議使用jar方式啟動,啟動速度快,更容易監(jiān)控
          • 緩存、緩存、緩存,系統(tǒng)中能使用緩存的地方盡量使用緩存,通過合理的使用緩存可以有效的提高系統(tǒng)的TPS
          • 服務(wù)拆分要合理,盡量避免因服務(wù)拆分而導(dǎo)致的服務(wù)循環(huán)依賴
          • 合理的設(shè)置線程池,避免設(shè)置過大或者過小導(dǎo)致系統(tǒng)異常

          六、總結(jié)

          Dubbo出生于阿里系,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司;只需要通過spring配置的方式即可完成服務(wù)化,對于應(yīng)用無入侵。設(shè)計的目的還是服務(wù)于自身的業(yè)務(wù)為主。雖然阿里內(nèi)部原因dubbo曾經(jīng)一度暫停維護(hù)版本,但是框架本身的成熟度以及文檔的完善程度,完全能滿足各大互聯(lián)網(wǎng)公司的業(yè)務(wù)需求。如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成,這樣無形中增加了使用 Dubbo 的難度。

          Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品, 專注于企業(yè)級開源框架的研發(fā)。 Spring Cloud 自從發(fā)展到現(xiàn)在,仍然在不斷的高速發(fā)展,幾乎考慮了服務(wù)治理的方方面面,開發(fā)起來非常的便利和簡單。

          Dubbo于2017年開始又重啟維護(hù),發(fā)布了更新后的2.5.6版本,而Spring Cloud更新的非???,目前已經(jīng)更新到Finchley.M2。因此,企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構(gòu)來解決業(yè)務(wù)問題,不管是Dubbo還是Spring Cloud都是實現(xiàn)微服務(wù)有效的工具。


          者:moon

          原文:https://mp.weixin.qq.com/s/-kVf5qWqcw-4AJF7LL3uWw

          前言

          雖然金三銀四過了,但是金九銀十馬上就要到了,還不快快準(zhǔn)備起來?

          今天就開啟《面試八股文》系列的第一版-RPC王者Dubbo,moon 在后續(xù)的《面試八股文》系列還將繼續(xù)推出mysql,spring,并發(fā),redis,kafka,zookeeper等一系列文章。

          當(dāng)然大家有什么好的建議也可以通過公眾號或者個人微信和我交流。

          每天一個知識點

          • 不要背,要理解,大家不要夸我內(nèi)卷了

          目錄

          • 1.Dubbo是什么?RPC又是什么?
          • 2. Dubbo能做什么?
          • 3.能說下Dubbo的總體的調(diào)用過程嗎?
          • 4.說說Dubbo 支持哪些協(xié)議,每種協(xié)議的應(yīng)用場景和優(yōu)缺點
          • 5.Dubbo中都用到哪些設(shè)計模式?
          • 6.如果Dubbo中provider提供的服務(wù)由多個版本怎么辦?
          • 7.服務(wù)暴露的流程是怎么樣的?
          • 8.服務(wù)引用的流程是怎么樣的?
          • 9.Dubbo的注冊中心有哪些?
          • 10.聊聊Dubbo SPI機制?
          • 11.Dubbo的SPi和JAVA的SPI有什么區(qū)別?
          • 12.有哪些負(fù)載均衡策略?
          • 13.集群容錯方式有哪些?
          • 14.說說Dubbo的分層?
          • 15.服務(wù)提供者能實現(xiàn)失效踢出是什么原理?
          • 16.為什么要通過代理對象通信??
          • 17.怎么設(shè)計一個RPC框架?



          1.Dubbo是什么?RPC又是什么?

          Dubbo是一個分布式服務(wù)框架,致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案,以及SOA服務(wù)治理方案。

          RPC(Remote Procedure Call)—遠(yuǎn)程過程調(diào)用,它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計算機程序上請求服務(wù),而不需要了解底>層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在,如TCP或UDP,為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)>通信模型中,RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。RPC采用客戶機/服務(wù)器模式。請求程序就是一個客戶機,而服務(wù)提供程序就是一個服務(wù)器。首先,客戶機調(diào)用進(jìn)程發(fā)>送一個有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程,然后等待應(yīng)答信息。在服務(wù)器端,進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息到達(dá)為>止。當(dāng)一個調(diào)用信息到達(dá),服務(wù)器獲得進(jìn)程參數(shù),計算結(jié)果,發(fā)送答復(fù)信息,然后等待下一個調(diào)用信息,最后,客戶>端調(diào)用進(jìn)程接收答復(fù)信息,獲得進(jìn)程結(jié)果,然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。有多種 RPC模式和執(zhí)行。

          我們用一種通俗易懂的語言解釋它,遠(yuǎn)程調(diào)用就是本地機器調(diào)用遠(yuǎn)程機器的一個方法,遠(yuǎn)程機器返回結(jié)果的過程。

          為什么要這么做?

          主要原因是由于單臺服務(wù)的性能已經(jīng)無法滿足我們了,在這個流量劇增的時代,只有多臺服務(wù)器才能支撐起來現(xiàn)有的用戶體系,

          而在這種體系下,服務(wù)越來越多,逐漸演化出了現(xiàn)在這種微服務(wù)化的RPC框架。


          2. Dubbo能做什么?

          Dubbo的核心功能主要包含:


          • 遠(yuǎn)程通訊:dubbo-remoting模塊, 提供對多種基于長連接的NIO框架抽象封裝,包括多種線程模型,序列化,以及“請求-響應(yīng)”模式的信息交換方式。

          • 集群容錯: 提供基于接口方法的透明遠(yuǎn)程過程調(diào)用,包括多協(xié)議支持,以及軟負(fù)載均衡,失敗容錯,地址路由,動態(tài)配置等集群支持。

          • 自動發(fā)現(xiàn): 基于注冊中心目錄服務(wù),使服務(wù)消費方能動態(tài)的查找服務(wù)提供方,使地址透明,使服務(wù)提供方可以平滑增加或減少機器。

          3.能說下Dubbo的總體的調(diào)用過程嗎?

          調(diào)用過程圖:

          • 1.Proxy持有一個Invoker對象,使用Invoker調(diào)用
          • 2.之后通過Cluster進(jìn)行負(fù)載容錯,失敗重試
          • 3.調(diào)用Directory獲取遠(yuǎn)程服務(wù)的Invoker列表
          • 4.負(fù)載均衡
            • 用戶配置了路由規(guī)則,則根據(jù)路由規(guī)則過濾獲取到的Invoker列表
            • 用戶沒有配置路由規(guī)則或配置路由后還有很多節(jié)點,則使用LoadBalance方法做負(fù)載均衡,選用一個可以調(diào)用的Invoker
          • 5.經(jīng)過一個一個過濾器鏈,通常是處理上下文、限流、計數(shù)等。
          • 6.會使用Client做數(shù)據(jù)傳輸
          • 7.私有化協(xié)議的構(gòu)造(Codec)
          • 8.進(jìn)行序列化
          • 9.服務(wù)端收到這個Request請求,將其分配到ThreadPool中進(jìn)行處理
          • 10.Server來處理這些Request
          • 11.根據(jù)請求查找對應(yīng)的Exporter
          • 12.之后經(jīng)過一個服務(wù)提供者端的過濾器鏈
          • 13.然后找到接口實現(xiàn)并真正的調(diào)用,將請求結(jié)果返回

          4.說說Dubbo 支持哪些協(xié)議,每種協(xié)議的應(yīng)用場景和優(yōu)缺點

          • 1.dubbo 單一長連接和 NIO 異步通訊,適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用,以及消費者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP,異步,Hessian 序列化
          • 2.rmi 采用 JDK 標(biāo)準(zhǔn)的 rmi 協(xié)議實現(xiàn),傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serializable 接口,使用 java 標(biāo)準(zhǔn)序列化機制,使用阻塞式短連接,傳輸數(shù)據(jù)包大小混合,消費者和提供者個數(shù)差不多,可傳文件,傳輸協(xié)議 TCP。多個短連接,TCP 協(xié)議傳輸,同步傳輸,適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互 操作。在依賴低版本的 Common-Collections 包,java 序列化存在安全漏洞
          • 3.webservice 基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議,集成 CXF 實現(xiàn),提供和原生 WebService 的互操作。多個短連接,基于 HTTP 傳輸,同步傳輸,適用系統(tǒng)集成和跨語言調(diào)用;
          • 4.http 基于 Http 表單提交的遠(yuǎn)程調(diào)用協(xié)議,使用 Spring 的 HttpInvoke 實 現(xiàn)。多個短連接,傳輸協(xié)議 HTTP,傳入?yún)?shù)大小混合,提供者個數(shù)多于消 費者,需要給應(yīng)用程序和瀏覽器 JS 調(diào)用
          • 5.hessian 集成 Hessian 服務(wù),基于 HTTP 通訊,采用 Servlet 暴露服務(wù),Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時默認(rèn)實現(xiàn),提供與 Hession 服務(wù)互操作。多個短連接,同步 HTTP 傳輸,Hessian 序列化,傳入?yún)?shù)較大,提供者大于消費者,提供者壓力較大,可傳文件;
          • 6.memcache 基于 memcached 實現(xiàn)的 RPC 協(xié)議
          • 7.redis 基于 redis 實現(xiàn)的 RPC 協(xié)議

          5.Dubbo中都用到哪些設(shè)計模式?

          責(zé)任鏈模式:
          責(zé)任鏈模式在Dubbo中發(fā)揮的作用舉足輕重,就像是Dubbo框架的骨架。Dubbo的調(diào)用鏈組織是用責(zé)任鏈模式串連起來的。責(zé)任鏈中的每個節(jié)點實現(xiàn)Filter接口,然后由ProtocolFilterWrapper,將所有Filter串連起來。Dubbo的許多功能都是通過Filter擴展實現(xiàn)的,比如監(jiān)控、日志、緩存、安全、telnet以及RPC本身都是。

          觀察者模式:
          Dubbo中使用觀察者模式最典型的例子是RegistryService。消費者在初始化的時候回調(diào)用subscribe方法,注冊一個觀察者,如果觀察者引用的服務(wù)地址列表發(fā)生改變,就會通過NotifyListener通知消費者。此外,Dubbo的InvokerListener、ExporterListener 也實現(xiàn)了觀察者模式,只要實現(xiàn)該接口,并注冊,就可以接收到consumer端調(diào)用refer和provider端調(diào)用export的通知。

          修飾器模式:
          Dubbo中還大量用到了修飾器模式。比如ProtocolFilterWrapper類是對Protocol類的修飾。在export和refer方法中,配合責(zé)任鏈模式,把Filter組裝成責(zé)任鏈,實現(xiàn)對Protocol功能的修飾。其他還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。

          工廠方法模式:
          CacheFactory的實現(xiàn)采用的是工廠方法模式。CacheFactory接口定義getCache方法,然后定義一個AbstractCacheFactory抽象類實現(xiàn)CacheFactory,并將實際創(chuàng)建cache的createCache方法分離出來,并設(shè)置為抽象方法。這樣具體cache的創(chuàng)建工作就留給具體的子類去完成。

          抽象工廠模式:
          ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個方法,分別用來生產(chǎn)Proxy和Invoker(這兩個方法簽名看起來有些矛盾,因為getProxy方法需要傳入一個Invoker對象,而getInvoker方法需要傳入一個Proxy對象,看起來會形成循環(huán)依賴,但其實兩個方式使用的場景不一樣)。AbstractProxyFactory實現(xiàn)了ProxyFactory接口,作為具體實現(xiàn)類的抽象父類。然后定義了JdkProxyFactory和JavassistProxyFactory兩個具體類,分別用來生產(chǎn)基于jdk代理機制和基于javassist代理機制的Proxy和Invoker。

          適配器模式:
          為了讓用戶根據(jù)自己的需求選擇日志組件,Dubbo自定義了自己的Logger接口,并為常見的日志組件(包括jcl, jdk, log4j, slf4j)提供相應(yīng)的適配器。并且利用簡單工廠模式提供一個LoggerFactory,客戶可以創(chuàng)建抽象的Dubbo自定義Logger,而無需關(guān)心實際使用的日志組件類型。在LoggerFactory初始化時,客戶通過設(shè)置系統(tǒng)變量的方式選擇自己所用的日志組件,這樣提供了很大的靈活性。

          代理模式:
          Dubbo consumer使用Proxy類創(chuàng)建遠(yuǎn)程服務(wù)的本地代理,本地代理實現(xiàn)和遠(yuǎn)程服務(wù)一樣的接口,并且屏蔽了網(wǎng)絡(luò)通信的細(xì)節(jié),使得用戶在使用本地代理的時候,感覺和使用本地服務(wù)一樣。


          6.如果Dubbo中provider提供的服務(wù)由多個版本怎么辦?

          可以直接通過Dubbo配置中的version版本來控制多個版本即可。

          比如:

          <dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceFirst" version="1.0.0"/>
          <dubbo:service interface="com.xxxx.rent.service.IDemoService" ref="iDemoServiceSecond" version="1.0.1"/>
          

          老版本 version=1.0.0, 新版本version=1.0.1


          7.服務(wù)暴露的流程是怎么樣的?

          1.通過ServiceConfig解析標(biāo)簽,創(chuàng)建dubbo標(biāo)簽解析器來解析dubbo的標(biāo)簽,容器創(chuàng)建完成之后,觸發(fā)ContextRefreshEvent事件回調(diào)開始暴露服務(wù)

          2.通過proxyFactory.getInvoker方法,并利用javassist或DdkProxyFactory來進(jìn)行動態(tài)代理,將服務(wù)暴露接口封裝成invoker對象,里面包含了需要執(zhí)行的方法的對象信息和具體的URL地址。

          3.再通過DubboProtocol的實現(xiàn)把包裝后的invoker轉(zhuǎn)換成exporter,

          4.然后啟動服務(wù)器server,監(jiān)聽端口

          5.最后RegistryProtocol保存URL地址和invoker的映射關(guān)系,同時注冊到服務(wù)中心


          8.服務(wù)引用的流程是怎么樣的?

          1.首先客戶端根據(jù)config文件信息從注冊中心訂閱服務(wù),首次會全量緩存到本地,后續(xù)的更新會監(jiān)聽動態(tài)更新到本地。

          2.之后DubboProtocol根據(jù)provider的地址和接口信息連接到服務(wù)端server,開啟客戶端client,然后創(chuàng)建invoker

          3.之后通過invoker為服務(wù)接口生成代理對象,這個代理對象用于遠(yuǎn)程調(diào)用provider,至此完成了服務(wù)引用


          9.Dubbo的注冊中心有哪些?

          Zookeeper、Redis、Multicast、Simple 等都可以作為Dubbo的注冊中心


          10.聊聊Dubbo SPI機制?

          SPI(Service Provider Interface),是一種服務(wù)發(fā)現(xiàn)機制,其實就是將結(jié)構(gòu)的實現(xiàn)類寫入配置當(dāng)中,在服務(wù)加載的時候?qū)⑴渲梦募毺帲虞d實現(xiàn)類,這樣就可以在運行的時候,動態(tài)的幫助接口替換實現(xiàn)類

          Dubbo的SPI其實是對java的SPI進(jìn)行了一種增強,可以按需加載實現(xiàn)類之外,增加了 IOC 和 AOP 的特性,還有自適應(yīng)擴展機制。

          SPI在dubbo應(yīng)用很多,包括協(xié)議擴展、集群擴展、路由擴展、序列化擴展等等。

          Dubbo對于文件目錄的配置分為了三類

          • 1.META-INF/services/ 目錄:該目錄下的 SPI 配置文件是為了用來兼容 Java SPI 。
          • 2.META-INF/dubbo/ 目錄:該目錄存放用戶自定義的 SPI 配置文件。
          key=com.xxx.xxx
          
          • 3.META-INF/dubbo/internal/ 目錄:該目錄存放 Dubbo 內(nèi)部使用的 SPI 配置文件。

          11.Dubbo的SPi和JAVA的SPI有什么區(qū)別?

          Java Spi

          • Java SPI 在查找擴展實現(xiàn)類的時候遍歷 SPI 的配置文件并且將實現(xiàn)類全部實例化

          Dubbo Spi

          • 1,對 Dubbo 進(jìn)行擴展,不需要改動 Dubbo 的源碼
          • 2,延遲加載,可以一次只加載自己想要加載的擴展實現(xiàn)。
          • 3,增加了對擴展點 IOC 和 AOP 的支持,一個擴展點可以直接 setter 注入其它擴展點。
          • 4,Dubbo 的擴展機制能很好的支持第三方 IoC 容器,默認(rèn)支持 Spring Bean。

          12.有哪些負(fù)載均衡策略?

          1.加權(quán)隨機:比如我們有三臺服務(wù)器[A, B, C],給他們設(shè)置權(quán)重為[4, 5, 6],然后講這三個數(shù)平鋪在水平線上,和為15。

          然后在15以內(nèi)生成一個隨機數(shù),0~4是服務(wù)器A,4~9是服務(wù)器B,9~15是服務(wù)器C

          2.最小活躍數(shù):每個服務(wù)提供者對應(yīng)一個活躍數(shù) active,初始情況下,所有服務(wù)提供者活躍數(shù)均為0。每收到一個請求,活躍數(shù)加1,完成請求后則將活躍數(shù)減1。在服務(wù)運行一段時間后,性能好的服務(wù)提供者處理請求的速度更快,因此活躍數(shù)下降的也越快,此時這樣的服務(wù)提供者能夠優(yōu)先獲取到新的服務(wù)請求。

          3.一致性hash

          • 首先求出memcached服務(wù)器(節(jié)點)的哈希值,并將其配置到0~2的32次方的圓(continuum)上。
          • 然后采用同樣的方法求出存儲數(shù)據(jù)的鍵的哈希值,并映射到相同的圓上。
          • 然后從數(shù)據(jù)映射到的位置開始順時針查找,將數(shù)據(jù)保存到找到的第一個服務(wù)器上。如果超過2的32次方仍然找不到服務(wù)器,就會保存到第一臺memcached服務(wù)器上。

          4.加權(quán)輪詢:比如我們有三臺服務(wù)器[A, B, C],給他們設(shè)置權(quán)重為[4, 5, 6],那么假如總共有15次請求,那么會有4次落在A服務(wù)器,5次落在B服務(wù)器,6次落在C服務(wù)器。


          13.集群容錯方式有哪些?

          1.Failover Cluster失敗自動切換:dubbo的默認(rèn)容錯方案,當(dāng)調(diào)用失敗時自動切換到其他可用的節(jié)點,具體的重試次數(shù)和間隔時間可用通過引用服務(wù)的時候配置,默認(rèn)重試次數(shù)為1是只調(diào)用一次。

          2.Failback Cluster失敗自動恢復(fù):在調(diào)用失敗,記錄日志和調(diào)用信息,然后返回空結(jié)果給consumer,并且通過定時任務(wù)每隔5秒對失敗的調(diào)用進(jìn)行重試

          3.Failfast Cluster快速失敗:只會調(diào)用一次,失敗后立刻拋出異常

          4.Failsafe Cluster失敗安全:調(diào)用出現(xiàn)異常,記錄日志不拋出,返回空結(jié)果

          5.Forking Cluster并行調(diào)用多個服務(wù)提供者:通過線程池創(chuàng)建多個線程,并發(fā)調(diào)用多個provider,結(jié)果保存到阻塞隊列,只要有一個provider成功返回了結(jié)果,就會立刻返回結(jié)果

          6.Broadcast Cluster廣播模式:逐個調(diào)用每個provider,如果其中一臺報錯,在循環(huán)調(diào)用結(jié)束后,拋出異常。


          14.說說Dubbo的分層?

          分層圖:

          從大的范圍來說,dubbo分為三層

          • business業(yè)務(wù)邏輯層由我們自己來提供接口和實現(xiàn)還有一些配置信息
          • RPC層就是真正的RPC調(diào)用的核心層,封裝整個RPC的調(diào)用過程、負(fù)載均衡、集群容錯、代理
          • remoting則是對網(wǎng)絡(luò)傳輸協(xié)議和數(shù)據(jù)轉(zhuǎn)換的封裝。

          Service和Config兩層可以認(rèn)為是API層,主要提供給API使用者,使用者只需要配置和完成業(yè)務(wù)代碼就可以了。

          后面所有的層級是SPI層,主 要提供給擴展者使用主要是用來做Dubbo的二次開發(fā)擴展功能。

          再劃分到更細(xì)的層面,就是圖中的10層模式。


          15.服務(wù)提供者能實現(xiàn)失效踢出是什么原理?

          服務(wù)失效踢出基于Zookeeper的臨時節(jié)點原理。

          Zookeeper中節(jié)點是有生命周期的,具體的生命周期取決于節(jié)點的類型,節(jié)點主要分為持久節(jié)點(Persistent)和臨時節(jié)點(Ephemeral) 。


          16.為什么要通過代理對象通信??

          其實主要就是為了將調(diào)用細(xì)節(jié)封裝起來,將調(diào)用遠(yuǎn)程方法變得和調(diào)用本地方法一樣簡單,還可以做一些其他方面的增強,比如負(fù)載均衡,容錯機制,過濾操作,調(diào)用數(shù)據(jù)的統(tǒng)計。


          17.怎么設(shè)計一個RPC框架?

          關(guān)于這個問題,其實核心考察點就是你對于RPC框架的理解,一個成熟的RPC框架可以完成哪些功能,其實當(dāng)我們看過一兩個RPC框架后,就可以對這個問題回答個七七八八了,我們來舉個例子。

          1.首先我們得需要一個注冊中心,去管理消費者和提供者的節(jié)點信息,這樣才會有消費者和提供才可以去訂閱服務(wù),注冊服務(wù)。

          2.當(dāng)有了注冊中心后,可能會有很多個provider節(jié)點,那么我們肯定會有一個負(fù)載均衡模塊來負(fù)責(zé)節(jié)點的調(diào)用,至于用戶指定路由規(guī)則可以使一個額外的優(yōu)化點。

          3.具體的調(diào)用肯定會需要牽扯到通信協(xié)議,所以需要一個模塊來對通信協(xié)議進(jìn)行封裝,網(wǎng)絡(luò)傳輸還要考慮序列化。

          4.當(dāng)調(diào)用失敗后怎么去處理?所以我們還需要一個容錯模塊,來負(fù)責(zé)失敗情況的處理。

          5.其實做完這些一個基礎(chǔ)的模型就已經(jīng)搭建好了,我們還可以有更多的優(yōu)化點,比如一些請求數(shù)據(jù)的監(jiān)控,配置信息的處理,日志信息的處理等等。

          這其實就是一個比較基本的RPC框架的大體思路,大家有沒有g(shù)et到?

          服務(wù)架構(gòu)是互聯(lián)網(wǎng)很熱門的話題,是互聯(lián)網(wǎng)技術(shù)發(fā)展的必然結(jié)果。它提倡將單一應(yīng)用程序劃分成一組小的服務(wù),服務(wù)之間互相協(xié)調(diào)、互相配合,為用戶提供最終價值。雖然微服務(wù)架構(gòu)沒有公認(rèn)的技術(shù)標(biāo)準(zhǔn)和規(guī)范或者草案,但業(yè)界已經(jīng)有一些很有影響力的開源微服務(wù)架構(gòu)框架提供了微服務(wù)的關(guān)鍵思路,例如Dubbo和Spring Cloud。各大互聯(lián)網(wǎng)公司也有自研的微服務(wù)框架,但其模式都于這二者相差不大。

          微服務(wù)主要的優(yōu)勢如下:

          1、降低復(fù)雜度

          將原來偶合在一起的復(fù)雜業(yè)務(wù)拆分為單個服務(wù),規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能,并通過定義良好的接口清晰表述服務(wù)邊界。每個服務(wù)開發(fā)者只專注服務(wù)本身,通過使用緩存、DAL等各種技術(shù)手段來提升系統(tǒng)的性能,而對于消費方來說完全透明。

          2、可獨立部署

          由于微服務(wù)具備獨立的運行進(jìn)程,所以每個微服務(wù)可以獨立部署。當(dāng)業(yè)務(wù)迭代時只需要發(fā)布相關(guān)服務(wù)的迭代即可,降低了測試的工作量同時也降低了服務(wù)發(fā)布的風(fēng)險。

          3、容錯

          在微服務(wù)架構(gòu)下,當(dāng)某一組件發(fā)生故障時,故障會被隔離在單個服務(wù)中。 通過限流、熔斷等方式降低錯誤導(dǎo)致的危害,保障核心業(yè)務(wù)正常運行。

          4、擴展

          單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展,就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴展需求上存在差異時,微服務(wù)架構(gòu)便體現(xiàn)出其靈活性,因為每個服務(wù)可以根據(jù)實際需求獨立進(jìn)行擴展。

          本文主要圍繞微服務(wù)的技術(shù)選型、通訊協(xié)議、服務(wù)依賴模式、開始模式、運行模式等幾方面來綜合比較Dubbo和Spring Cloud 這2種開發(fā)框架。架構(gòu)師可以根據(jù)公司的技術(shù)實力并結(jié)合項目的特點來選擇某個合適的微服務(wù)架構(gòu)平臺,以此穩(wěn)妥地實施項目的微服務(wù)化改造或開發(fā)進(jìn)程。

          一、核心部件

          微服務(wù)的核心要素在于服務(wù)的發(fā)現(xiàn)、注冊、路由、熔斷、降級、分布式配置,基于上述幾種必要條件對Dubbo和Spring Cloud做出對比。

          1、總體架構(gòu)

          Dubbo 核心部件(如下圖):

          Provider: 暴露服務(wù)的提供方,可以通過jar或者容器的方式啟動服務(wù)

          Consumer:調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。

          Registry: 服務(wù)注冊中心和發(fā)現(xiàn)中心。

          Monitor: 統(tǒng)計服務(wù)和調(diào)用次數(shù),調(diào)用時間監(jiān)控中心。(dubbo的控制臺頁面中可以顯示,目前只有一個簡單版本)

          Container:服務(wù)運行的容器。

          ▲Dubbo 總體架構(gòu)

          Spring Cloud總體架構(gòu)如下圖

          Service Provider: 暴露服務(wù)的提供方。

          Service Consumer:調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方。

          EureKa Server: 服務(wù)注冊中心和服務(wù)發(fā)現(xiàn)中心。

          ▲Spring Cloud總體架構(gòu)

          點評:從整體架構(gòu)上來看,二者模式接近,都需要需要服務(wù)提供方,注冊中心,服務(wù)消費方。

          2、微服務(wù)架構(gòu)核心要素

          Dubbo只是實現(xiàn)了服務(wù)治理,而Spring Cloud子項目分別覆蓋了微服務(wù)架構(gòu)下的眾多部件,而服務(wù)治理只是其中的一個方面。Dubbo提供了各種Filter,對于上述中“無”的要素,可以通過擴展Filter來完善。

          例如

          1.分布式配置:可以使用淘寶的diamond、百度的disconf來實現(xiàn)分布式配置管理

          2.服務(wù)跟蹤:可以使用京東開源的Hydra,或者擴展Filter用Zippin來做服務(wù)跟蹤

          3.批量任務(wù):可以使用當(dāng)當(dāng)開源的Elastic-Job、tbschedule

          點評:從核心要素來看,Spring Cloud 更勝一籌,在開發(fā)過程中只要整合Spring Cloud的子項目就可以順利的完成各種組件的融合,而Dubbo缺需要通過實現(xiàn)各種Filter來做定制,開發(fā)成本以及技術(shù)難度略高。

          二、通訊協(xié)議

          基于通訊協(xié)議層面對2種框架支持的協(xié)議類型以及運行效率方面進(jìn)行比較;

          (一)、支持協(xié)議

          1、Dubbo:dubbo使用RPC通訊協(xié)議,提供序列化方式如下:

          dubbo:Dubbo缺省協(xié)議采用單一長連接和NIO異步通訊,適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用,以及服務(wù)消費者機器數(shù)遠(yuǎn)大于服務(wù)提供者機器數(shù)的情況

          rmi:RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實現(xiàn),采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式

          Hessian:Hessian協(xié)議用于集成Hessian的服務(wù),Hessian底層采用Http通訊,采用Servlet暴露服務(wù),Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實現(xiàn)

          http:采用Spring的HttpInvoker實現(xiàn)

          Webservice:基于CXF的frontend-simple和transports-http實現(xiàn)

          2、Spring Cloud:Spring Cloud 使用HTTP協(xié)議的REST API

          (二)、性能比較

          使用一個Pojo對象包含10個屬性,請求10萬次,Dubbo和Spring Cloud在不同的線程數(shù)量下,每次請求耗時(ms)如下:

          說明:客戶端和服務(wù)端配置均采用阿里云的ECS服務(wù)器,4核8G配置,dubbo采用默認(rèn)的dubbo協(xié)議

          點評:dubbo支持各種通信協(xié)議,而且消費方和服務(wù)方使用長鏈接方式交互,通信速度上略勝Spring Cloud,如果對于系統(tǒng)的響應(yīng)時間有嚴(yán)格要求,長鏈接更合適。

          三、服務(wù)依賴方式

          Dubbo:服務(wù)提供方與消費方通過接口的方式依賴,服務(wù)調(diào)用設(shè)計如下:

          interface層:服務(wù)接口層,定義了服務(wù)對外提供的所有接口

          Molel層:服務(wù)的DTO對象層,

          business層:業(yè)務(wù)實現(xiàn)層,實現(xiàn)interface接口并且和DB交互

          因此需要為每個微服務(wù)定義了各自的interface接口,并通過持續(xù)集成發(fā)布到私有倉庫中,調(diào)用方應(yīng)用對微服務(wù)提供的抽象接口存在強依賴關(guān)系,開發(fā)、測試、集成環(huán)境都需要嚴(yán)格的管理版本依賴。如果想免費學(xué)習(xí)Java工程化、高性能及分布式、深入淺出。微服務(wù)、Spring,MyBatis,Netty源碼分析的朋友可以加我的Java進(jìn)階群:478030634,群里有阿里大牛直播講解技術(shù),以及Java大型互聯(lián)網(wǎng)技術(shù)的視頻免費分享給大家。

          通過maven的install & deploy命令把interface和Model層發(fā)布到倉庫中,服務(wù)調(diào)用方只需要依賴interface和model層即可。在開發(fā)調(diào)試階段只發(fā)布Snapshot版本。等到服務(wù)調(diào)試完成再發(fā)布Release版本,通過版本號來區(qū)分每次迭代的版本。通過xml配置方式即可方面接入dubbo,對程序無入侵。

          ▲Dubbo接口依賴方式

          Spring Cloud:服務(wù)提供方和服務(wù)消費方通過json方式交互,因此只需要定義好相關(guān)json字段即可,消費方和提供方無接口依賴。通過注解方式來實現(xiàn)服務(wù)配置,對于程序有一定入侵。

          點評:Dubbo服務(wù)依賴略重,需要有完善的版本管理機制,但是程序入侵少。而Spring Cloud通過Json交互,省略了版本管理的問題,但是具體字段含義需要統(tǒng)一管理,自身Rest API方式交互,為跨平臺調(diào)用奠定了基礎(chǔ)。

          四、組件運行流程

          下圖中的每個組件都是需要部署在單獨的服務(wù)器上,gateway用來接受前端請求、聚合服務(wù),并批量調(diào)用后臺原子服務(wù)。每個service層和單獨的DB交互。

          ▲Dubbo組件運行流程

          gateWay:前置網(wǎng)關(guān),具體業(yè)務(wù)操作,gateWay通過dubbo提供的負(fù)載均衡機制自動完成

          Service:原子服務(wù),只提供該業(yè)務(wù)相關(guān)的原子服務(wù)

          Zookeeper:原子服務(wù)注冊到zk上

          ▲Spring Cloud 組件運行

          Spring Cloud

          所有請求都統(tǒng)一通過 API 網(wǎng)關(guān)(Zuul)來訪問內(nèi)部服務(wù)。

          網(wǎng)關(guān)接收到請求后,從注冊中心(Eureka)獲取可用服務(wù)。

          由 Ribbon 進(jìn)行均衡負(fù)載后,分發(fā)到后端的具體實例。

          微服務(wù)之間通過 Feign 進(jìn)行通信處理業(yè)務(wù)。

          點評:業(yè)務(wù)部署方式相同,都需要前置一個網(wǎng)關(guān)來隔絕外部直接調(diào)用原子服務(wù)的風(fēng)險。Dubbo需要自己開發(fā)一套API 網(wǎng)關(guān),而Spring Cloud則可以通過Zuul配置即可完成網(wǎng)關(guān)定制。使用方式上Spring Cloud略勝一籌。

          五、微服務(wù)架構(gòu)組成以及注意事項

          到底使用是dubbo還是Spring Cloud其實并不重要,重點在于如何合理的利用微服務(wù)。下面是一張互聯(lián)網(wǎng)通用的架構(gòu)圖,其中每個環(huán)節(jié)都是微服務(wù)的核心部分。

          (一)、架構(gòu)分解

          網(wǎng)關(guān)集群:數(shù)據(jù)的聚合、實現(xiàn)對接入客戶端的身份認(rèn)證、防報文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制等

          業(yè)務(wù)集群:一般情況下移動端訪問和瀏覽器訪問的網(wǎng)關(guān)需要隔離,防止業(yè)務(wù)耦合

          Local Cache:由于客戶端訪問業(yè)務(wù)可能需要調(diào)用多個服務(wù)聚合,所以本地緩存有效的降低了服務(wù)調(diào)用的頻次,同時也提示了訪問速度。本地緩存一般使用自動過期方式,業(yè)務(wù)場景中允許有一定的數(shù)據(jù)延時。

          服務(wù)層:原子服務(wù)層,實現(xiàn)基礎(chǔ)的增刪改查功能,如果需要依賴其他服務(wù)需要在Service層主動調(diào)用

          Remote Cache:訪問DB前置一層分布式緩存,減少DB交互次數(shù),提升系統(tǒng)的TPS

          DAL:數(shù)據(jù)訪問層,如果單表數(shù)據(jù)量過大則需要通過DAL層做數(shù)據(jù)的分庫分表處理。

          MQ:消息隊列用來解耦服務(wù)之間的依賴,異步調(diào)用可以通過MQ的方式來執(zhí)行

          數(shù)據(jù)庫主從:服務(wù)化過程中畢竟的階段,用來提升系統(tǒng)的TPS

          (二)注意事項

          服務(wù)啟動方式建議使用jar方式啟動,啟動速度快,更容易監(jiān)控

          緩存、緩存、緩存,系統(tǒng)中能使用緩存的地方盡量使用緩存,通過合理的使用緩存可以有效的提高系統(tǒng)的TPS

          服務(wù)拆分要合理,盡量避免因服務(wù)拆分而導(dǎo)致的服務(wù)循環(huán)依賴

          合理的設(shè)置線程池,避免設(shè)置過大或者過小導(dǎo)致系統(tǒng)異常

          六、總結(jié)

          Dubbo出生于阿里系,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于中國各互聯(lián)網(wǎng)公司;只需要通過spring配置的方式即可完成服務(wù)化,對于應(yīng)用無入侵。設(shè)計的目的還是服務(wù)于自身的業(yè)務(wù)為主。雖然阿里內(nèi)部原因dubbo曾經(jīng)一度暫停維護(hù)版本,但是框架本身的成熟度以及文檔的完善程度,完全能滿足各大互聯(lián)網(wǎng)公司的業(yè)務(wù)需求。如果我們需要使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成,這樣無形中增加了使用 Dubbo 的難度。

          Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品, 專注于企業(yè)級開源框架的研發(fā)。 Spring Cloud 自從發(fā)展到現(xiàn)在,仍然在不斷的高速發(fā)展,幾乎考慮了服務(wù)治理的方方面面,開發(fā)起來非常的便利和簡單。

          Dubbo于2017年開始又重啟維護(hù),發(fā)布了更新后的2.5.6版本,而Spring Cloud更新的非常快,目前已經(jīng)更新到Finchley.M2。因此,企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構(gòu)來解決業(yè)務(wù)問題,不管是Dubbo還是Spring Cloud都是實現(xiàn)微服務(wù)有效的工具。


          主站蜘蛛池模板: 精品国产日韩亚洲一区91| 一区二区精品视频| 国产一区中文字幕| 国模大尺度视频一区二区| 国产一区二区三区不卡观| 亚洲一区免费观看| 色狠狠色噜噜Av天堂一区| 精品乱码一区二区三区四区| 福利一区在线视频| 精品国产一区二区三区无码| 国产精品小黄鸭一区二区三区| 久久久精品人妻一区二区三区| 国产在线一区二区三区av| 精品福利一区二区三区免费视频| 日亚毛片免费乱码不卡一区 | 亚洲午夜精品一区二区| 国产伦精品一区二区三区无广告| 78成人精品电影在线播放日韩精品电影一区亚洲 | 国产精久久一区二区三区| 无码国产精品一区二区免费虚拟VR | 久久青青草原一区二区| 亚洲国产一区在线| 人妻体内射精一区二区三四| 中文字幕日本一区| 国产一区二区高清在线播放| 精品3d动漫视频一区在线观看| 亚洲av成人一区二区三区观看在线 | 国产成人高清亚洲一区91| 国产乱人伦精品一区二区| 在线精品国产一区二区| 国产精品一区在线播放| 日产亚洲一区二区三区| 久久久久久综合一区中文字幕| 国产精品一区12p| 国产精品va无码一区二区| 久久99精品一区二区三区| 韩国福利一区二区美女视频| 97久久精品一区二区三区| 国产美女一区二区三区| 海角国精产品一区一区三区糖心| 国产在线精品一区在线观看|