本文是極客時間《微服務架構核心20講》課程的學習筆記。

這個視訊作者架構師楊波的下面這篇文章也很不錯，喜歡的也可一併學習下。

微服務架構技術棧選型手冊 https://www.infoq.cn/article/micro-service-technology-stack

第1講 什麼是微服務架構

Martin flower在博文中給出的微服務的特點如下：

• 一組小的服務

• 獨立的程序

• 輕量級部署

• 基於業務能力（使用者服務、登入服務、商品服務）

• 獨立部署（每個團隊維護自己的服務，團隊之間不需要協調）

• 無集中式管理

Netflix前架構師給出的微服務的定義：

Loosely coupled（鬆散耦合，服務之間非強依賴）

Service Oriented architecture（本質上還是SOA）

with bounded context（服務之間有邊界，可獨立演化）

第2講 微服務的利弊

講了微服務的利和弊

微服務的利

• 強模組化邊界

• 可獨立部署

• 技術多樣性

微服務的弊

• 分散式複雜性（相對於單體應用，現在，細分成很多服務，開發人員無法理解整個系統是如何工作的。）

• 最終一致性

• 運維複雜性

• 測試複雜性（對於單體應用，直接測試整個系統功能就可以了；微服務後，各個系統分散在各個團隊，需要多個團隊聯調做整合測試。）

（我自己的理解：

關於微服務的利與弊，其實就是把一個系統細分為多個服務後，系統可看做整體，每個微服務可看做部分。好處是容易把控每個微服務自己，各個團隊負責自己的服務就好了，壞處就是對系統整體的把握上會出現一些不便，比如對系統整理的理解、對系統的測試等）

思考以下問題：

運維團隊，面對微服務的時候，應該採用什麼樣的手段來應對運維複雜性？

第3講 康威法則

康威法則：系統的架構等價於組織的架構。

（我自己的理解就是：

如果系統是單體應用，那麼應該是一個團隊負責。

如果系統微服務化以後，比如分為服務A，B，C，那麼組織架構上，也應當劃分為A，B，C三個團隊，每個團隊可獨立迭代。

)

思考以下問題：

作為架構師， 為什麼不僅僅要做技術架構，也要了解組織架構？

第4講 企業應該什麼時候引入微服務

單體優先原則：不宜過早引入微服務，因為系統初期對系統的未來發展無法預知，過早引入微服務風險較高。

（我自己的理解：

不要在系統初期直接上微服務架構，而是在系統演變過程中逐漸引入）

丟擲的問題：

架構是設計出來的還是演進出來的？

第5講 什麼樣的組織結構更適合微服務

傳統的組織架構：

一個產品需要產品團隊、使用者體驗團隊、研發專家團隊、測試專家團隊、DBA專家團隊、運維專家團隊等。

微服務組織架構：

每個微服務團隊end-end ownership，從開發到測試到運維等，統統自己負責，形成閉環

Archite--->Design--->Develo--->Reivew--->Test--->Deploy--->Run--->Support

思考以下問題：

Netflix前總架構師說了一句話，微服務架構本質上是組織架構的重組，你如何理解這句話？

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

大中臺，小前臺。 強化“技術中臺+業務中臺”，中臺肥沃，在這上面的業務生態才會更繁榮。業務應用更小更靈活，迭代能力變強，按照市場變化不斷演化新應用出來。

思考以下問題：

大中臺，小前臺戰略。每個架構師怎樣在每個公司內部實踐。

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

基礎服務：也叫核心領域服務、公共服務、中間層服務
聚合服務：也叫適配服務、邊界服務

第8講 微服務總體技術架構體系是怎樣設計的？

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

第1種：傳統基於LB的模式

使用硬體的F5負載均衡器、軟體的Nginx負載均衡器。

不足：1）服務配置、域名配置等需要運維介入 2）有一個集中LB，可能單點 

第2種：程序LB模式

不足：在多語言的環境當中，必須為每一個消費者開發響應的客戶端，升級成本、都語言支援成本比較高

第3種：主機獨立LB模式

將LB已獨立程序的方式部署在主機上，既不是集中式LB，也不是程序內LB。

當呼叫的時候，主機上的LB會負責負載均衡。

優點：1）沒有集中式LB的單點問題 2）對於呼叫方來說，多語言可以靈活地接入，無需為每種語言開發相應客服端

缺點：運維成本會比較高，因為在每臺主機上要部署LB程序

（這種其實就是在每臺主機上部署了個agent）

思考以下問題：

Service Mesh服務網格核心的點也是服務發現，那它使用了上面哪一種服務發現機制

第10講 微服務API服務閘道器(一)原理

微服務中為什麼要引入閘道器這個元件？

內部有許多微服務，由各自平臺來維護，外部訪問的時候需遮蔽細節，像是一個統一的服務。

為什麼閘道器前面引入一個負載均衡器？
在接入閘道器時有一個負載均衡器，其作用是讓閘道器是無狀態的，這樣的話，閘道器就可以部署很多，避免閘道器單點。

閘道器的職責：反向路由（將外面請求轉換為內部ms的呼叫）、安全認證、限流熔斷、日誌監控（流量訪問的日誌）

第11講 微服務API服務閘道器（二）開源閘道器Zuul

思考以下問題：

假如要設計一個防爬蟲的功能，應該放在Filter的哪個階段？Pre routing or Routing or Post Routing？

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

上面圖畫錯了，【外部nginx】應為【外部LB】，【內部nginx】應為【內部LB】

服務註冊中心：Eureka開源元件

閘道器層：Zuul開源元件

思考以下問題：

市面上有很多開源的元件，根據你的經驗，參考以上架構，怎麼來設計微服務架構服務發現體系？

第13講 集中式配置中心的作用和原理是什麼？

微服務中為什麼要引入配置中心？它的作用是什麼?

配置中心的配置如何下發到服務上？

1）push的方式

優點：可以實時更新。當配置修改了，就推送。

缺點：由於網路問題，可能導致沒有推送到。

2）pull的方式

優點：一定能拉到。即使網路出現了問題，下次也一定能拉到，保證獲取到最新的配置

缺點：非實時

3）push和pull相結合的方式

Spring cloud config、百度的difconf、攜程的Apollo

本地檔案快取的作用？高可用：即使Apollo配置中心掛了，服務重啟時，配置不會丟失。

配置中心配置下發採用push和pull相結合的方式。

第14講 微服務通訊方式 RPC vs REST

耦合性：

RPC是強耦合，採用定製的訊息格式，服務端和客戶端之間必須以特定的訊息格式進行通訊。

第15講 微服務框架需要考慮哪些治理環節

思考以下問題：

Dubbo是如何將這些功能融合在框架中的

第16講 微服務監控系統分層和監控架構

第17講 微服務的呼叫鏈監控該如何選型

第18講 微服務的容錯限流是如何工作的

熔斷、隔離

限流、降級

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

環境一致性問題

映象部署問題

第20講 容器叢集排程和基於容器的釋出