小熊學(xué)Java：https://www.javaxiaobear.cn/，文末有免費(fèi)資源

本文我們來學(xué)習(xí)微服務(wù)的架構(gòu)設(shè)計

主要包括如下內(nèi)容。

• 單體系統(tǒng)的困難：編譯部署困難、數(shù)據(jù)庫連接耗盡、服務(wù)復(fù)用困難、新增業(yè)務(wù)困難。

• 微服務(wù)框架：Dubbo 和 Spring Cloud，微服務(wù)的架構(gòu)策略。

• 微服務(wù)模式：事件溯源、查詢與命令職責(zé)分離 CQRS、斷路器、超時。

• 微服務(wù)最佳實(shí)踐。

單體系統(tǒng)的困難

在微服務(wù)出現(xiàn)之前，互聯(lián)網(wǎng)應(yīng)用系統(tǒng)主要是單體系統(tǒng)，也就是說一個網(wǎng)站的整個系統(tǒng)由一個應(yīng)用構(gòu)成。如果是 Java，就打包成一個 war 包，一個 war 包包含整個應(yīng)用系統(tǒng)，系統(tǒng)更新的時候，即使只是更新其中極小的一部分，也要重新打包整個 war 包，發(fā)布整個系統(tǒng)。

這樣的單體系統(tǒng)面臨的挑戰(zhàn)主要是什么呢？

編譯、部署困難

隨著網(wǎng)站的業(yè)務(wù)不斷發(fā)展，系統(tǒng)會變得越來越龐大，最后變成一個巨無霸的系統(tǒng)。

   在我曾經(jīng)工作過的公司，單個應(yīng)用可能有幾個 G 大，這對于網(wǎng)站開發(fā)工程師來說，開發(fā)編譯和部署都是非常困難的。在開發(fā)的過程中，即使只改了龐大系統(tǒng)中的一行代碼，也必須把完整的網(wǎng)站系統(tǒng)重新打包，才能做測試。這會經(jīng)歷漫長的編譯過程：出去抽一支煙回來一看，在編譯；又去喝了一杯水回來，還在編譯；再去趟廁所，回來還在編譯。好不容易編譯結(jié)束了，如果某個配置項(xiàng)錯誤導(dǎo)致編譯失敗，又得重來一次，浪費(fèi)大半天的時間。這樣的單體系統(tǒng)對于開發(fā)部署和測試都是非常困難的。

代碼分支管理困難

因?yàn)閱误w應(yīng)用非常龐大，所以代碼模塊也是由多個團(tuán)隊(duì)共同維護(hù)的。但最后還是要編譯成一個單體應(yīng)用，統(tǒng)一發(fā)布。這就要求把各個團(tuán)隊(duì)的代碼 merge 在一起，這個過程很容易發(fā)生代碼沖突。而 merge 的時候又是網(wǎng)站要進(jìn)行發(fā)布的時候，發(fā)布過程本來就復(fù)雜，再加上代碼 merge 帶來的問題，各種情況糾纏在一起，極易出錯。所以，在單體應(yīng)用時代每一次網(wǎng)站發(fā)布都需要搞到深更半夜。

數(shù)據(jù)庫連接耗盡

對于一個巨型的應(yīng)用而言。因?yàn)橛写罅康挠脩暨M(jìn)行訪問，所以必須把應(yīng)用部署到大規(guī)模的服務(wù)器集群上。然后每個應(yīng)用都需要與數(shù)據(jù)庫建立連接，大量的應(yīng)用服務(wù)器連接到數(shù)據(jù)庫，會對數(shù)據(jù)庫的連接產(chǎn)生巨大的壓力，某些情況下甚至?xí)谋M數(shù)據(jù)庫的連接。

新增業(yè)務(wù)困難

巨無霸單體應(yīng)用的另一個挑戰(zhàn)是新增業(yè)務(wù)困難。因?yàn)樗械臉I(yè)務(wù)都耦合在一個單一的大系統(tǒng)里，通常隨著時間的發(fā)展，這個系統(tǒng)會變得非常的復(fù)雜，里面的各種結(jié)構(gòu)也非常亂，想要維護(hù)這樣一個系統(tǒng)是非常困難和復(fù)雜的。很多工程師入職公司半年，都還不能熟悉業(yè)務(wù)，因?yàn)闃I(yè)務(wù)太過龐大和復(fù)雜，經(jīng)常會出各種錯誤。所以就會出現(xiàn)這種現(xiàn)象：熟悉系統(tǒng)的老員們工忙得要死，加班加點(diǎn)干活，不熟悉系統(tǒng)的新員工們一幫忙就出亂，跟著加班加點(diǎn)干活。整個公司熱火朝天地干活，但最后還是常常出故障，新的功能遲遲不能上線。

發(fā)布困難

因?yàn)橐粋€ war 包包含了所有的代碼，進(jìn)行新版本發(fā)布的時候，發(fā)布代碼跟自己的開發(fā)的代碼一點(diǎn)關(guān)系沒有，但是因?yàn)?war 包包含了自己的代碼，為了以防萬一，也不得不跟著發(fā)布值班。結(jié)果真正更新代碼功能的只有幾個人，而整個部門都要跟著加班。常常出現(xiàn)，到了深夜，有代碼更新的同事汗流浹背進(jìn)行代碼沖突處理和修復(fù)發(fā)布 bug，沒有代碼更新的同事陪著聊天、打瞌睡、打游戲，這種情況。

微服務(wù)架構(gòu)

解決上述問題的主要手段是將一個單體的巨無霸系統(tǒng)，根據(jù)模塊以及復(fù)用的粒度進(jìn)行拆分，拆分成多個可以獨(dú)立部署的分布式服務(wù)。應(yīng)用通過遠(yuǎn)程訪問調(diào)用的方式，使用這些服務(wù)，構(gòu)成一個系統(tǒng)。但是由于它的核心服務(wù)是在其他的服務(wù)器上分布部署的，本身的業(yè)務(wù)邏輯可以變得比較簡單，這樣就把一個巨無霸系統(tǒng)單體應(yīng)用拆成了若干個可復(fù)用的服務(wù)，利用較少的邏輯代碼就可以組成一個應(yīng)用系統(tǒng)。

SOA 架構(gòu)

這樣的設(shè)計思路其實(shí)并不是在互聯(lián)網(wǎng)時代才出現(xiàn)的。在早期的時候，就有人提出了 SOA 面向服務(wù)的體系架構(gòu)。如下圖所示，在面向服務(wù)的體系架構(gòu)里面，服務(wù)的提供者向注冊中心注冊自己的服務(wù)，而服務(wù)的使用者向注冊中心去發(fā)現(xiàn)服務(wù)。發(fā)現(xiàn)服務(wù)以后，根據(jù)服務(wù)注冊中心提供的訪問接口和訪問路徑對服務(wù)發(fā)起請求，由服務(wù)的提供者完成請求返回結(jié)果給調(diào)用者。現(xiàn)在的微服務(wù)或者分布式服務(wù)，其實(shí)也是 SOA 架構(gòu)的一種實(shí)現(xiàn)。但是在早期的 SOA 架構(gòu)實(shí)踐中，服務(wù)的注冊與服務(wù)的調(diào)用都非常復(fù)雜，服務(wù)調(diào)用效率也比較低。

微服務(wù)架構(gòu)

后來在互聯(lián)網(wǎng)時代的微服務(wù)中，人們簡化了 SOA 架構(gòu)中的調(diào)用規(guī)范和服務(wù)規(guī)范，形成了我們現(xiàn)在所熟悉的分布式微服務(wù)架構(gòu)。

如下圖，所謂的微服務(wù)架構(gòu)就是將一個單體的巨無霸系統(tǒng)拆分成一組可復(fù)用的服務(wù)，基于這些服務(wù)構(gòu)成的應(yīng)用系統(tǒng)。圖中左邊是早期的單體應(yīng)用系統(tǒng)架構(gòu)，里面的各個模塊互相調(diào)用、耦合，所有的系統(tǒng)和模塊打包在一起，最后組成一個龐大的巨無霸系統(tǒng)。右邊是微服務(wù)架構(gòu)，根據(jù)服務(wù)的粒度和可復(fù)用的級別，對服務(wù)進(jìn)行拆分，以獨(dú)立部署服務(wù)的方式，對外提供服務(wù)調(diào)用。而應(yīng)用系統(tǒng)也按照用途和場景的不同，依賴這些可復(fù)用的服務(wù)，進(jìn)行邏輯組合，構(gòu)建成自己的業(yè)務(wù)系統(tǒng)。

通過這樣一種方式，系統(tǒng)變得比較簡單，復(fù)用級別也比較高，同時也解決了前面提出的單體巨無霸的幾個重要問題。因?yàn)槊恳粋€服務(wù)或是應(yīng)用系統(tǒng)，代碼都比較簡單，所以編譯和部署、開發(fā)和測試，都比較簡單和快速。而且這些服務(wù)都是獨(dú)立維護(hù)和部署的，它的代碼分支也是獨(dú)立的，不會和其他的代碼分支一起進(jìn)行管理，減少了代碼沖突的可能性。發(fā)布的時候，也是每個服務(wù)獨(dú)立發(fā)布，只要做好服務(wù)的版本控制和接口兼容，應(yīng)用系統(tǒng)不需要跟隨服務(wù)一起更新發(fā)布。

在微服務(wù)體系中，連接數(shù)據(jù)庫的是具體的服務(wù)，應(yīng)用系統(tǒng)不需要自己去連接數(shù)據(jù)庫，只需要調(diào)用組合服務(wù)，對服務(wù)進(jìn)行編排。所以對數(shù)據(jù)庫的連接也相對比以前更少一些。最主要的是當(dāng)需要開發(fā)新業(yè)務(wù)的時候，使用這種方式不需要對原有的單體系統(tǒng)進(jìn)行各種重構(gòu)和代碼修改，只需要開發(fā)一個新的業(yè)務(wù)系統(tǒng)，組合調(diào)用現(xiàn)有的微服務(wù)，就可以組合出來一個新的產(chǎn)品功能，可以快速開發(fā)新產(chǎn)品。

Dubbo

目前一些典型的微服務(wù)框架本身的架構(gòu)是如何設(shè)計的？

先看 Dubbo 架構(gòu)。Dubbo 是阿里開源的，比較早也比較有影響力的一個分布式微服務(wù)框架。如下圖所示，在 Dubbo 架構(gòu)中，最核心的模塊有 3 個部分，一個是服務(wù)的提供者，一個是服務(wù)的消費(fèi)者，還有一個是服務(wù)的注冊中心。

服務(wù)的提供者顧名思義就是微服務(wù)的具體提供者，通過微服務(wù)容器對外提供服務(wù)。而服務(wù)的消費(fèi)者就是應(yīng)用系統(tǒng)或是其他的微服務(wù)。

應(yīng)用系統(tǒng)通過組合多個微服務(wù)，構(gòu)成自己的業(yè)務(wù)邏輯，實(shí)現(xiàn)自己的產(chǎn)品功能。具體過程是服務(wù)的提供者程序在 Dubbo 的服務(wù)容器中啟動，服務(wù)管理容器向服務(wù)注冊中心進(jìn)行注冊，聲明服務(wù)提供者所要提供的接口參數(shù)和規(guī)范，并且注冊自己所在服務(wù)器的 IP 地址和端口，如下圖所示。

而服務(wù)的消費(fèi)者如果想要調(diào)用某個服務(wù)，只需依賴服務(wù)提供者的接口進(jìn)行編程。而服務(wù)接口通過 Dubbo 框架的代理訪問機(jī)制，調(diào)用 Dubbo 的服務(wù)框架客戶端，服務(wù)框架客戶端會根據(jù)服務(wù)接口聲明，去注冊中心查找對應(yīng)的服務(wù)提供者啟動在哪些服務(wù)器上，并且將這個服務(wù)器列表返回給客戶端。客戶端根據(jù)某種負(fù)載均衡策略，選擇某一個服務(wù)器通過遠(yuǎn)程通訊模塊發(fā)送具體的服務(wù)調(diào)用請求。

服務(wù)調(diào)用請求，通過 Dubbo 底層自己的遠(yuǎn)程通訊模塊，也就是 RPC 調(diào)用方式，將請求發(fā)送到服務(wù)的提供者服務(wù)器，服務(wù)提供者服務(wù)器收到請求以后，將該請求發(fā)送給服務(wù)提供者程序，完成服務(wù)的執(zhí)行，并將服務(wù)執(zhí)行處理結(jié)果通過遠(yuǎn)程調(diào)用通訊模塊 RPC 返回給服務(wù)消費(fèi)者客戶端，服務(wù)消費(fèi)者客戶端將結(jié)果返回給服務(wù)調(diào)用程序，從而完成遠(yuǎn)程服務(wù)的調(diào)用，獲得服務(wù)處理的結(jié)果。

Dubbo 使用 Java 進(jìn)行開發(fā)，并且通過服務(wù)接口的方式對消費(fèi)者提供服務(wù)，所以它的服務(wù)調(diào)用方式比較簡單，可以透明地進(jìn)行遠(yuǎn)程微服務(wù)調(diào)用。服務(wù)消費(fèi)者程序，可以無感知地進(jìn)行遠(yuǎn)程微服務(wù)調(diào)用，對開發(fā)者相對比較友好。

Spring Cloud

另一種目前比較熱門的微服務(wù)框架是 Spring Cloud。Spring Cloud 微服務(wù)框架組件跟 Dubbo 類似，也是由服務(wù)的消費(fèi)者、服務(wù)的提供者和注冊中心組成。如下圖所示，Spring cloud 的服務(wù)提供者通過 Spring Boot 啟動，然后向服務(wù)注冊中心 Eureka Server 進(jìn)行注冊，而服務(wù)的消費(fèi)者通過一個 Zuul 網(wǎng)關(guān)訪問 Eureka Server 進(jìn)行服務(wù)的發(fā)現(xiàn)，獲得自己想要調(diào)用的遠(yuǎn)程服務(wù)對應(yīng)的服務(wù)地址。獲得地址以后，通過 HTTP 的方式向遠(yuǎn)程的服務(wù)提供者發(fā)起調(diào)用請求。服務(wù)提供者完成服務(wù)處理后，將處理結(jié)果通過 HTTP 返回。從而實(shí)現(xiàn)了遠(yuǎn)程的微服務(wù)調(diào)用。

Spring Cloud 還包含了一組服務(wù)調(diào)用監(jiān)控組件，主要是 Hystrix，通過 Hystrix 可以監(jiān)控服務(wù)調(diào)用，還在此基礎(chǔ)上實(shí)現(xiàn)了熔斷、降級、超時管理等一系列高可用策略。

微服務(wù)架構(gòu)策略

對微服務(wù)架構(gòu)而言，技術(shù)現(xiàn)在其實(shí)比較成熟。使用什么樣的技術(shù)去實(shí)現(xiàn)一個微服務(wù)，本身并沒有太多的困難。構(gòu)建一個微服務(wù)架構(gòu)最困難的還是服務(wù)治理，也就是業(yè)務(wù)劃分。策略要點(diǎn)如圖所示。

一個微服務(wù)包含的功能有哪些？服務(wù)的邊界是什么？服務(wù)之間的依賴關(guān)系如何？這些關(guān)鍵的問題決定了服務(wù)的復(fù)用程度，維護(hù)的難易程度，開發(fā)的便利程度。所以設(shè)計微服務(wù)架構(gòu)的時候，首先要關(guān)注的是業(yè)務(wù)，業(yè)務(wù)要先行，理順業(yè)務(wù)模塊之間的邊界和依賴，做好服務(wù)治理和調(diào)用依賴管理。

微服務(wù)技術(shù)是微服務(wù)架構(gòu)的手段，而不是目的。微服務(wù)最主要的目的還是實(shí)現(xiàn)服務(wù)治理——如何劃分和管理服務(wù)。首先要有獨(dú)立的功能模塊，然后才有分布式的服務(wù)。也就是說在軟件設(shè)計的時候，軟件功能模塊之間的依賴關(guān)系就要清晰、合理、規(guī)范、便于維護(hù)、便于擴(kuò)展，便于實(shí)現(xiàn)新的功能。服務(wù)之間的依賴關(guān)系要清晰、參數(shù)要簡單、耦合關(guān)系要少。設(shè)計好這樣的模塊化結(jié)構(gòu)以后，將這些設(shè)計好的模塊，拆分成獨(dú)立的微服務(wù)進(jìn)行部署和調(diào)用，就可以構(gòu)建一個良好的微服務(wù)系統(tǒng)。如果模塊本身就是混亂的、耦合嚴(yán)重的、邊界不清晰的、關(guān)系復(fù)雜的，那么，把它們拆分成獨(dú)立的微服務(wù)進(jìn)行部署，只會使事情變得更加復(fù)雜。

所以進(jìn)行微服務(wù)架構(gòu)設(shè)計之初，就要先做好業(yè)務(wù)模塊的設(shè)計和規(guī)劃。同時，對于那些業(yè)務(wù)耦合比較嚴(yán)重、邏輯復(fù)雜多變的系統(tǒng)，進(jìn)行微服務(wù)重構(gòu)的時候，也要特別謹(jǐn)慎。如果做不好模塊的劃分和耦合管理。那么，寧可晚一點(diǎn)進(jìn)行微服務(wù)架構(gòu)重構(gòu)，也不要倉促上馬，以免最后帶來巨大的損失。要使用微服務(wù)架構(gòu)的時候，一定要搞清楚實(shí)施微服務(wù)的目的究竟是什么，是為了業(yè)務(wù)復(fù)用，是為了開發(fā)邊界清晰，是為了分布式集群提升性能，還是僅僅想要使用微服務(wù)？目的一定要清楚。

跟其他技術(shù)不同，微服務(wù)具有強(qiáng)業(yè)務(wù)屬性，業(yè)務(wù)如果本身結(jié)構(gòu)混亂，目標(biāo)不清晰，倉促使用微服務(wù)，可能會使整個系統(tǒng)變得更加復(fù)雜和難以控制。所以在使用微服務(wù)前，最重要的是要先明確自己的需求：我們到底想用微服務(wù)達(dá)到什么樣的目的？需求清晰了，再去考慮具體的方案和技術(shù)。這也是使用大多數(shù)技術(shù)的時候應(yīng)有的方法和思路。

如下圖所示，最重要的是需求。在日常工作中，我們要根據(jù)需求去考慮具體的價值，再根據(jù)價值構(gòu)建我們的設(shè)計原則，根據(jù)原則尋找最佳實(shí)踐，最后根據(jù)實(shí)踐去選擇最合適的工具。按這樣的方式去選擇技術(shù)做架構(gòu)設(shè)計才是比較成熟和高效的。如果相反，先找到一個工具，然后用工具硬往上套需求，只會導(dǎo)致技術(shù)也沒用好，業(yè)務(wù)也沒做好，所有人都疲憊不堪，事情變得一團(tuán)糟，最后還可能反過來怪技術(shù)沒用。

微服務(wù)的使用模式

下面來看可供參考的幾種微服務(wù)的使用模式。

事件溯源

第一是事件溯源，因?yàn)槲⒎?wù)的調(diào)用過程會比較復(fù)雜，調(diào)用鏈路可能會比較長。如果某個微服務(wù)調(diào)用出錯，如何進(jìn)行管理和監(jiān)控？使用事件溯源這種模式是一種解決辦法。

所謂的事件溯源是指將用戶的請求處理過程，每一次的狀態(tài)變化都記錄到事件日志中，并按照時間序列進(jìn)行持久化的存儲，也就是說，把所有的變更操作都按日志的方式，按時間化序列進(jìn)行記錄。

使用事件溯源的好處有如下兩點(diǎn)。

• 可以精確地復(fù)現(xiàn)用戶的狀態(tài)變化。

用戶執(zhí)行了哪些操作，使它成為現(xiàn)在這樣一種狀況，然后通過事件溯源的方式，追溯以往的操作和動作，從而進(jìn)行復(fù)核和審計。當(dāng)用戶投訴的時候，當(dāng)狀態(tài)不一致的時候，可以通過事件溯源中的日志進(jìn)行審計和查找。

• 可以有效監(jiān)控用戶的狀態(tài)變化，并在此基礎(chǔ)上實(shí)現(xiàn)分布式的事務(wù)。

我們傳統(tǒng)的事務(wù)使用數(shù)據(jù)庫事務(wù)進(jìn)行實(shí)現(xiàn)，可以將多個數(shù)據(jù)庫操作統(tǒng)一提交，或者統(tǒng)一回滾，保持?jǐn)?shù)據(jù)的一致性，但是在分布式狀況下，對數(shù)據(jù)的操作是分布在多個獨(dú)立部署的服務(wù)進(jìn)行處理。這個時候就無法使用數(shù)據(jù)庫的事務(wù)進(jìn)行管理。

那么，如何在這種情況下實(shí)行分布式系統(tǒng)的事務(wù)？

事件溯源是一種辦法。因?yàn)槭录菰磳⑺械臄?shù)據(jù)變更都按日志的方式記錄起來，所以如果日志不完整，我們就知道事務(wù)不完整，可以對事務(wù)進(jìn)行重組或者補(bǔ)償操作，從而使數(shù)據(jù)變得一致。

命令與查詢職責(zé)隔離（CQRS）

這種模式在服務(wù)接口層面將查詢操作（也就是讀操作）和命令操作（也就是寫操作）隔離開來，在服務(wù)層實(shí)現(xiàn)讀寫分離。

使用 CQRS 模式，主要的好處是可以有更清晰的領(lǐng)域模型，根據(jù)操作的方式不同，使用不同的領(lǐng)域模型。還可以分別進(jìn)行讀寫優(yōu)化，從而實(shí)現(xiàn)更好的性能。

我們知道在讀操作中主要使用的優(yōu)化方式是緩存操作。那么，我們可以將接口層面的查詢操作即讀操作，盡量多地通過緩存來返回。而寫操作也就是命令操作，主要的性能優(yōu)化方式是使用消息隊(duì)列。那么，我們可以將數(shù)據(jù)的更新操作，盡量通過消息隊(duì)列，通過異步化的方式進(jìn)行處理，以改善性能。

因?yàn)槭褂?CQRS 查詢和命令分離的方式，我們可以在接口層面上使用不同的優(yōu)化手段。查詢操作不會修改數(shù)據(jù)庫，那么所有來自于查詢接口的服務(wù)，可以統(tǒng)一連接到只讀數(shù)據(jù)庫中，防止誤操作破壞數(shù)據(jù)，可以更好地保護(hù)數(shù)據(jù)，同時使用 CQRS，還可以更好地實(shí)現(xiàn)剛才的事件溯源機(jī)制。因?yàn)椴樵儾僮魇菬o須進(jìn)行事件溯源的，所有的事件溯源都可以統(tǒng)一設(shè)置在命令服務(wù)接口上。

斷路器

使用微服務(wù)的時候，你還需要關(guān)注一個事情：服務(wù)的不可用。

當(dāng)某個服務(wù)實(shí)例出現(xiàn)故障的時候，它的響應(yīng)延遲或者失敗率增加的時候，繼續(xù)調(diào)用這個服務(wù)實(shí)例會導(dǎo)致請求者阻塞。請求阻塞以后會導(dǎo)致資源消耗增加，最后可能會導(dǎo)致請求者也失敗和崩潰，進(jìn)而出現(xiàn)服務(wù)的級聯(lián)崩潰，也就是服務(wù)請求者的請求者也失敗，最后會導(dǎo)致整個系統(tǒng)全部失敗，即雪崩現(xiàn)象。

在這種情況下，可以使用斷路器對故障服務(wù)進(jìn)行隔離。斷路器有三種狀態(tài)：關(guān)閉、打開、半開。當(dāng)服務(wù)出現(xiàn)故障的時候，通過斷路器阻斷對故障服務(wù)實(shí)例的調(diào)用，避免它的故障擴(kuò)散開來。在 Spring Cloud 中可以使用 Hystrix 實(shí)現(xiàn)斷路器。

超時

還有一件需要關(guān)注的事情是：微服務(wù)調(diào)用的超時機(jī)制如何設(shè)置。

如果使用統(tǒng)一的超時設(shè)置，那么當(dāng)下游調(diào)用者超時的時候，上游調(diào)用者一定也已經(jīng)超時了，因?yàn)榉?wù)調(diào)用是阻塞的。所以，下游調(diào)用的超時一定會反應(yīng)在上游調(diào)用者上。因此在設(shè)置超時的時候，要設(shè)置上游調(diào)用者的超時時間大于下游調(diào)用者的超時時間之和，相同的超時設(shè)置是沒有意義的，如下圖所示。

總結(jié)回顧

首先，之所以要使用微服務(wù)，是因?yàn)閭鹘y(tǒng)的單體巨無霸系統(tǒng)帶來的挑戰(zhàn)和困難，包括編譯和部署的困難、連接的困難、打包代碼沖突的困難，以及復(fù)用的困難、新增業(yè)務(wù)的困難。

而具體的微服務(wù)框架基本上都是由三個核心部分組成的：服務(wù)的提供者、服務(wù)的調(diào)用者和服務(wù)的注冊中心。服務(wù)的提供者向注冊中心注冊自己的服務(wù)，而服務(wù)的調(diào)用者通過注冊中心發(fā)現(xiàn)服務(wù)，并進(jìn)行遠(yuǎn)程調(diào)用。

另外，很多微服務(wù)架構(gòu)中還包括一個監(jiān)控者的角色，通過監(jiān)控者進(jìn)行服務(wù)的管理和流量的控制。

使用微服務(wù)最重要的是做好業(yè)務(wù)的模塊化設(shè)計，模塊之間要低耦合，高聚合，模塊之間的依賴關(guān)系要清晰簡單。只有這樣的模塊化設(shè)計，才能夠構(gòu)建出良好的微服務(wù)架構(gòu)。如果系統(tǒng)本身就是一團(tuán)遭，強(qiáng)行將它們拆分在不同的微服務(wù)里，只會使系統(tǒng)變得更加混亂。

使用微服務(wù)的時候，有幾個重要的使用模式，需要關(guān)注：一個是事件溯源，一個是命令與查詢隔離，還有一個是斷路器以及關(guān)于超時如何進(jìn)行設(shè)置。

福利資源

海量數(shù)據(jù)高并發(fā)場景，構(gòu)建Go+ES8企業(yè)級搜索微服務(wù)：https://www.aliyundrive.com/s/ib2BeM5W3Du