建站
咨詢
售后
建站咨詢
新聞中心
微服務架構是互聯(lián)網(wǎng)很熱門的話題，是互聯(lián)網(wǎng)技術發(fā)展的必然結果。它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。
讓客戶滿意是我們工作的目標，不斷超越客戶的期望值來自于我們對這個行業(yè)的熱愛。我們立志把好的技術通過有效、簡單的方式提供給客戶，將通過不懈努力成為客戶在信息化領域值得信任、有價值的長期合作伙伴，公司提供的服務項目有：空間域名、網(wǎng)頁空間、營銷軟件、網(wǎng)站建設、通山網(wǎng)站維護、網(wǎng)站推廣。
雖然微服務架構沒有公認的技術標準和規(guī)范或者草案，但業(yè)界已經(jīng)有一些很有影響力的開源微服務架構框架提供了微服務的關鍵思路，例如 Dubbo 和 Spring Cloud。
各大互聯(lián)網(wǎng)公司也有自研的微服務框架，但其模式都與這二者相差不大。
微服務主要的優(yōu)勢
降低復雜度
將原來耦合在一起的復雜業(yè)務拆分為單個服務，規(guī)避了原本復雜度無止境的積累。
每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界；每個服務開發(fā)者只專注服務本身，通過使用緩存、DAL 等各種技術手段來提升系統(tǒng)的性能，而對于消費方來說完全透明。
可獨立部署
由于微服務具備獨立的運行進程，所以每個微服務可以獨立部署。當業(yè)務迭代時只需要發(fā)布相關服務的迭代即可，降低了測試的工作量同時也降低了服務發(fā)布的風險。
容錯
在微服務架構下，當某一組件發(fā)生故障時，故障會被隔離在單個服務中。比如通過限流、熔斷等方式降低錯誤導致的危害，保障核心業(yè)務正常運行。
擴展
單塊架構應用也可以實現(xiàn)橫向擴展，就是將整個應用完整的復制到不同的節(jié)點。
當應用的不同組件在擴展需求上存在差異時，微服務架構便體現(xiàn)出其靈活性，因為每個服務可以根據(jù)實際需求獨立進行擴展。
本文主要圍繞微服務的技術選型、通訊協(xié)議、服務依賴模式、開始模式、運行模式等幾方面來綜合比較 Dubbo 和 Spring Cloud 這 2 種開發(fā)框架。
架構師可以根據(jù)公司的技術實力并結合項目的特點來選擇某個合適的微服務架構平臺，以此穩(wěn)妥地實施項目的微服務化改造或開發(fā)進程。
核心部件
微服務的核心要素在于服務的發(fā)現(xiàn)、注冊、路由、熔斷、降級、分布式配置，基于上述幾種必要條件對 Dubbo 和 Spring Cloud 做出對比。
總體架構
Dubbo 核心部件（如下圖）:
- Provider：暴露服務的提供方，可以通過 jar 或者容器的方式啟動服務。
- Consumer：調(diào)用遠程服務的服務消費方。
- Registry：服務注冊中心和發(fā)現(xiàn)中心。
- Monitor：統(tǒng)計服務和調(diào)用次數(shù)，調(diào)用時間監(jiān)控中心。（Dubbo 的控制臺頁面中可以顯示，目前只有一個簡單版本。）
- Container：服務運行的容器。
Dubbo 總體架構
Spring Cloud總體架構（如下圖）：
- Service Provider： 暴露服務的提供方。
- Service Consumer：調(diào)用遠程服務的服務消費方。
- EureKa Server： 服務注冊中心和服務發(fā)現(xiàn)中心。
Spring Cloud 總體架構
點評：從整體架構上來看，二者模式接近，都需要服務提供方，注冊中心，服務消費方。
微服務架構核心要素
Dubbo 只是實現(xiàn)了服務治理，而 Spring Cloud 子項目分別覆蓋了微服務架構下的眾多部件，服務治理只是其中的一個方面。
Dubbo 提供了各種 Filter，對于上述中“無”的要素，可以通過擴展 Filter 來完善。例如：
- 分布式配置：可以使用淘寶的 diamond、百度的 disconf 來實現(xiàn)分布式配置管理。
- 服務跟蹤：可以使用京東開源的 Hydra，或者擴展 Filter 用 Zippin 來做服務跟蹤。
- 批量任務：可以使用當當開源的 Elastic-Job、tbschedule。
點評：從核心要素來看，Spring Cloud 更勝一籌，在開發(fā)過程中只要整合 Spring Cloud 的子項目就可以順利的完成各種組件的融合，而 Dubbo 卻需要通過實現(xiàn)各種 Filter 來做定制，開發(fā)成本以及技術難度略高。
通訊協(xié)議
基于通訊協(xié)議層面對 2 種框架支持的協(xié)議類型以及運行效率方面進行比較。
支持協(xié)議
Dubbo
Dubbo 使用 RPC 通訊協(xié)議，提供序列化方式如下：
- Dubbo：Dubbo 缺省協(xié)議采用單一長連接和 NIO 異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務調(diào)用，以及服務消費者機器數(shù)遠大于服務提供者機器數(shù)的情況。
- RMI：RMI 協(xié)議采用 JDK 標準的 java.rmi.* 實現(xiàn)，采用阻塞式短連接和 JDK 標準序列化方式。
- Hessian：Hessian 協(xié)議用于集成 Hessian 的服務，Hessian 底層采用 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 缺省內(nèi)嵌 Jetty 作為服務器實現(xiàn)。
- HTTP：采用 Spring 的 Http Invoker 實現(xiàn)。
- Webservice：基于 CXF 的 frontend-simple 和 transports-http 實現(xiàn)。
Spring Cloud
Spring Cloud 使用 HTTP 協(xié)議的 REST API。
性能比較
使用一個 Pojo 對象包含 10 個屬性，請求 10 萬次，Dubbo 和 Spring Cloud 在不同的線程數(shù)量下，每次請求耗時（ms）如下：
說明：客戶端和服務端配置均采用阿里云的 ECS 服務器，4 核 8G 配置，Dubbo 采用默認的 Dubbo 協(xié)議。
點評：Dubbo 支持各種通信協(xié)議，而且消費方和服務方使用長鏈接方式交互，通信速度上略勝 Spring Cloud，如果對于系統(tǒng)的響應時間有嚴格要求，長鏈接更合適。
服務依賴方式
Dubbo
服務提供方與消費方通過接口的方式依賴，服務調(diào)用設計如下：
- Interface 層：服務接口層，定義了服務對外提供的所有接口。
- Molel 層：服務的 DTO 對象層。
- Business層：業(yè)務實現(xiàn)層，實現(xiàn) Interface 接口并且和 DB 交互。
因此需要為每個微服務定義各自的 Interface 接口，并通過持續(xù)集成發(fā)布到私有倉庫中。調(diào)用方應用對微服務提供的抽象接口存在強依賴關系，開發(fā)、測試、集成環(huán)境都需要嚴格的管理版本依賴。
通過 maven 的 install & deploy 命令把 Interface 和 Model 層發(fā)布到倉庫中，服務調(diào)用方只需要依賴 Interface 和 Model 層即可。
在開發(fā)調(diào)試階段只發(fā)布 Snapshot 版本，等到服務調(diào)試完成再發(fā)布 Release 版本，通過版本號來區(qū)分每次迭代的版本。通過 xml 配置方式即可接入 Dubbo，對程序無入侵。
Dubbo 接口依賴方式
Spring Cloud
服務提供方和服務消費方通過 Json 方式交互，因此只需要定義好相關 Json 字段即可，消費方和提供方無接口依賴。通過注解方式來實現(xiàn)服務配置，對于程序有一定入侵。
點評：Dubbo 服務依賴略重，需要有完善的版本管理機制，但是程序入侵少。
而 Spring Cloud 通過 Json 交互，省略了版本管理的問題，但是具體字段含義需要統(tǒng)一管理，自身 Rest API 方式交互，為跨平臺調(diào)用奠定了基礎。
組件運行流程
Dubbo
下圖中的每個組件都是需要部署在單獨的服務器上，Gateway 用來接受前端請求、聚合服務，并批量調(diào)用后臺原子服務。每個 Service 層和單獨的 DB 交互。
Dubbo 組件運行流程
Dubbo 組件運行：
- Gateway：前置網(wǎng)關，具體業(yè)務操作，Gateway 通過 Dubbo 提供的負載均衡機制自動完成。
- Service：原子服務，只提供該業(yè)務相關的原子服務。
- Zookeeper：原子服務注冊到 ZK 上。
Spring Cloud 組件運行
Spring Cloud
Spring Cloud組件運行：
- 所有請求都統(tǒng)一通過 API 網(wǎng)關（Zuul）來訪問內(nèi)部服務。
- 網(wǎng)關接收到請求后，從注冊中心（Eureka）獲取可用服務。
- 由 Ribbon 進行均衡負載后，分發(fā)到后端的具體實例。
- 微服務之間通過 Feign 進行通信處理業(yè)務。
點評：業(yè)務部署方式相同，都需要前置一個網(wǎng)關來隔絕外部直接調(diào)用原子服務的風險。
Dubbo 需要自己開發(fā)一套 API 網(wǎng)關，而 Spring Cloud 則可以通過 Zuul 配置即可完成網(wǎng)關定制。使用方式上 Spring Cloud 略勝一籌。
微服務架構組成以及注意事項
到底使用是 Dubbo 還是 Spring Cloud 并不重要，重點在于如何合理的利用微服務。
下面是一張互聯(lián)網(wǎng)通用的架構圖，其中每個環(huán)節(jié)都是微服務的核心部分。
架構分解：
- 網(wǎng)關集群：數(shù)據(jù)的聚合、實現(xiàn)對接入客戶端的身份認證、防報文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務鑒權、響應數(shù)據(jù)的脫敏、流量與并發(fā)控制等。
- 業(yè)務集群：一般情況下移動端訪問和瀏覽器訪問的網(wǎng)關需要隔離，防止業(yè)務耦合。
- Local Cache：由于客戶端訪問業(yè)務可能需要調(diào)用多個服務聚合，所以本地緩存有效的降低了服務調(diào)用的頻次，同時也提示了訪問速度。本地緩存一般使用自動過期方式，業(yè)務場景中允許有一定的數(shù)據(jù)延時。
- 服務層：原子服務層，實現(xiàn)基礎的增刪改查功能，如果需要依賴其他服務需要在 Service 層主動調(diào)用。
- Remote Cache：訪問 DB 前置一層分布式緩存，減少 DB 交互次數(shù)，提升系統(tǒng)的TPS。
- DAL：數(shù)據(jù)訪問層，如果單表數(shù)據(jù)量過大則需要通過 DAL 層做數(shù)據(jù)的分庫分表處理。
- MQ：消息隊列用來解耦服務之間的依賴，異步調(diào)用可以通過 MQ 的方式來執(zhí)行。
- 數(shù)據(jù)庫主從：服務化過程中必經(jīng)的階段，用來提升系統(tǒng)的 TPS。
注意事項：
- 服務啟動方式建議使用jar方式啟動，啟動速度快，更容易監(jiān)控。
- 緩存、緩存、緩存，系統(tǒng)中能使用緩存的地方盡量使用緩存，通過合理的使用緩存可以有效的提高系統(tǒng)的TPS。
- 服務拆分要合理，盡量避免因服務拆分而導致的服務循環(huán)依賴。
- 合理的設置線程池，避免設置過大或者過小導致系統(tǒng)異常。
總結
Dubbo 出生于阿里系，是阿里巴巴服務化治理的核心框架，并被廣泛應用于中國各互聯(lián)網(wǎng)公司；只需要通過 Spring 配置的方式即可完成服務化，對于應用無入侵，設計的目的還是服務于自身的業(yè)務為主。
雖然阿里內(nèi)部原因 Dubbo 曾經(jīng)一度暫停維護版本，但是框架本身的成熟度以及文檔的完善程度，完全能滿足各大互聯(lián)網(wǎng)公司的業(yè)務需求。
如果我們使用配置中心、分布式跟蹤這些內(nèi)容都需要自己去集成，這樣無形中增加了使用 Dubbo 的難度。
Spring Cloud 是大名鼎鼎的 Spring 家族的產(chǎn)品， 專注于企業(yè)級開源框架的研發(fā)。
Spring Cloud 自從發(fā)布到現(xiàn)在，仍然在不斷的高速發(fā)展，幾乎考慮了服務治理的方方面面，開發(fā)起來非常的便利和簡單。
Dubbo 于 2017 年開始又重啟維護，發(fā)布了更新后的 2.5.7 版本，而 Spring Cloud 更新的非?？?，目前已經(jīng)更新到 Finchley.M2。
因此，企業(yè)需要根據(jù)自身的研發(fā)水平和所處階段選擇合適的架構來解決業(yè)務問題，不管是 Dubbo 還是 Spring Cloud 都是實現(xiàn)微服務有效的工具。
本文名稱：到底孰優(yōu)孰劣？Dubbo和SpringCloud微服務架構終極對決！
文章地址：http://www.5511xx.com/article/copoege.html
