微服務（Microservices）是一種架構風格凉馆，一個大型復雜軟件應用由一個或多個微服務組成。

系統(tǒng)中的各個微服務可被獨立部署，各個微服務之間是松耦合的彬伦。每個微服務僅關注于完成一件任務并很好地完成該任務滔悉。在所有情況下，每個任務代表著一個小的業(yè)務能力单绑。

一回官、微服務主要的優(yōu)勢

1.1 降低復雜度

將原來耦合在一起的復雜業(yè)務拆分為單個服務，規(guī)避了原本復雜度無止境的積累搂橙。

每一個微服務專注于單一功能歉提，并通過定義良好的接口清晰表述服務邊界；每個服務開發(fā)者只專注服務本身区转，通過使用緩存唯袄、DAL 等各種技術手段來提升系統(tǒng)的性能，而對于消費方來說完全透明蜗帜。

1.2 可獨立部署

由于微服務具備獨立的運行進程恋拷，所以每個微服務可以獨立部署。當業(yè)務迭代時只需要發(fā)布相關服務的迭代即可厅缺，降低了測試的工作量同時也降低了服務發(fā)布的風險蔬顾。

1.3 容錯

在微服務架構下，當某一組件發(fā)生故障時湘捎，故障會被隔離在單個服務中诀豁。比如通過限流、熔斷等方式降低錯誤導致的危害窥妇，保障核心業(yè)務正常運行舷胜。

1.4 擴展

單塊架構應用也可以實現(xiàn)橫向擴展，就是將整個應用完整的復制到不同的節(jié)點活翩。

當應用的不同組件在擴展需求上存在差異時烹骨，微服務架構便體現(xiàn)出其靈活性藕漱，因為每個服務可以根據(jù)實際需求獨立進行擴展吕嘀。

二创淡、微服務架構選型

2.1 核心部件

微服務的核心要素在于服務的發(fā)現(xiàn)不皆、注冊、路由代赁、熔斷掩宜、降級戚扳、分布式配置旦事，基于上述幾種必要條件對 Dubbo 和 Spring Cloud 做出對比魁巩。

2.2 總體架構

2.2.1 Dubbo 核心部件

節(jié)點角色說明

Provider：暴露服務的提供方，可以通過 jar 或者容器的方式啟動服務姐浮。

Consumer：調(diào)用遠程服務的服務消費方谷遂。

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

Monitor：統(tǒng)計服務和調(diào)用次數(shù)单料，調(diào)用時間監(jiān)控中心埋凯。（Dubbo 的控制臺頁面中可以顯示点楼，目前只有一個簡單版本扫尖。）

Container：服務運行的容器白对。

調(diào)用關系說明：

0. 服務容器負責啟動，加載换怖，運行服務提供者甩恼。

1. 服務提供者在啟動時，向注冊中心注冊自己提供的服務沉颂。

2. 服務消費者在啟動時条摸，向注冊中心訂閱自己所需的服務。

3. 注冊中心返回服務提供者地址列表給消費者铸屉，如果有變更钉蒲，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。

4. 服務消費者彻坛，從提供者地址列表中顷啼，基于軟負載均衡算法，選一臺提供者進行調(diào)用昌屉，如果調(diào)用失敗钙蒙，再選另一臺調(diào)用。

5. 服務消費者和提供者间驮，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間躬厌，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

(1) 連通性：

注冊中心負責服務地址的注冊與查找竞帽，相當于目錄服務扛施，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發(fā)請求屹篓，壓力較小

監(jiān)控中心負責統(tǒng)計各服務調(diào)用次數(shù)煮嫌，調(diào)用時間等，統(tǒng)計先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務器抱虐，并以報表展示

服務提供者向注冊中心注冊其提供的服務昌阿，并匯報調(diào)用時間到監(jiān)控中心，此時間不包含網(wǎng)絡開銷

服務消費者向注冊中心獲取服務提供者地址列表恳邀，并根據(jù)負載算法直接調(diào)用提供者懦冰，同時匯報調(diào)用時間到監(jiān)控中心，此時間包含網(wǎng)絡開銷

注冊中心谣沸，服務提供者刷钢，服務消費者三者之間均為長連接，監(jiān)控中心除外

注冊中心通過長連接感知服務提供者的存在乳附，服務提供者宕機内地，注冊中心將立即推送事件通知消費者

注冊中心和監(jiān)控中心全部宕機伴澄，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

注冊中心和監(jiān)控中心都是可選的阱缓，服務消費者可以直連服務提供者

(2) 健狀性：

監(jiān)控中心宕掉不影響使用非凌，只是丟失部分采樣數(shù)據(jù)

數(shù)據(jù)庫宕掉后，注冊中心仍能通過緩存提供服務列表查詢荆针，但不能注冊新服務

注冊中心對等集群敞嗡，任意一臺宕掉后，將自動切換到另一臺

注冊中心全部宕掉后航背，服務提供者和服務消費者仍能通過本地緩存通訊

服務提供者無狀態(tài)喉悴，任意一臺宕掉后，不影響使用

服務提供者全部宕掉后玖媚，服務消費者應用將無法使用箕肃，并無限次重連等待服務提供者恢復

(3) 伸縮性：

注冊中心為對等集群，可動態(tài)增加機器部署實例今魔，所有客戶端將自動發(fā)現(xiàn)新的注冊中心

服務提供者無狀態(tài)勺像，可動態(tài)增加機器部署實例，注冊中心將推送新的服務提供者信息給消費者

(4) 升級性：

當服務集群規(guī)模進一步擴大涡贱，帶動IT治理結構進一步升級咏删，需要實現(xiàn)動態(tài)部署，進行流動計算问词，現(xiàn)有分布式服務架構不會帶來阻力：

2.2.2 Spring Cloud總體架構

Service Provider： 暴露服務的提供方督函。

Service Consumer：調(diào)用遠程服務的服務消費方。

EureKa Server： 服務注冊中心和服務發(fā)現(xiàn)中心激挪。

2.2.3 點評

從整體架構上來看辰狡，二者模式接近，都需要服務提供方垄分，注冊中心宛篇，服務消費方。

2.3 微服務架構核心要素

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ā)成本以及技術難度略高司倚。

2.4 通訊協(xié)議

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

2.4.1 支持協(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。

2.4.2 性能比較

使用一個 Pojo 對象包含 10 個屬性辰晕，請求 10 萬次蛤迎，Dubbo 和 Spring Cloud 在不同的線程數(shù)量下含友，每次請求耗時（ms）如下：

說明：客戶端和服務端配置均采用阿里云的 ECS 服務器，4 核 8G 配置辆童，Dubbo 采用默認的 Dubbo 協(xié)議胸遇。

點評

Dubbo 支持各種通信協(xié)議汉形，而且消費方和服務方使用長鏈接方式交互倍阐，通信速度上略勝 Spring Cloud峰搪，如果對于系統(tǒng)的響應時間有嚴格要求凯旭，長鏈接更合適罐呼。

2.5 服務依賴方式

2.5.1 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扬蕊，對程序無入侵弹囚。

2.5.2 Spring Cloud

服務提供方和服務消費方通過 Json 方式交互鸥鹉，因此只需要定義好相關 Json 字段即可庶骄，消費方和提供方無接口依賴单刁。通過注解方式來實現(xiàn)服務配置羔飞，對于程序有一定入侵。

2.5.3 點評

Dubbo 服務依賴略重么伯，需要有完善的版本管理機制卡儒，但是程序入侵少骨望。

而 Spring Cloud 通過 Json 交互擎鸠，省略了版本管理的問題，但是具體字段含義需要統(tǒng)一管理袜蚕，自身 Rest API 方式交互，為跨平臺調(diào)用奠定了基礎

2.6 組件運行流程

2.6.1 Dubbo

下圖中的每個組件都是需要部署在單獨的服務器上糊饱，Gateway 用來接受前端請求另锋、聚合服務狭归，并批量調(diào)用后臺原子服務过椎。每個 Service 層和單獨的 DB 交互疚宇。

Dubbo 組件運行：

Gateway：前置網(wǎng)關，具體業(yè)務操作间涵，Gateway 通過 Dubbo 提供的負載均衡機制自動完成榜揖。

Service：原子服務举哟，只提供該業(yè)務相關的原子服務妨猩。

Zookeeper：原子服務注冊到 ZK 上。

2.6.2 Spring Cloud

Spring Cloud組件運行：

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

網(wǎng)關接收到請求后牡属，從注冊中心（Eureka）獲取可用服務扼睬。

由 Ribbon 進行均衡負載后，分發(fā)到后端的具體實例特纤。

微服務之間通過 Feign 進行通信處理業(yè)務侥加。

2.6.3 點評

業(yè)務部署方式相同担败，都需要前置一個網(wǎng)關來隔絕外部直接調(diào)用原子服務的風險提前。

Dubbo 需要自己開發(fā)一套 API 網(wǎng)關，而 Spring Cloud 則可以通過 Zuul 配置即可完成網(wǎng)關定制宙搬。使用方式上 Spring Cloud 略勝一籌勇垛。

2.6.4 微服務架構組成以及注意事項

到底使用是 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)異常纵顾。

三施逾、總結

3.1 Dubbo 一些優(yōu)點

Dubbo 支持 RPC 調(diào)用汉额，服務之間的調(diào)用性能會很好榨汤。

支持多種序列化協(xié)議收壕，如 Hessian啼器、HTTP端壳、WebService。

Dobbo Admin后臺管理功能強大岖免，提供了路由規(guī)則颅湘、動態(tài)配置闯参、訪問控制鹿寨、權重調(diào)節(jié)薪夕、均衡負載等功能原献。

在國內(nèi)影響力比較大，中文社區(qū)文檔較為全面倔撞。

阿里最近重啟維護误窖。

3.2 Dubbo 一些問題

Registry 嚴重依賴第三方組件（zookeeper 或者 redis）霹俺，當這些組件出現(xiàn)問題時毒费，服務調(diào)用很快就會中斷觅玻。

Dubbo 只支持 RPC 調(diào)用溪厘。使得服務提供方（抽象接口）與調(diào)用方在代碼上產(chǎn)生了強依賴畸悬，服務提供者需要不斷將包含抽象接口的 jar 包打包出來供消費者使用。一旦打包出現(xiàn)問題蹋宦，就會導致服務調(diào)用出錯冷冗，并且以后發(fā)布部署會成很大問題（太強的依賴關系）蒿辙。

另外思灌，以后要兼容 .NET Core 服務习瑰，Dubbo RPC 本身不支持跨語言（可以用跨語言 RPC 框架解決甜奄，比如 Thrift课兄、gRPC（重復封裝了）烟阐，或者自己再包一層 REST 服務，提供跨平臺的服務調(diào)用實現(xiàn)唉擂，但相對麻煩很多）

Dubbo 只是實現(xiàn)了服務治理玩祟，其他微服務框架并未包含空扎，如果需要使用转锈，需要結合第三方框架實現(xiàn)（比如分布式配置用淘寶的 Diamond撮慨、服務跟蹤用京東的 Hydra甫煞，但使用相對麻煩些），開發(fā)成本較高抚吠，且風險較大楷力。

社區(qū)更新不及時（雖然最近在瘋狂更新）萧朝，但也難免阿里以后又不更新了检柬，就尷尬了竖配。

主要是國內(nèi)公司使用，但阿里內(nèi)部使用 HSF原押，相對于 Spring Cloud诸衔，企業(yè)應用會差一些笨农。

3.3 Spring Cloud 的一些優(yōu)點

有強大的 Spring 社區(qū)磁餐、Netflix 等公司支持诊霹，并且開源社區(qū)貢獻非称⒒梗活躍鄙漏。

標準化的將微服務的成熟產(chǎn)品和框架結合一起怔蚌，Spring Cloud 提供整套的微服務解決方案桦踊，開發(fā)成本較低籍胯，且風險較小杖狼。

基于 Spring Boot蝶涩，具有簡單配置、快速開發(fā)、輕松部署子寓、方便測試的特點暗挑。

支持 REST 服務調(diào)用，相比于 RPC斜友，更加輕量化和靈活（服務之間只依賴一紙契約，不存在代碼級別的強依賴）垃它，有利于跨語言服務的實現(xiàn)鲜屏，以及服務的發(fā)布部署国拇。另外洛史，結合 Swagger，也使得服務的文檔一體化酱吝。

提供了 Docker 及 Kubernetes 微服務編排支持也殖。

國內(nèi)外企業(yè)應用非常多，經(jīng)受了大公司的應用考驗（比如 Netfilx 公司）务热，以及強大的開源社區(qū)支持忆嗜。

3.4 Spring Cloud 的一些問題

支持 REST 服務調(diào)用，可能因為接口定義過輕崎岂，導致定義文檔與實際實現(xiàn)不一致導致服務集成時的問題（可以使用統(tǒng)一文檔和版本管理解決捆毫，比如 Swagger）。

另外冲甘，REST 服務調(diào)用性能會比 RPC 低一些（但也不是強綁定）

Spring Cloud 整合了大量組件绩卤，相關文檔比較復雜，需要針對性的進行閱讀江醇。

3.5 選型總結

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)微服務有效的工具餐济。

微服務架構是互聯(lián)網(wǎng)很熱門的話題，是互聯(lián)網(wǎng)技術發(fā)展的必然結果胆剧。它提倡將單一應用程序劃分成一組小的服務絮姆，服務之間互相協(xié)調(diào)、互相配合秩霍，為用戶提供最終價值篙悯。

---------------------

作者：有恒則成

來源：CSDN

原文：https://blog.csdn.net/hardworking0323/article/details/81170961

版權聲明：本文為博主原創(chuàng)文章，轉載請附上博文鏈接前域！

https://blog.csdn.net/hardworking0323/article/details/81170961#12-%E5%8F%AF%E7%8B%AC%E7%AB%8B%E9%83%A8%E7%BD%B2

兜兒邦項目搭建流程（簡要搭建）

1辕近、創(chuàng)建一個父項目：pcparent? (maven項目)，他的<parent>標簽設置如下：

打包方式：<packaging>pom</packaging>

注：maven有三種打包方式

如果想要其他項目依賴匿垄，打jar包

如果想要運行到服務器（例如tomcat）上移宅，打war包

如果想其他項目繼承,實現(xiàn)maven的聚合，打pom包

2.創(chuàng)建一個公共的module：pccommon椿疗，用來存放整個項目要用到的配置類漏峰，工具類等等，即所有項目都要用到的類集合在這個module中届榄，便于管理浅乔。這時將這個模塊打包成jar，同時pom.xml文件中<parent>標簽也要改變铝条。如下

3靖苇、創(chuàng)建一個聚集所有項目實體的module用來承載所有的映射類，取名entity,另外班缰，其<parent>標簽也要改變

4贤壁、maven中jar沖突的解決：（1）排除依賴（2）版本限定

這里采用版本限定。

在父項目的pom.xml中埠忘，先聲明版本號

然后進行版本限定：

限定完成后脾拆，將其他module中的<version>標簽刪除馒索。

5、每個module 都要在父項目的pom.xml中添加

6名船、搭建注冊中心pceureka：

yml文件的配置：

pom.xml<parent>標簽設置和上面的module一樣（注：所有子module<parent>標簽都一樣）绰上。

啟動類的配置：

至此，注冊中心搭建完畢渠驼。

7蜈块、服務提供者

首先服務提供者的pom.xml文件中，添加上common和entity的依賴（因為要用到）渴邦，如下：

然后就是<parent>標簽疯趟，和上面的設置一樣。

啟動類配置：

yml配置：

dao,controller,service 等自寫谋梭，可參考老師代碼。

8倦青、服務消費者

pom.xml文件配置：<parent>標簽設置和依賴的entity和common與提供者一樣瓮床。

yml文件配置 ：

啟動類：

其他層參考老師代碼。

這樣一個功能模塊的提供产镐，注冊隘庄，消費服務設計完畢。