本文是極客時間《微服務架構核心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講 容器集群調度和基於容器的發布
