大家好，我是小羽。

最近有很多粉絲私信：羽哥，羽哥！是不是失蹤啦？好幾個月沒更新了！

過氣博主表示，工作也比較忙，加之自己搬家（沒有叫貨拉拉，懂的都懂，手動狗頭）的原因，更文就落下了。現在終於把這些事情都處理完了，有充足的時間來更新博文了。放心，落下的遲早都該補回來的，這不已經開始準備上了嘛～先給大家看看收拾好的小窩：

​

帥羽的小窩

之前的一篇文章給大家介紹過了何為微服務：圖文詳解：如何給女朋友解釋什麼是微服務？但是身為一名積極好學的前端女朋友還是會經常問我，微服務那麼多理念，你跟我講完，我就忘了，可以再給我講講它的思想到底是啷個回事嘛～看在她這麼刻苦奮進的情況下，加之我們公司也做了許多微服務的專案，對此還算有所研究。今天就繼續為大家帶來深層次的關於微服務架構的講解：

在學習微服務之前，我們先來回顧下單體架構的模式。

單體架構

概念

單體架構也稱之為單體系統或者是單體應用。就是一種把系統中所有的功能、模組耦合在一個應用中的架構方式。

特點

單體架構的特點主要有：

1. 打包成一個獨立的單元(導成一個唯一的jar包或者是war包)

2. 以一個程序的方式來執行

​

單體架構

優點

易於開發： 開發方式簡單，IDE 支援好，方便執行和除錯。

易於測試： 所有功能執行在一個程序中，一旦程序啟動，便可以進行系統測試。

易於部署： 只需要將打好的一個軟體包釋出到伺服器即可。

易於水平伸縮： 只需要建立一個伺服器節點，配置好執行時環境，再將軟體包釋出到新伺服器節點即可執行程式（當然也需要採取分發策略保證請求能有效地分發到新節點）。

缺點

維護成本大： 當應用程式的功能越來越多、團隊越來越大時，溝通成本、管理成本顯著增加；當出現 bug 時，可能引起 bug 的原因組合越來越多，導致分析、定位和修復的成本增加；並且在對全域性功能缺乏深度理解的情況下，容易在修復 bug 時引入新的 bug。

持續交付週期長： 構建和部署時間會隨著功能的增多而增加，任何細微的修改都會觸發部署流水線。

新人培養週期長： 新成員瞭解背景、熟悉業務和配置環境的時間越來越長。

技術選型成本高： 單塊架構傾向於採用統一的技術平臺或方案來解決所有問題，如果後續想引入新的技術或框架，成本和風險都很大。

可擴充套件性差： 隨著功能的增加，垂直擴充套件的成本將會越來越大；而對於水平擴充套件而言，因為所有程式碼都執行在同一個程序，沒辦法做到針對應用程式的部分功能做獨立的擴充套件

採用過時的單體架構的話，就會使得公司僱傭有潛力的開發者很困難，應用無法擴充套件，可靠性很低，那麼我們再來看看微服務架構是怎樣的呢？

微服務架構

概念

微服務是一種架構風格。一個大型的複雜軟體應用，由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是鬆耦合的。每個微服務僅關注於完成一件任務並且能夠很好的完成該任務。

​

架構核心

核心部分

閘道器叢集：資料的聚合、實現對接入客戶端的身份認證、防報文重放與防資料篡改、功能呼叫的業務鑑權、響應資料的脫敏、流量與併發控制等。

業務叢集：一般情況下移動端訪問和瀏覽器訪問的閘道器需要隔離，防止業務耦合。

Local Cache：由於客戶端訪問業務可能需要呼叫多個服務聚合，所以本地快取有效的降低了服務呼叫的頻次，同時也提示了訪問速度。本地快取一般使用自動過期方式，業務場景中允許有一定的資料延時。

服務層：原子服務層，實現基礎的增刪改查功能，如果需要依賴其他服務需要在 Service 層主動呼叫。

Remote Cache：訪問 DB 前置一層分散式快取，減少 DB 互動次數，提升系統的TPS。

DAL：資料訪問層，如果單表資料量過大則需要通過 DAL 層做資料的分庫分表處理。

MQ：訊息佇列用來解耦服務之間的依賴，非同步呼叫可以通過 MQ 的方式來執行。

資料庫主從：服務化過程中必經的階段，用來提升系統的 TPS

架構

常見的架構有：

1. 客戶端與服務端的

2. 基於元件模型的架構（EJB）

3. 分層架構(MVC)

4. 面向服務架構(SOA)

特點

1. 系統是由多個服務構成

2. 每個服務可以單獨獨立部署

3. 每個服務之間是鬆耦合的。服務內部是高內聚的，外部是低耦合的。高內聚就是每個服務只關注完成一個功能。

優點

邊界清晰：比如說一個電商平臺，我們以前是部署在一臺伺服器上，所有的程式碼打成一個war包。現在，我們可以給它拆分開：使用者服務，積分服務，支付服務，倉儲服務，資訊服務，地圖服務等等，每一個微服務只關注一個特定的業務功能，這樣的話開發和維護單個服務都比較簡單，因為它的邊界足夠清晰，業務也足夠清晰，使用者服務，只做好使用者的事情就好了，相較於之前的大而全的單體服而言，每個微服務的程式碼量也比較少。

效率高：單體服務隨著程式碼量變得越來越多，比如說百萬行級別的程式碼，僅僅編譯一次應用可能就需要花費很久，但是現在，如果一個地方有問題，比如說支付模組有問題，只需要單獨修改支付模組，修改完支付模組之後，單獨測試支付功能，單獨部署支付模組就可以了，而不會影響整體的部署速度。

技術棧不受限制：每一個服務可以使用不同的技術棧來實現，由於不同的服務之間是通過restful API來通訊的，所以每個服務可以使用不同的技術框架，使用不同的儲存庫來實現;

拓展性更強：隨著業務的發展，使用者量變得越來越多，或者說訂單量猛增，這時我們可以專門去優化這個訂單服務，給這個訂單服務提供更高配置的機器，而其他並沒有遇到瓶頸的業務，比如說簡訊服務，我們可以暫時不用動。

缺點

運維成本過高：以前只需要打個 war 包扔在 tomcat 下面就可以了，但現在，我們可能需要部署幾個甚至幾十個微服務，這樣的話，如何保證這幾十甚至上百個微服務正常的執行和互相通訊協作，這給運維帶來了很大的挑戰；

分散式系統複雜：使用微服務這種架構，構建的是一個分散式的系統，在分散式系統當中會引入很多問題，比如說分散式鎖，分散式事務等等，這個時候我們需要對這個系統的，事務，冪等，網路延遲，分割槽，熔斷，降級等問題都要有一個妥善的處理和應對方案；

通訊成本高：由於之前的介面呼叫都在同一個程序內，我需要支付呼叫支付方法，需要積分直接呼叫新增積分的方法，但現在，由於積分模組或者支付模組都被拆成了單獨的服務，這個時候如果再想去呼叫的話，就是通過http方式的請求去呼叫，這種頻繁的跨服務通訊是有很高的成本的，選擇一個適合自己業務的輕量級低成本的通訊方式，也很關鍵。

服務拆分難：如何做好微服務的拆分？這個是需要我們不斷摸索的，從單體服務向微服務架構的演進，它是一個循序漸進的過程，在演進的過程中常常會根據業務變化來對微服務進行重構，甚至是重新劃分，從而讓這個架構更加合理。

架構區別

MVC 架構

MVC 架構就是一個單體架構。我們常使用的技術：Struts2、SpringMVC、Spring、Mybatis等等。

RPC 架構

RPC(RemoteProcedureCall)：遠端過程呼叫。他一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。我們常使用的技術：Thrift、Hessian等等

實現原理：首先需要有處理網路連線通訊的模組，負責連線建立、管理和訊息的傳輸。其次需要有編解碼的模組，因為網路通訊都是傳輸的位元組碼，需要將我們使用的物件序列化和反序列化。剩下的就是客戶端和伺服器端的部分，伺服器端暴露要開放的服務介面，客戶呼叫服務介面的一個代理實現，這個代理實現負責收集資料、編碼並傳輸給伺服器然後等待結果返回。

SOA 架構

SOA(ServiceorientedArchitecture):面向服務架構

ESB(EnterpariseServceBus):企業服務匯流排，服務中介。主要是提供了一個服務於服務之間的互動。ESB 包含的功能如：負載均衡，流量控制，加密處理，服務的監控，異常處理，監控告急等等。我們常使用的技術：Mule、WSO2

微服務架構

微服務就是一個輕量級的服務治理方案。我們常使用的技術：SpringCloud、dubbo等等。

​

架構區別

微服務原則

AKF拆分原則

業界對於可擴充套件的系統架構設計有一個樸素的理念,就是：通過加機器就可以解決容量和可用性問題。

這一理念在“雲端計算”概念瘋狂流行的今天，得到了廣泛的認可！對於一個規模迅速增長的系統而言，容量和效能問題當然是首當其衝的。但是隨著時間的向前，系統規模的增長，除了面對效能與容量的問題外，還需要面對功能與模組數量上的增長帶來的系統複雜性問題以及業務的變化帶來的提供差異化服務問題。而許多系統，在架構設計時並未充分考慮到這些問題，導致系統的重構成為常態，從而影響業務交付能力，還浪費人力財力！對此，《可擴充套件的藝術》一書提出了一個更加系統的可擴充套件模型——AKF 可擴充套件立方（ScalabilityCube）。這個立方體中沿著三個座標軸設定分別為：X、Y、Z。

Y 軸(功能)——關注應用中功能劃分，基於不同的業務拆分

Y 軸擴充套件會將龐大的整體應用拆分為多個服務。每個服務實現一組相關的功能，如訂單管理、客戶管理等。在工程上常見的方案是服務化架構(SOA)。比如對於一個電子商務平臺，我們可以拆分成不同的服務，組成下面這樣的架構：

​

服務化架構 SOA

但通過觀察上圖容易發現，當服務數量增多時，服務呼叫關係變得複雜。為系統新增一個新功能，要呼叫的服務數也變得不可控，由此引發了服務管理上的混亂。所以，一般情況下，需要採用服務註冊的機制形成服務閘道器來進行服務治理。系統的架構將變成下圖所示：

​

服務閘道器治理

X 軸(水平擴充套件)——關注水平擴充套件，也就是”加機器解決問題”

X 軸擴充套件與我們前面樸素理念是一致的，通過絕對平等地複製服務與資料，以解決容量和可用性的問題。其實就是將微服務執行多個例項，做叢集加負載均衡的模式。為了提升單個服務的可用性和容量，對每一個服務進行X軸擴充套件劃分。

​

X 軸（水平擴充套件）

Z 軸(資料分割槽)——關注服務和資料的優先順序劃分，如按地域劃分

Z 軸擴充套件通常是指基於請求者或使用者獨特的需求，進行系統劃分，並使得劃分出來的子系統是相互隔離但又是完整的。工程領域常見的Z軸擴充套件有以下兩種方案：

單元化架構：在分散式服務設計領域，一個單元（Cell）就是滿足某個分割槽所有業務操作的自包含閉環。如上面我們說到的Y軸擴充套件的SOA架構，客戶端對服務端節點的選擇一般是隨機的，但是，如果在此加上Z軸擴充套件，那服務節點的選擇將不再是隨機的了，而是每個單元自成一體。如下圖：

​

PC 使用者

​

移動端使用者

資料分割槽：為了效能資料安全上的考慮，我們將一個完整的資料集按一定的維度劃分出不同的子集。一個分割槽（Shard），就是是整體資料集的一個子集。比如用尾號來劃分使用者，那同樣尾號的那部分使用者就可以認為是一個分割槽。資料分割槽為一般包括以下幾種資料劃分的方式：

資料型別 如：業務型別

資料範圍 如：時間段，使用者ID

資料熱度 如：使用者活躍度，商品熱度

按讀寫分 如：商品描述，商品庫存

前後端分離原則

何為前後端分離？前後端本來不就分離麼？這要從尷尬的jsp講起。分工精細化從來都是蛋糕做大的原則，多個領域工程師最好在不需要接觸其他領域知識的情況下合作，才可能使效率越來越高，維護也會變得簡單。jsp 的模板技術融合了 html 和 java 程式碼，使得傳統 MVC 開發中的前後端在這裡如膠似漆，前端做好頁面，後端轉成模板，發現問題再找前端，前端又看不懂 java 程式碼……前後端分離的目的就是將這尷尬局面打破。

​

前後端分離

前後端分離原則，簡單來講就是前端和後端的程式碼分離，我們推薦的模式是最好採用物理分離的方式部署，進一步促使更徹底的分離。如果繼續直接使用服務端模板技術，如：jsp，把 java、js、html、css 都堆到一個頁面裡，稍微複雜一點的頁面就無法維護了。

​

分離原則

這種分離方式有幾個好處：

1. 前後端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的使用者體驗優化效果更好。

2. 分離模式下，前後端互動介面更清晰，就剩下了介面模型，後端的介面簡潔明瞭，更容易維護。

3. 前端多渠道整合場景更容易實現，後端服務無需變更，採用統一的資料和模型，可以支援多個前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端

無狀態服務

對於無狀態服務，首先說一下什麼是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那麼這個資料被稱為狀態。進而依賴這個“狀態”資料的服務被稱為有狀態服務，反之稱為無狀態服務。

​

無狀態服務

那麼這個無狀態服務原則並不是說在微服務架構裡就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那麼狀態資料也就相應的遷移到對應的“有狀態資料服務”中。

場景說明：例如我們以前在本地記憶體中建立的資料快取、Session 快取，到現在的微服務架構中就應該把這些資料遷移到分散式快取中儲存，讓業務服務變成一個無狀態的計算節點。遷移後，就可以做到按需動態伸縮，微服務應用在執行時動態增刪節點，就不再需要考慮快取資料如何同步的問題。

RestFul 的通訊風格

原則來講本來應該是個“無狀態通訊原則”

​

無狀態通訊

在這裡我們直接推薦一個實踐優選的 Restful 通訊風格，因為他有很多好處：

1. 無狀態協議 HTTP，具備先天優勢，擴充套件能力很強。例如需要安全加密，有現成的成熟方案HTTPS即可。

2. JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜尋引擎友好。

3. 語言無關，各大熱門語言都提供成熟的 RestfulAPI 框架，相對其他的一些 RPC 框架生態更完善。

通訊

服務通訊

WebService、WCF、WebAPI，以及 ASHX,ASPX。

• 主動觸發

• 資料序列化傳遞

• 跨平臺。

• 跨語言

• Http 穿透防火牆。

程序通訊

• Net Remoting：Net 平臺督郵的，不支援跨平臺。

• gRPC：高效能、開源和通用 RPC框架，面向服務端和移動端，基於 HTTP/2 設計，推薦使用。

​

WebService

註冊中心 Eureka

註冊中心主要提供三個核心功能：

1. 服務註冊

服務提供者啟動時，會通過 Eureka Client 向 Eureka Server 註冊資訊，Eureka Server 會儲存該服務的資訊，Eureka Server 內部有二層快取機制來維護整個登錄檔

2. 提供登錄檔

服務消費者在呼叫服務時，如果 Eureka Client 沒有快取登錄檔的話，會從 Eureka Server 獲取最新的登錄檔

3. 同步狀態

Eureka Client 通過註冊、心跳機制和 Eureka Server 同步當前客戶端的狀態。

​

Eureka 流程

閘道器 Zuul

API 閘道器是一個更為智慧的應用伺服器，它的存在就像是整個微服務架構系統的門面，所有的外部客戶端訪問都需要經過它來進行排程和過濾。除了需要實現請求路由，負載均衡及校驗過濾等功能外還需要與服務治理框架的結合，請求轉發時的熔斷機制，服務的聚合等一系列高階功能。主要核心功能：

• 服務路由轉發

• 鑑權校驗過濾

• 熔斷限制保護

​

閘道器

認證&授權

現在的應用開發層出不窮，基於瀏覽器的網頁應用，基於微信的公眾號、小程式，基於 IOS、Android 的 App，基於 Windows 系統的桌面應用和 UWP 應用等等，這麼多種類的應用，就給應用的開發帶來的挑戰，我們除了分別實現各個應用外，我們還要考慮各個應用之間的互動，通用模組的提煉，其中身份的認證和授權就是每個應用必不可少的的一部分。而現在的網際網路，對於資訊保安要求又十分苛刻，所以一套統一的身份認證和授權就至關重要。

IdentityServer4 就是這樣一個框架，IdentityServer4 是為 ASP.NET CORE 量身定製的實現了 OpenId Connect 和 OAuth2.0 協議的認證授權中介軟體。

​

IdentityServer4

分散式日誌

一般我們需要進行日誌分析場景：直接在日誌檔案中 grep、awk 就可以獲得自己想要的資訊。但在規模較大也就是日誌量多而複雜的場景中，此方法效率低下，面臨問題包括日誌量太大如何歸檔、文字搜尋太慢怎麼辦、如何多維度查詢。需要集中化的日誌管理，所有伺服器上的日誌收集彙總。常見解決思路是建立集中式日誌收集系統，將所有節點上的日誌統一收集，管理，訪問。

大型系統通常都是一個分散式部署的架構，不同的服務模組部署在不同的伺服器上，問題出現時，大部分情況需要根據問題暴露的關鍵資訊，定位到具體的伺服器和服務模組，構建一套集中式日誌系統，可以提高定位問題的效率。

Exceptionless 是一個開源的實時的日誌收集框架，它可以應用在基於 ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC 等技術棧的應用程式中，並且提供了 Rest 介面可以應用在 Javascript，Node.js 中。它將日誌收集變得簡單易用並且不需要了解太多的相關技術細節及配置。在以前，我們做日誌收集大多使用 Log4net，Nlog 等框架，在應用程式變得複雜並且叢集的時候，可能傳統的方式已經不是很好的適用了，因為收集各個日誌並且分析他們將變得麻煩而且浪費時間。

現在 Exceptionless 團隊給我們提供了一個更好的框架來做這件事情，我認為這是非常偉大並且有意義的，感謝他們。

ELK是三個開源軟體的縮寫，分別為：Elasticsearch 、 Logstash 以及 Kibana , 它們都是開源軟體。不過現在還新增了一個 Beats，它是一個輕量級的日誌收集處理工具(Agent)，Beats 佔用資源少，適合於在各個伺服器上搜集日誌後傳輸給 Logstash，官方也推薦此工具，目前由於原本的 ELK Stack 成員中加入了 Beats 工具所以已改名為 Elastic Stack，推薦使用。

​

ELK

配置中心 Config

Spring Config 首推基於 git 的管理方式，提供了兩個管理維度，一個是 label(即 branch)，一個是 profile。主要核心功能：

• 業務配置

• 功能開關

• 服務配置

​

Spring Config

非同步佇列 MQ

MQ大家都熟悉，現在主流的MQ有rabbitMQ，rocketMQ，kafka。想要了解更多關於 rabbitMQ 和 kafka 的知識可以在這兩篇文章裡檢視：

圖文詳解：阿里寵兒【小兔】RabbitMQ的養成攻略

圖文詳解：Kafka到底有哪些祕密讓我對它情有獨鍾呢？

核心功能：削峰填谷

​

流量削峰

容錯限流 Hystrix

它設計用來當分散式系統發生不可避免的異常的時候去隔離當前服務和遠端服務、系統、三方包的聯絡，防止出現級聯失敗的情況，從而導致整個系統雪崩。主要核心功能：

• 失敗轉移和優雅降級

• 實時監控更改相關配置

• 基於執行緒和訊號量的斷路器隔離

​

容錯限流

負載均衡、服務呼叫

ribbon是一個負載均衡客戶端，可以很好的控制htt和tcp的一些行為。

Feign預設集成了ribbon。ribbon主要功能是提供客戶端的軟體負載均衡演算法。Ribbon就屬於程序內負載均衡，它只是一個類庫，集成於消費方程序，消費方通過它來獲取到服務提供方的地址。主要核心功能：負載均衡

​

負載均衡

持續整合 Jenkins

在專案多的時候，重複操作極大的浪費時間。如果遇到同一時間不同專案組打包專案，打包和部署伺服器就要排隊使用，測試人員只能在等待中浪費時間。為了解決這些問題，選擇尋找合適的持續整合方案。來自動化完成重複的步驟。jenkins 還包含了很多外掛，比如程式碼校驗等等。是 CI/CD 的基本技術。核心功能：

• 拉取程式碼

• 打包構建

• 將資源送往目標伺服器

​

持續整合

分散式快取 Redis

Redis 是一款基於 ANSI C 語言編寫的，BSD 許可的，日誌型 key-value 儲存元件，它的所有資料結構都存在記憶體中，可以用作快取、資料庫和訊息中介軟體。核心功能：

• 記憶體資料庫

• 基於記憶體資料庫的各種擴充套件功能

​

分散式快取 Redis

分散式事務

分散式事務的實現方式主要有：

• 2PC（two-phase commit protocol，強一致性，沒有可用性）

• 3PC

• TCC（Try-Confirm-Cancel）

• 本地訊息表，推薦 RabbitMQ。

• Saga 模式

本地訊息表：MQ分散式事務—本地訊息表—基於訊息的一致性。

• 上有投遞訊息

• 下游獲取訊息

• 上游投遞穩定性

• 下游接受穩定性

​

訊息佇列非同步

分庫分表 sharding jdbc

Sharding-JDBC 定位為輕量級 Java 框架，在 Java 的 JDBC 層提供額外的服務，以 jar 包形式提供服務，無需額外部署和依賴，可以理解為增強版的 JDBC 驅動，完全相容 JDBC 和各種 ORM 框架。核心功能：

• 資料分片

• 讀寫分離

• 透明的使用jdbc訪問各個資料庫

​

Sharding-JDBC

SpringCloud

SpringCloud，從命名我們就可以知道，Spring Cloud 是大名鼎鼎的 Spring 家族的產品， 專注於企業級開源框架的研發。

Spring Cloud 自從釋出到現在，仍然在不斷的高速發展，幾乎考慮了服務治理的方方面面，開發起來非常的便利和簡單。

Spring Cloud 架構

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

Service Consumer： 呼叫遠端服務的服務消費方。

EureKa Server： 服務註冊中心和服務發現中心。

​

Spring Cloud 架構

支援協議

Spring Cloud 使用 HTTP 協議的 REST API。

Spring Cloud 元件執行

所有請求都統一通過 API 閘道器（Zuul）來訪問內部服務。

閘道器接收到請求後，從註冊中心（Eureka）獲取可用服務。

由 Ribbon 進行均衡負載後，分發到後端的具體例項。

微服務之間通過 Feign 進行通訊處理業務。

​

Spring Cloud 元件執行

Dubbo

Dubbo 出生於阿里系，是阿里巴巴服務化治理的核心框架，並被廣泛應用於中國各網際網路公司；只需要通過 Spring 配置的方式即可完成服務化，對於應用無入侵，設計的目的還是服務於自身的業務為主。

雖然阿里內部原因 Dubbo 曾經一度暫停維護版本，但是框架本身的成熟度以及文件的完善程度，完全能滿足各大網際網路公司的業務需求。

Dubbo 架構

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

Consumer：呼叫遠端服務的服務消費方。

Registry：服務註冊中心和發現中心。

Monitor：統計服務和呼叫次數，呼叫時間監控中心。（Dubbo 的控制檯頁面中可以顯示，目前只有一個簡單版本。）

Container：服務執行的容器。

​

Dubbo 架構

支援協議

Dubbo 使用 RPC 通訊協議，提供序列化方式如下：

Dubbo：Dubbo 預設協議採用單一長連線和 NIO 非同步通訊，適合於小資料量大併發的服務呼叫，以及服務消費者機器數遠大於服務提供者機器數的情況。

RMI：RMI 協議採用 JDK 標準的 java.rmi.* 實現，採用阻塞式短連線和 JDK 標準序列化方式。

Hessian：Hessian 協議用於整合 Hessian 的服務，Hessian 底層採用 HTTP 通訊，採用 Servlet 暴露服務，Dubbo 預設內嵌 Jetty 作為伺服器實現。

HTTP：採用 Spring 的 Http Invoker 實現。

Webservice：基於 CXF 的 frontend-simple 和 transports-http 實現。

Dubbo 元件執行

每個元件都是需要部署在單獨的伺服器上，Gateway 用來接受前端請求、聚合服務，並批量呼叫後臺原子服務。每個 Service 層和單獨的 DB 互動。

​

Dubbo 元件執行儲

Gateway：前置閘道器，具體業務操作，Gateway 通過 Dubbo 提供的負載均衡機制自動完成。

Service：原子服務，只提供該業務相關的原子服務。

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

最後

以上就是關於微服務的一些核心知識點了，暫時就寫到這裡了，也是為自己做一下相關技術棧的記錄，後續有時間會針對每一項技術進行仔細研究，或者通過實際專案來展示，儘量通過一個完整的專案來幫助大家更好的瞭解這些技術的落地應用。