微服務架構設計總結

點選上方“芋道源碼”，選擇“設為星标”

管她前浪，還是後浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉億點點頭發...

源碼精品專欄

• 原創 | Java 2021 超神之路，很肝~
• 中文詳細注釋的開源項目
• RPC 架構 Dubbo 源碼解析
• 消息中間件 RocketMQ 源碼解析
• 資料庫中間件 Sharding-JDBC 和 MyCAT 源碼解析
• 作業排程中間件 Elastic-Job 源碼解析
• 分布式事務中間件 TCC-Transaction 源碼解析
• Eureka 和 Hystrix 源碼解析
• Java 并發源碼

來源：www.cnblogs.com/wintersun/p/6219259.html

• 微服務架構
• 微服務優點
• 需要考慮的問題
• 設計要素
• 服務容錯
• 微服務系統底座
• 容器（Docker）與微服務
• 微服務案例

微服務

圖檔

Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.

（設計系統的組織，其産生的設計和架構等價于組織間的溝通結構。）

Monolithic架構

圖檔

Monolithic比較适合小項目，優點是：

開發簡單直接，集中式管理, 基本不會重複開發

功能都在本地，沒有分布式的管理開銷和調用開銷。它的缺點也非常明顯，特别對于網際網路公司來說（不一一列舉了）：

• 開發效率低：所有的開發在一個項目改代碼，遞交代碼互相等待，代碼沖突不斷
• 代碼維護難：代碼功能耦合在一起，新人不知道何從下手
• 部署不靈活：建構時間長，任何小修改必須重新建構整個項目，這個過程往往很長
• 穩定性不高：一個微不足道的小問題，可以導緻整個應用挂掉

擴充性不夠：無法滿足高并發情況下的業務需求

推薦下自己做的 Spring Boot 的實戰項目：

https://github.com/YunaiV/ruoyi-vue-pro

微服務架構

微服務是指開發一個單個小型的但有業務功能的服務，每個服務都有自己的處理和輕量通訊機制，可以部署在單個或多個伺服器上。微服務也指一種種松耦合的、有一定的有界上下文的面向服務架構。也就是說，如果每個服務都要同時修改，那麼它們就不是微服務，因為它們緊耦合在一起；如果你需要掌握一個服務太多的上下文場景使用條件，那麼它就是一個有上下文邊界的服務，這個定義來自DDD領域驅動設計。

相對于單體架構和SOA，它的主要特點是元件化、松耦合、自治、去中心化，展現在以下幾個方面：

• 一組小的服務 服務粒度要小，而每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情。
• 獨立部署運作和擴充 每個服務能夠獨立被部署并運作在一個程序内。這種運作和部署方式能夠賦予系統靈活的代碼組織方式和釋出節奏，使得快速傳遞和應對變化成為可能。
• 獨立開發和演化 技術選型靈活，不受遺留系統技術限制。合适的業務問題選擇合适的技術可以獨立演化。服務與服務之間采取與語言無關的API進行內建。相對單體架構，微服務架構是更面向業務創新的一種架構模式。
• 獨立團隊和自治 團隊對服務的整個生命周期負責，工作在獨立的上下文中，自己決策自己治理，而不需要統一的指揮中心。團隊和團隊之間通過松散的社群部落進行銜接。

我們可以看到整個微服務的思想就如我們現在面對資訊爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個複雜的系統群組織能夠快速的應對變化。

我們為什麼采用微服務呢？

"讓我們的系統盡可能快地響應變化" - Rebecca Parson

讓我們的系統盡可能快地去響應變化。其實幾十年來我們一直在嘗試解決這個問題。如果一定要在前面加個限制的話，那就是低成本的快速響應變化。上世紀90年代Kent Beck提出要擁抱變化，在同期出現了諸多輕量級開發方法（諸如 XP、Scrum）；2001年靈活宣言誕生，之後又出現了精益、看闆等新的管理方式。如果說，這些是為了盡快的響應變化，在軟體開發流程和實踐方面提出的解決方案，那麼微服務架構就是在軟體技術和架構層面提出的應對之道。

圖檔

Autonomous

A Microservice is a unit of functionality; it provides an API for a set of capabilities oriented around a business domain or common utility

Isolated

A Microservice is a unit of deployment; it can be modified, tested and deployed as a unit without impacting other areas of a solution

Elastic

A Microservice is stateless; it can be horizontally scaled up and down as needed

Resilient

A Microservice is designed for failure; it is fault tolerant and highly available

Responsive

A Microservice responds to requests in a reasonable amount of time

Intelligent

The intelligence in a system is found in the Microservice endpoints not ‘on the wire’

Message Oriented

Microservices rely on HTTP or a lightweight message bus to establish a boundary between components; this ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages

Programmable

Microservices provide API’s for access by developers and administrators

Composable

Applications are composed from multiple Microservices

Automated

The lifecycle of a Microservice is managed through automation that includes development, build, test, staging, production and distribution

推薦下自己做的 Spring Cloud 的實戰項目：

https://github.com/YunaiV/onemall

服務之間如何通信

圖檔

一般同步調用比較簡單，一緻性強，但是容易出調用問題，性能體驗上也會差些，特别是調用層次多的時候。RESTful和RPC的比較也是一個很有意 思的話題。

一般REST基于HTTP，更容易實作，更容易被接受，服務端實作技術也更靈活些，各個語言都能支援，同時能跨用戶端，對用戶端沒有特殊的要 求，隻要封裝了HTTP的SDK就能調用，是以相對使用的廣一些。

RPC也有自己的優點，傳輸協定更高效，安全更可控，特别在一個公司内部，如果有統一個 的開發規範和統一的服務架構時，他的開發效率優勢更明顯些。

就看各自的技術積累實際條件，自己的選擇了。而異步消息的方式在分布式系統中有特别廣泛的應用，他既能減低調用服務之間的耦合，又能成為調用之間的緩沖，確定消息積壓不會沖垮被調用方，同時能 保證調用方的服務體驗，繼續幹自己該幹的活，不至于被背景性能拖慢。

不過需要付出的代價是一緻性的減弱，需要接受資料最終一緻性；還有就是背景服務一般要 實作幂等性，因為消息發送出于性能的考慮一般會有重複（保證消息的被收到且僅收到一次對性能是很大的考驗）；最後就是必須引入一個獨立的broker，如 果公司内部沒有技術積累，對broker分布式管理也是一個很大的挑戰。

圖檔

微服務優點

• 每個微服務都很小，這樣能聚焦一個指定的業務功能或業務需求。
• 微服務能夠被小團隊單獨開發，這個小團隊是2到5人的開發人員組成。
• 微服務是松耦合的，是有功能意義的服務，無論是在開發階段或部署階段都是獨立的。
• 微服務能使用不同的語言開發。
• 微服務允許容易且靈活的方式內建自動部署，通過持續內建工具，如Jenkins, bamboo 。
• 一個團隊的新成員能夠更快投入生産。
• 微服務易于被一個開發人員了解，修改和維護，這樣小團隊能夠更關注自己的工作成果。無需通過合作才能展現價值。
• 微服務允許你利用融合最新技術。
• 微服務隻是業務邏輯的代碼，不會和HTML,CSS 或其他界面元件混合。
• 微服務能夠即時被要求擴充。
• 微服務能部署中低端配置的伺服器上。
• 易于和第三方內建。
• 每個微服務都有自己的存儲能力，可以有自己的資料庫。也可以有統一資料庫。

微服務架構的缺點

• 微服務架構可能帶來過多的操作。
• 需要DevOps技巧 (en.wikipedia.org/wiki/D).
• 可能雙倍的努力。
• 分布式系統可能複雜難以管理。
• 因為分布部署跟蹤問題難。
• 當服務數量增加，管理複雜性增加。

需要考慮的問題

• 單個微服務代碼量小，易修改和維護。但是，系統複雜度的總量是不變的，每個服務代碼少了，但服務的個數肯定就多了。就跟拼圖遊戲一樣，切的越碎，越難拼出整幅圖。一個系統被拆分成零碎的微服務，最後要內建為一個完整的系統，其複雜度肯定比大塊的功能內建要高很多。
• 單個微服務資料獨立，可獨立部署和運作。雖然微服務本身是可以獨立部署和運作的，但仍然避免不了業務上的你來我往，這就涉及到要對外通信，當微服務的數量達到一定量級的時候，如何提供一個高效的叢集通信機制成為一個問題。
• 單個微服務擁有自己的程序，程序本身就可以動态的啟停，為無縫更新的打好了基礎，但誰來啟動和停止程序，什麼時機，選擇在哪台裝置上做這件事情才是無縫更新的關鍵。這個能力并不是微服務本身提供的，而是需要背後強大的版本管理和部署能力。
• 多個相同的微服務可以做負載均衡，提高性能和可靠性。正是因為相同微服務可以有多個不同執行個體，讓服務按需動态伸縮成為可能，在高峰期可以啟動更多的相同的微服務執行個體為更多使用者服務，以此提高響應速度。同時這種機制也提供了高可靠性，在某個微服務故障後，其他相同的微服務可以接替其工作，對外表現為某個裝置故障後業務不中斷。同樣的道理，微服務本身是不會去關心系統負載的，那麼什麼時候應該啟動更多的微服務，多個微服務的流量應該如何排程和分發，這背後也有一套複雜的負載監控和均衡的系統在起作用。
• 微服務可以獨立部署和對外提供服務，微服務的業務上線和下線是動态的，當一個新的微服務上線時，使用者是如何通路到這種新的服務？這就需要有一個統一的入口，新的服務可以動态的注冊到這個入口上，使用者每次通路時可以從這個入口拿到系統所有服務的通路位址。這個統一的系統入口并不是微服務本身的一部分，是以這種能力需要系統單獨提供。
• 還有一些企業級關注的系統問題，比如，安全政策如何集中管理？系統故障如何快速審計和跟蹤到具體服務？整個系統狀态如何監控？服務之間的依賴關系如何管理？等等這些問題都不是單個微服務考慮的範疇，而需要有一個系統性的考慮和設計，讓每個微服務都能夠按照系統性的要求和限制提供對應的安全性，可靠性，可維護性的能力。

圖檔

API為什麼很重要

• 服務價值的精華展現
• 可靠、可用、可讀
• 隻有一次機會

圖檔

實作一個API網關作為所有用戶端的唯一入口。API網關有兩種方式來處理請求。有些請求被簡單地代理/路由到合适的服務上，其他的請求被轉給到一組服務。

圖檔

相比于提供普适的API，API網關根據不同的用戶端開放不同的API。比如，Netflix API網關運作着用戶端特定的擴充卡代碼，會向用戶端提供最适合其需求的API。

API網關也可以實作安全性，比如驗證用戶端是否被授權進行某請求。

設計要素

• Version
• RequstID
• Auth&Signature
• RateLimit
• Docs
• ErrorCode&Message

圖檔

微服務治理

• 按需伸縮
• 部署與監控運維成本
• 獨立部署
• 機器數量與部署成本
• 業務獨立
• 服務依賴、治理，版本管理、事務處理
• 技術多樣性
• 環境部署成本、約定成本
• 運作狀态治理
• 監控、限流、SLA、LB、日志分析
• 服務注冊與發現
• 部署
• 快速、複制、擴容
• 單機開發
• 調用
• 安全、容錯、服務降級、調用延時

圖檔

圖檔

服務容錯

當企業微服務化以後，服務之間會有錯綜複雜的依賴關系，例如，一個前端請求一般會依賴于多個後端服務，技術上稱為1 -> N扇出. 在實際生産環境中，服務往往不是百分百可靠，服務可能會出錯或者産生延遲，如果一個應用不能對其依賴的故障進行容錯和隔離，那麼該應用本身就處在被拖垮的風險中。

在一個高流量的網站中，某個單一後端一旦發生延遲，可能在數秒内導緻所有應用資源(線程，隊列等)被耗盡，造成所謂的雪崩效應(Cascading Failure)，嚴重時可緻整個網站癱瘓。

圖檔

服務依賴

圖檔

服務架構

1. 服務注冊、發現、負載均衡和健康檢查，假定采用程序内LB方案，那麼服務自注冊一般統一做在伺服器端架構中，健康檢查邏輯由具體業務服務定制，架構層提供調用健康檢查邏輯的機制，服務發現和負載均衡則內建在服務用戶端架構中。
2. 監控日志，架構一方面要記錄重要的架構層日志、metrics和調用鍊資料，還要将日志、metrics等接口暴露出來，讓業務層能根據需要記錄業務日志資料。在運作環境中，所有日志資料一般集中落地到企業背景日志系統，做進一步分析和處理。
3. REST/RPC和序列化，架構層要支援将業務邏輯以HTTP/REST或者RPC方式暴露出來，HTTP/REST是目前主流API暴露方式，在性能要求高的場合則可采用Binary/RPC方式。針對目前多樣化的裝置類型(浏覽器、普通PC、無線裝置等)，架構層要支援可定制的序列化機制，例如，對浏覽器，架構支援輸出Ajax友好的JSON消息格式，而對無線裝置上的Native App，架構支援輸出性能高的Binary消息格式。
4. 配置，除了支援普通配置檔案方式的配置，架構層還可內建動态運作時配置，能夠在運作時針對不同環境動态調整服務的參數和配置。
5. 限流和容錯，架構內建限流容錯元件，能夠在運作時自動限流和容錯，保護服務，如果進一步和動态配置相結合，還可以實作動态限流和熔斷。
6. 管理接口，架構內建管理接口，一方面可以線上檢視架構和服務内部狀态，同時還可以動态調整内部狀态，對調試、監控和管理能提供快速回報。Spring Boot微架構的Actuator子產品就是一個強大的管理接口。
7. 統一錯誤處理，對于架構層和服務的内部異常，如果架構層能夠統一處理并記錄日志，對服務監控和快速問題定位有很大幫助。
8. 安全，安全和通路控制邏輯可以在架構層統一進行封裝，可做成插件形式，具體業務服務根據需要加載相關安全插件。
9. 文檔自動生成，文檔的書寫和同步一直是一個痛點，架構層如果能支援文檔的自動生成和同步，會給使用API的開發和測試人員帶來極大便利。Swagger是一種流行Restful API的文檔方案。

微服務系統底座

一個完整的微服務系統，它的底座最少要包含以下功能：

• 日志和審計，主要是日志的彙總，分類和查詢
• 監控和告警，主要是監控每個服務的狀态，必要時産生告警
• 消息總線，輕量級的MQ或HTTP
• 注冊發現
• 負載均衡
• 部署和更新
• 事件排程機制
• 資源管理，如：底層的虛拟機，實體機和網絡管理

以下功能不是最小集的一部分，但也屬于底座功能：

• 認證和鑒權
• 微服務統一代碼架構，支援多種程式設計語言
• 統一服務建構和打包
• 統一服務測試
• 微服務CI/CD流水線
• 服務依賴關系管理
• 統一問題跟蹤調試架構，俗稱調用鍊
• 灰階釋出
• 藍綠部署

容器（Docker）與微服務

• 容器夠小
• 解決微服務對機器數量的訴求
• 容器獨立
• 解決多語言問題
• 開發環境與生産環境相同
• 單機開發、提升效率
• 容器效率高
• 省錢
• 代碼/image一體化
• 可複用管理系統
• 容器的橫向與縱向擴容
• 可複制
• 可動态調節CPU與記憶體

容器(Docker)與微服務

• Image管理
• 系統安全管理
• 授權管理
• 系統成熟度
• 社群成熟度

開發方式影響

随着持續傳遞概念推廣以及Docker容器普及，微服務将這兩種理念和技術結合起來，形成新的微服務+API + 平台的開發模式，提出了容器化微服務的持續傳遞概念。下圖傳統Monolithic的DevOps開發隊伍方式：

圖檔

這種整體型架構要求産品隊伍橫跨産品管理 Dev開發 QA DBA 以及系統營運管理，而微服務架構引入以後，如下圖：

圖檔

微服務促進了DevOps方式的重組，将一個大臃腫的整體産品開發隊伍切分為根據不同微服務的劃分的産品隊伍，以及一個大的整體的平台隊伍負責營運管理，兩者之間通過API互動，做到了松耦合隔絕。

圖檔

圖檔

• 首先需要考慮建構DevOps能力，這是保證微服務架構在持續傳遞和應對複雜運維問題的動力之源；
• 其次保持服務持續演進，使之能夠快速、低成本地被拆分和合并，以快速響應業務的變化；
• 同時要保持團隊和架構對齊。微服務貌似是技術層面的變革，但它對團隊結構群組織文化有很強的要求和影響。識别和建構比對架構的團隊是解決問題的另一大支柱。
• 最後，打造持續改進的自組織文化是實施微服務的關鍵基石。隻有持續改進，持續學習和回報，持續打造這樣一個文化氛圍和團隊，微服務架構才能持續發展下去，保持新鮮的生命力，進而實作我們的初衷。

微服務的實施是有一定的先決條件：基礎的運維能力（如監控、快速配置、快速部署）需提前建構，否則就會陷入如我們般被動的局面。

推薦采用基礎設施及代碼的實踐，通過代碼來描述計算和網絡基礎設施的方法，使得圖案度i可以快速安全的搭建和處理由新的配置代替的伺服器，伺服器之間可以擁有更高的一緻性，降低了在“我的環境工作，而你的環境不工作”的可能，也是為後續的釋出政策和運維提供更好的支撐。

圖檔

由于Docker引入，不同的微服務可以使用不同的技術架構，比如Node.js Java Ruby Python等等，這些單個的服務都可以獨立完成傳遞生命周期，如下：

圖檔

微服務案例

Netflix的微服務架構如下，着重全球分發 高可擴充性和可用性：

圖檔

Twitter的微服務架構，注重高效的可擴充的資料中心：

圖檔 - END -

歡迎加入我的知識星球，一起探讨架構，交流源碼。加入方式，長按下方二維碼噢：

已在知識星球更新源碼解析如下：

最近更新《芋道 SpringBoot 2.X 入門》系列，已經 101 餘篇，覆寫了 MyBatis、Redis、MongoDB、ES、分庫分表、讀寫分離、SpringMVC、Webflux、權限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能測試等等内容。

提供近 3W 行代碼的 SpringBoot 示例，以及超 4W 行代碼的電商微服務項目。

擷取方式：點“在看”，關注公衆号并回複 666 領取，更多内容陸續奉上。

文章有幫助的話，在看，轉發吧。
謝謝支援喲 (*^__^*）