1，微服務架構是什麼

很多做微服務的程式猿都很避諱SOA架構，談起微服務必然和單體應用進行對比，好像不如此微服務架構就不高大上，不足以與有榮焉。

然而，從單體分層應用到分散式架構，再到面向服務的架構，直到微服務架構，都是在前者的基礎上為解決面臨的問題而一步步發展而來，甚至於在解決問題的同時，也總是引入新的問題（比如技術複雜度越來越高），只有在有效解決引入問題後，新的架構風格才能體現其價值。

單體分層應用 到 分散式架構：

當單體分層應用模組之間耦合嚴重，不能針對行擴充套件叢集的問題越來越不能忍受後，產生了分散式架構，分散式架構降低了每個單體應用的複雜度、可以靈活不是升級和橫向擴充套件叢集，但是引入了問題：程序間通訊。當時主要是採用EJB框架或者其他RPC元件，以解決程序通訊問題。同時引入了分散式事務等問題和各種解決方案。

分散式架構可以理解為：多個單體分層架構系統，以程序通訊技術整合到一起的一種架構風格。

分散式架構到SOA架構：

隨著分散式架構風格構建的系統，程序通訊使用的RPC封裝相關問題、介面描述穩定性、異構系統問題等導致使用技術複雜度高和難以維護的問題越來越突出的時候，為解決問題，就出現了SOA架構風格，就像是程式設計引入的面向介面程式設計，要求所有分散式中的單個系統都定義和釋出明確的服務介面，並採用webservice技術等解決異構系統之間的互動。同時，SOA架構引入了服務治理的難點，當dubbo等框架逐漸成熟，有效解決各種問題後，SOA架構才算真正體現價值。（但事實上，webservice效能問題等原因，dubbo依然採用RPC，做程序通許，在這一塊兒，複雜度依然不可避免。）

SOA架構也有直接稱為：面向服務的分散式架構。

SOA架構 到 微服務架構：

SOA架構是一種複雜度很高的架構模式，一般大型的、使用者量非常大的產品採用，這種環境下的產品面對複雜多變的需求，產品的快速迭代，需要更小、更靈活以及更高的自治的小應用來應對，每個小應用根據自身的業務需求等確定技術選型，相互之間通訊拋棄複雜度高的重方法（RPC），以更好的快速響應市場變化。

所以簡單來說：微服務架構就是：一種粒度更小，更輕量級、去中心化的、服務間通訊採用輕量級通訊機制（通常是restful API）的SOA架構。

從SOA架構到微服務架構，從技術上其實沒有跨度，可以理解為：微服務是一種方法，指導更好的實現SOA架構。

不要認為SOA就必須採用ESB，ESB只是實現SOA的一種技術，微服務建議不採用ESB這種中心化的管理實現SOA。

微服務的核心思想就是：以更輕、更小的粒度來縱向拆分應用，各個小應用能夠獨立選擇技術、發展、部署

2，微服務設計原則和實現

1，高內聚、低耦合

分散式架構縱向拆分系統時，不管如何強調高內聚、低耦合，都不為過。微服務的架構更是如此，因為大的系統，被拆分很多互相協作的小應用，這會導致服務之間的互動量會大大增大，如果不能高內聚、低耦合，對服務的管理、監控就會提出巨大的挑戰。如果牽一髮而動全身，那麼維護變得比單體應用的複雜度更高，得不償失。

如何縱向拆分，獲得高內聚、低耦合的分散式應用？

圍繞業務進行建模，按照業務的領域模型進行分析；按照界定上下文，劃分業務領域；界定上下文之內的各種模型是穩定的，並且內聚的。在一個業務的界定上下文下，內部的各種模型之間互動，完成該上下文的業務邏輯。各業界定上下文之間的輸入輸出，其實就是拆分後各個小應用之間基本的服務需求。各個小系統按照界定上下文涉及的業務內聚，同時只有各個輸入輸出之間依賴，沒有業務上的複雜耦合。

領域驅動設計的基本概念和內容，參見：DDD簡要描述

2，只發布有價值的服務

微服務架構拆分出來的小應用可以具有技術、部署等獨立和靈活性，但是絕不是意味著小應用就可以為所欲為。

在小應用的服務設計時，要有清晰的系統意思：整個分散式系統中的所有小應用+使用軟體產品的組織和人，一起協同運作才是一個系統。單獨的小應用本身需要和其他應用協作才能產生價值。

小應用應該向外暴露且只暴露有價值的服務。

應用暴露的服務是否有價值，從下面考慮：

1，服務是服務於業務場景的，一個不會被使用的服務是沒有價值的。可以提前定義服務，但是，是依賴於對業務的分析和發展的預期，而不是：“未來可能有應用會用到”。不管你多喜歡這個服務，都不應該因為小應用團隊自身的喜好而給其他協作團隊帶來不必要麻煩。

2，服務的價值依賴於業務場景價值實現來體現，儘量優先實現和釋出價值高的服務。

（如何判斷需求的價值、優先順序？從產品立項，產品在組織的整體運營目標中就是具有其核心價值的，是從組織整體的運營目標中拆分出來的，是承擔了服務整體運營的任務的，這就是產品的基本原則來源。產品原則確定什麼最重要，是對團隊信仰和價值觀的總結，用來指導對US價值、優先順序的衡量。）

3，服務介面穩定

服務介面是對相關協作應用團隊的承諾，其他團隊使用資訊是完全基於介面說明的，如果介面多變，會導致協作工作量劇增。

如何使服務穩定：

1，良好的領域分析，對業務流和資料互動掌握清晰，並對潛在的業務變化有一定的預測，並清楚哪些變化點可能影響到服務，有一定的前瞻性設計；（並不推薦過於強調可能的變化點）

2，儘量採用非同步方式進行小應用間的互動，通過訊息釋出、訂閱機制，讓訂閱者決定實現方式，減少應用間的服務依賴。（當然，訊息也需要進行良好的設計和定義）

4，嚴格區分公共模型和內部模型

應用內部實現不應該暴露給不需要的應用，內部模型反應了內部業務資訊，不應該混用公共模型和內部模型。公共模型是穩定的需要互動的資訊，公共模型可以在互動的系統間複用，但是內部模型是不穩定的，應用團隊可以根據需要隨時進行重構。

如何分離：

對外暴露服務的出參、入參、訊息體等都應該抽取出來定義到jar包中作為公共模型，該部分jar包可以被需要互動的應用引用。該包中的內容應該是相對穩定的，隨著暴露服務的增加，會有增加，但是不應該輕易變化。
3，服務化技術棧

微服務條目（落地技術）

• 服務開發（springboot、spring等）
• 服務配置與管理（Archaius等）
• 服務註冊與發現（Eureka、Consul、Zookeeper等）
• 服務呼叫（Rest、RPC、gRPC）
• 服務熔斷器（Hystrix、Envoy等）
• 負載均衡（Ribbon、Nginx等）
• 服務介面呼叫（客戶端呼叫服務的簡化工具；Feign等）
• 服務配置中心管理（SpringCloudConfig等）
• 服務路由（API閘道器；Zuul等）
• 服務監控（Zabbix、Nagios、Metrics、Spectator等）
• 全鏈路追蹤（Zipkin、Brave、Dapper等）
• 服務部署（Docker、OpenStack等）
• 訊息佇列（RabbitMQ、Kafka、ActiveMQ等）
• 事件訊息匯流排（SpringCloud Bus）

總結

微服務架構實踐並不容易，不可能強大無匹還簡單無比。雖然有很多現有框架對微服務在技術上都能有很好的支撐（比較而言：spring cloud應該是對SOA架構各方面支撐最全面的框架）。但是必須意識到微服務不是一蹴而就的，也不是一勞永逸的。做好技術和環境準備，再一步步實踐，必要的調整以期逐漸完善。

原文：https://blog.csdn.net/kongxincai0/article/details/81435867