【萬字長文、多圖】微服務架構學習筆記

這是一份是我在極客時間學習《微服務架構核心20講》時作的筆記。

大綱

1.什麼是微服務架構？
2.架構師如何權衡微服務的利弊？
3.康威法則和微服務給架構師怎樣的啓示
4.企業應該在何時開始考慮引入微服務
5.怎麼的組織架構更適合微服務？
6.如何理解阿里巴巴提出的微服務中臺戰略
7.如何給出一個清晰簡潔的服務分層方式？
8.微服務整體技術架構是怎樣設計的
9.微服務最經典的三種服務發現機制
10.微服務 API 服務網關（一）「原理」
11.微服務 API 服務網關（二）「開源網關 Zuul」
12.跟 Netflix 學習微服務路由發現體系
13.集中式配置中心的做用和原理
14.微服務通信方式 RPC vs. REST
15.微服務架構須要考慮哪些治理環節
16.微服務監控系統分層和監控架構
17.微服務的調用鏈監控該如何選擇
18.微服務的容錯限流是如何工做的
19.Docker 容器部署技術 & 持續交付流水線
20.容器集羣調度和基於容器的發佈體系

---

什麼是微服務架構？

1. 微服務主張將單體應用拆成小的獨立服務
2. 微服務運行在獨立的進程中，以進程的方式來橫向擴展。（Java 運行在 Tomcat 中，NodeJS，容器等）
3. 輕量級的通訊機制（HTTP）
4. 基於業務能力（SOA）來構建
5. 獨立部署，每一個團隊維護本身的部署
6. 無集中式的管理，原來模式會有架構團隊來規劃標準：統一技術棧、統一存儲方式。而微服務主張每一個團隊根據本身的的業務須要選擇本身對擅長的、最能解決當前技術問題的技術棧，甚至採用不用的存儲方式。

Netflix - 微服務定義：Loosely coupled (鬆耦合), service oriented architecture (面向服務架構 - SOA) with bounded context(有界上下文或局部狀態)。

架構師如何權衡微服務的利弊？

微服務優點：

1. 強模塊化邊界，從類方式 -> 組件（類庫）-> 以服務的方式作模塊化（每一個團隊獨立的開發和維護本身的服務，開發完其餘團隊能夠直接調用這個服務，而不須要像 jar 包同樣去分享）
2. 可獨立部署，不要引入其餘團隊來一塊兒部署
3. 技術多樣性，分散式治理。不是越多越好（技術複雜性）

微服務帶來的挑戰：

1. 分佈式複雜性，單塊應用由一個團隊就能搞定。微服務化變成分佈式系統，會涉及到幾10、上百個服務，服務之間相互溝通合做使得系統會變得很是複雜，通常的開發人員或團隊都不能清晰的瞭解整個系統如何工做的
2. 最終一致性，每一個團隊有本身的數據存貯，例如：A 團隊有訂單數據、B 團隊也有訂單數據，當A 團隊改變訂單數據時，須要同步到有相似概念的團隊，這就涉及到數據一致性的問題
3. 運維複雜性，運維的是一個分佈式系統，對監控、容量規劃、可靠性、穩定性提出了很是大的挑戰
4. 測試複雜性，須要多個團隊聯合作集成測試

康威法則和微服務給架構師怎樣的啓示

康威法則：

「Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.」

設計系統的組織，其產生的設計和架構，等價組織的組織架構。

初期團隊規模、業務量不大、系統比較簡單，主要嘗試業務模式能不能起來。隨着業務增加、團隊規模變大（從一個團隊擴大到多個團隊），這時候若是系統架構仍然是單塊應用就會和多團隊產生不匹配的狀況（違反了康威法則，即單塊應用架構沒有反應組織架構）就會出現矛盾、協調成本變高、交付效率變低。

微服務是一種解決手段，將單塊應用拆分紅若干個微服務（圖：組織內部有 3 個團隊，把單塊架構拆分紅 S一、S二、S3 3 個服務，每一個團隊負責維護本身的服務。符合康威法則）

擴展：每一個架構師都應該研究下康威定律

企業應該在何時開始考慮引入微服務

初期業務複雜性不高，開發的應用系統主要是驗證商務模式。這個時候建議採用單塊應用。不推薦微服務，由於微服務前期有基礎設施要求，使得生產力變低。

隨着應用變得成功、用戶變多、系統複雜性變得愈來愈高，若是仍然使用單塊應用就會違背康威法則，使得生產力會隨着系統複雜性而下降，這時候就要考慮使用微服務。

考慮使用微服務的點（圖中交叉點），我的經驗：團隊接近百人研發時應該考慮採用微服務架構。

如何選擇?

1. 開始就走微服務架構
2. 單塊優先

不推薦方案 1：由於一開始的時候對問題領域並非很理解，很難把控怎麼來拆分這個服務、劃分服務邊界。另外有可能花了不少精力開發一套微服務，可是這個應用並不被客戶接受（應用沒有被市場驗證，可能會失敗）

推薦： 單塊優先，隨着業務推動，架構師會對業務領域有愈來愈清晰的瞭解，這個時候若是單塊應用不能知足業務發展需求了，研發效率開始降低（到了交叉點）。須要將某些功能點拆分出來，後續陸陸續續隨着業務團隊變大能夠將其餘功能點陸續拆分出來，最後變成一個微服務架構。

怎麼的組織架構更適合微服務？

橫座標： 業務價值流交付過程（研發 -> 上線 -> 運維）

縱座標： 業務能力，不一樣的業務線（業務團隊）

傳統企業： 團隊劃分是嚴格按照職能的（獨立職能部門），當有項目來的時候會從每一個團隊抽調一些人來組成交付團隊，當項目完成後這些人會回到各自的職能團隊。

這個團隊的劣質：

1. 溝通成本比較大（團隊溝通）
2. 反饋慢、週期長

基於微服務跨職能的組織模式：每一個團隊跨職能既有產品專家、用戶體驗專家、研發、測試專家，整個造成一個端到端的閉環。這些人圍繞在微服務周圍進行開發、測試和交付、不會由於項目結束而解散。

DBA、運維也以產品的方式來交付平臺產品（將計算、網絡存儲、持續交付的能力封裝在一個平臺內），對外提供 API 來支持不一樣的業務線快速的交付、迭代。

端到端控制權： 團隊內部人要負責：架構、設計、開發、評審、測試、發佈、運行和支持。

團隊規模：根據亞馬遜的兩個披薩原則 – 12我的左右（2 個披薩能搞定） 誰開發、誰就要去構建、去負責運行

微服務架構本質上是組織架構的重組 – Netflix 前架構師 Andrew

---

如何理解阿里巴巴提出的微服務中臺戰略

現代技術體系分四層：

1. IaaS層：基礎設施即服務：計算、存儲、網絡、監控等由基礎運維團隊來負責，提供底層基礎設施
2. PaaS層：平臺即服務：應用監控、持續交付、服務框架、後臺服務（大數據、AI）
3. 核心業務層：
4. 應用層
5. 渠道（第三方接入）

阿里巴巴提出大中臺（技術中臺 + 業務中臺），小前臺戰略（前端業務更小、更靈活，能根據市場的變化、業務的需求不斷的演化）從而賦能業務的持續創新，產生各類業務模式、快速響應市場需求。

PaaS 是微服務基礎設施層，核心業務層是公司的核心領域能力把它微服務化、抽象化沉澱下來的核心能力，這層能力依賴下一層的 PaaS 雲平臺、大數據及AI，同時向上支撐不一樣的業務線去交付業務應用。

如何給出一個清晰簡潔的服務分層方式？

分紅兩層（不一樣公司有本身的分層，有的3、四層，有的只有一層：統稱服務或微服務）

1. 基礎服務：支撐性服務，如電商網站的商品服務、用戶服務、購物車服務。都比較基礎性、原子性
2. 聚合服務：因爲有不一樣的外部接入端，會對服務作適當的適配、聚合和裁剪的工做

微服務整體技術架構是怎樣設計的

1. 接入層：外部、內部流量接入
2. 網關層：流量接入後進入網關層，網關層在微服務體系中佔有很是重要的地位，主要作反向路由、限流熔斷、安全等跨橫切面的功能
3. 業務服務層：分爲聚合層和基礎層
4. 支撐服務：微服務須要支撐體系來支撐它，例如：服務的註冊發現、集中化配置、容錯限流、認證受權、日誌聚合、監控告警、後臺服務（MQ、緩存、Job、數據訪問）
5. 平臺服務層：發佈系統、集羣資源調度、鏡像治理、IAM（權限管控）
6. 基礎設施：主要有運維團隊維護

微服務最經典的三種服務發現機制

1. 傳統基於LB (負載均衡)的模式
2. 進程內LB 模式
3. 主機獨立LB 模式

方式一：服務提供商上線後會向運維申請一個域名，而後運維配置負載均衡器。當用戶訪問域名時會域名解析到負載均衡器，負載均衡器進而指向到後臺服務器（多份）

優勢：廣泛的作法、比較簡單；消費者接入的成本比較低 缺點：服務的配置、域名的配置都須要運維的介入；集中的LB 可能會是一個單點，若是集中式LB 掛掉會影響到整個服務沒法訪問；性能損失，當消費者調用後臺服務時必須穿透LB ，會有性能開銷。

方式二：將LB 功能移動到應用的進程內，服務提供商會自動經過註冊方式註冊到服務註冊表，並按期發送心跳。服務消費經過客戶端（帶有服務發現和負載均衡功能）LB 調用後臺服務，而且LB會按期同步服務註冊表中的服務信息。

優勢： 沒有集中式的LB，性能會好，不存在單點問題

缺點： 在多語言環境中，必須爲每個消費者去開發有這樣一個客戶端，升級成本和多語言支持成本會高些

方式三：在前面兩種方式基礎上作了一個折中，將LB功能以一個獨立進程的方式部署在一臺獨立的主機上（既不是集中式LB，也不是在進程內客戶端的LB），其餘和方式二相似。

微服務API 服務網關（一）「原理」

公司內部通常會有不少微服務：購物車、庫存、訂單等，這些微服務是每一個團隊各自獨立維護的，但咱們不但願外部用戶訪問的時候知道這些細節。這時候就能夠經過網關來屏蔽這些細節，讓客戶看到的企業內部這些服務的時候像是一個服務。

屏蔽內部細節，暴露統一接口

爲何在接入網關前有一層負載均衡？是想讓網關是無狀態的（無狀態網關好處：能夠部署不少，不會有單點，即便掛了一臺其餘網關還在，這對整個系統的穩定性和可用性很是重要）。

網關基本功能：

1. 反向路由，將外部的請求轉換成內部具體服務的調用。與Nginx的反向代理功能相同
2. API 組合（這部分也可由聚合服務負責）
3. 協議轉換，RESTful API 或 gRPC
4. 認證安全，惡意訪問（爬蟲，黑客等）
5. 限流熔斷，突發流量（雙11、促銷等）以避免形成內部服務器癱
6. 日誌監控，對全部流量作訪問的審計，對日誌作分析

對請求的身份驗證、受權、限流熔斷、日誌監控等的處理函數稱爲邊緣函數。

微服務API服務網關（二）「開源網關Zuul」

Zuul過濾器：

1. Pre routing filters（前置路由過濾器）：如日誌處理
2. Routing filters（路由過濾器）：目的找到目標服務並進行調
3. Post routing filters（後置路由過濾器）：響應回來通過後置路由過濾器會到客戶端，在後置路由過濾器中能夠作過後處理：日誌、統計和審計等

(過濾器上傳加載機制)

(Request Context 實如今各個階段過濾器中分享相關信息。)

跟 Netflix 學習微服務路由發現體系

Netflix 兩個核心組件：

1. 服務註冊中心 – Eureka
2. 網關 – Zuul

內部微服務兩層邏輯劃分：

1.基礎服務 – Netflix稱：中間層服務2.聚合服務 – Netflix 稱：Edge service（邊界服務）

內部服務經過內部服務註冊中心 Eureka 註冊、發現。

1. 基礎服務註冊服務到服務中心
2. 聚合服務調用基礎服務時，經過註冊中心作服務發現，拉取路由表
3. 網關同步服務註冊中心的路由表，當服務請求進來時網關根據路由表找到後臺對應的聚合服務進行調用

服務註冊中心還能夠作服務治理，例如對服務調用的安全管控。

集中式配置中心的做用和原理

傳統的作法在配置文件中作配置，而且每一個團隊有各自的作法，這種作法的隱患：

1. 配置不標準，格式不統一
2. 上線後如遇重大事故，去響應並調整配置、去修改配置並從新發布，時間週期會比較長
3. 配置文件的修改沒法審計、追溯

哪些須要集中配置：

• 連接字符串 - 數據庫連接字符串、緩存連接字符串、消息隊列鏈接字符串動態調整參數 - 超時時間、限流閾值
• 業務開關 – 地域性功能、促銷時開放的功能

配置中心能夠簡單的認爲是一個服務器，開發、運營人員能夠經過界面對配置中心進行配置，咱們的服務連到配置中心後能夠實時更新配置服務器中修改的配置。

更新的方式主要有兩種：

1. 服務主動拉取配置 – Pull（弊端：有延遲）
2. 服務時刻連在Config Serve上，Config Server 有變動時會Push到每一個服務上（弊端：網絡等緣由沒能Push到某個服務上）

攜程開源的配置中心 – Apollo

Apollo 配置中心（左側）是一個服務器，研發或運營人員能夠在服務端進行配置的修改，Apollo配置中心帶有客戶端（支持Java、.Net），客戶端有一個緩存機制 – 配置更新後會拉取到客戶端的內存緩存中，爲了防止內存緩存的丟失客戶端還會按期將內存緩存同步到本地文件緩存中，這樣的設計可使得若是配置中心掛掉或應用程序重啓後還能經過讀取本地文件緩存。

服務的更新結合了配置推送 + 定時拉取，以保證高可用

微服務通信方式 RPC vs. REST

1. 耦合性：RPC - 服務端和客戶端必須以特定的消息格式進行通信
2. 消息協議：RPC – 二進制：thrift、protobuf等，性能比較高；REST – 文本XML、JSON。payload會比二進制大
3. 通信協議：RPC – TCP協議；REST – HTPP/HTTP2
4. 性能：RPC – 高，REST – 基於文本消息協議和HTTP，差於RPC
5. 接口契約IDL：RPC – thrift、protobuf IDL；REST – Swagger
6. 客戶端：RPC – 強類型客戶端，通常自動生成、多語言支持；REST – 通常HTTP客戶端可訪問，可自動生成強類型客戶端、多語言
7. 案例：RPC - Dubbo（阿里巴巴）、Motan（新浪微博）、Tars（騰訊）等；REST – SpringMVC/Boot、Jax-rs等
8. 開發者友好：RPC - 客戶端比較方便，但二進制消息不可讀；REST – 文本協議消息可讀
9. 對外開放：RPC – 對外通常須要轉換REST；REST – 直接對外開放

微服務架構須要考慮哪些治理環節

1. 服務註冊發現
2. 負載均衡、路由（灰度發佈、藍綠部署 – 軟路由能力）
3. 日誌監控 – 問題排查
4. Metrics – 對服務的調用量、延遲等監控
5. 調用鏈埋點 – 微服務有錯綜複雜的依賴關係，若是沒有好的調用鏈監控開發人員很容易迷失在這些服務中，出問題很難定位
6. 限流熔斷
7. 安全 & 訪問控制：黑名單、限制
8. REST/RPC
9. 序列化XML/JSON/二進制
10. 代碼生成 – 大規模開發比較推崇一種契約驅動的開發方法，開發人員先定義契約而後用代碼生成的方式自動生成客戶端和服務器端，這個在大規模開發中生成的代碼比較規整
11. 統一異常處理 – 異常標準化
12. 文檔 – 方便開發人員接入
13. 配置集成
14. 後臺服務集成 – DB、MQ、Cache

微服務治理就將這些環節沉澱下來變成框架或平臺的一部分；開發人員專一於業務邏輯的實現，在實現業務邏輯的過程當中不須要考慮這個外圍的治理能力。

這些治理環節沉在框架裏，由框架團隊或平臺團隊來集中管控。

完善的監控體系能實時瞭解微服務的健康狀況對整個系統的可靠性和穩定性是很是重要的。

主要分爲5 個層次發監控：

1. 基礎設施監控（由運維團隊負責，網絡和交換機）- 網絡流量、丟包、錯包和鏈接數等
2. 系統層監控（物理機、虛擬機、OS） - CPU、內存、磁盤等
3. 應用層監控 – URL訪問性能（技術、延遲）、服務、數據庫SQL、Cache可用性（性能、命中率）、響應時間、QPS等
4. 應用層監控 – 登陸註冊、下單、支付等
5. 端用戶體驗監控 – 性能、返回碼、城市地區、運行商、操做系統等

5 個關鍵監控面：

• 日誌監控
• Metrics監控
• 健康檢查
• 調用鏈監控
• 告警系統

主流監控架構：

在主機或服務進程內安裝Agent，Agent負責收集機器和應用中的日誌和Metrics發送到咱們的監控系統。

當服務比較大、收集的日誌和Metrics量比較大時會加入隊列（Kafka）。標準的日誌監控棧 – ELK（Elasticsearch、Logstash、Kibana）；Metrics會採用時間序列數據庫（InfluxDB、Grafana呈現展現）

經過健康檢查機制來按期對應用的健康進行自動化的檢查，開源的工具備Nagios。

微服務的調用鏈監控該如何選擇

原理： 當請求進入Web容器時會生成一個Span（圖中Root Span），當繼續調用Service 時又會生成一個Span（Child Span），請求進來進入Service會生成一個Span，Service調用DB或其餘Service時會產生Span；Web應用在調用Cache時會產生Span。

Span是調用鏈造成的關鍵，在Span會有一些信息：Trace Id、Span Id等。Root Span比較特殊會生成Span Id和Trace Id，其餘的Span會生成本身的Span Id同時爲了維護調用鏈之間的父子關係Child Span會跟蹤記錄Parent Id。

在跨進程中爲了使調用鏈持續連接，會將Trace Id和Parent Id一塊兒帶過來。

主流開源的調用鏈工具對比：

微服務的容錯限流是如何工做的

Netflix Hystrix

熔斷： 這一律念來源於電子工程中的斷路器（Circuit Breaker）。在互聯網系統中，當下遊服務因訪問壓力過大而響應變慢或失敗，上游服務爲了保護系統總體的可用性，能夠暫時切斷對下游服務的調用。這種犧牲局部，保全總體的措施就叫作熔斷。

若是不採起熔斷措施，咱們的系統會怎樣呢？例子 當前系統中有A，B，C三個服務，服務A是上游，服務B是中游，服務C是下游。它們的調用鏈以下：

一旦下游服務 C 因某些緣由變得不可用，積壓了大量請求，服務B的請求線程也隨之阻塞。線程資源逐漸耗盡，使得服務B也變得不可用。緊接着，服務 A 也變爲不可用，整個調用鏈路被拖垮。

像這種調用鏈路的連鎖故障，叫作雪崩。

隔離： 是經過資源隔離減小風險的方式，源自貨船爲了進行防止漏水和火災的擴散,會將貨倉分隔爲多個, 以下圖所示。

軟件系統的隔離推薦的方法是進行服務拆分，讓每一個小業務獨立運行，即使是其中一個業務宕掉，其餘服務依然能夠正常運行。

限流： 提早對各個類型的請求設置最高的QPS閾值，若高於設置的閾值則對該請求直接返回，再也不調用後續資源。

降級： 當服務器壓力劇增的狀況下，根據實際業務狀況及流量，對一些服務和頁面有策略的不處理或換種簡單的方式處理，從而釋放服務器資源以保證核心交易正常運做或高效運做。

原理： 使用Hystrix 組件後，會將調用封裝在Hystrix Command內，封裝之後它就具備了熔斷、限流、隔離和降級功能。請求方式能夠是同步、異步或反應式的，請求過來後會作電路判斷：若是電路打開即斷路，會走降級流程調用降級函數。

若是電路閉合即沒有熔斷，而後進行線程/隊列資源判斷（若是資源不足，就會進入降級流程），若是前兩關經過就運行調用。在調用時若是運行超時也會走降級流程。執行成功（Success）獲取正確的相應結果返回調用端，失敗走降級流程。

在整個調用過程當中，任何一個環節的相關信息（電路是否打開、線程是否佔用、運行是否超時）都會以Metrics形式反饋給計算電路健康組件（Calculate Circuit Health）進而反饋給電路判斷（指導下一次關閉/打開電路的判斷依據）

Docker 容器部署技術 & 持續交付流水線

容器技術的優勢：

1. 環境一致性
2. 鏡像部署

流程： 開發人員提交代碼到Git，經過Jenkins 完成構建、單元測試和打鏡像並上傳到鏡像中心（Docker registry）。發佈到測試環境經QA測試後升級到UAT環境，通過UAT測試後升級到生產環境（生產環境可能會經過灰度發佈、藍綠部署發佈到生產環境）

藍綠部署 + 灰度發佈（經過軟路由切換流量）保證服務的穩定性：

容器集羣調度和基於容器的發佈體系

---

「極客閱讀 」匯聚了國內外最優質的技術博客、產品動態、公衆號文章。開發者能夠在極客閱讀一站式的閱讀到來自互聯網技術大咖的文章。

「極客閱讀 」官網：geeker-read.com