微服務筆記：百萬程式員都讀過的兩本書！

微服務相關的書籍多如牛毛，在衆多書籍中找出适合自己看的的确不易，這裡推薦兩本自己看過的，并整理了自己的讀書筆記分享給大家。

《微服務設計》

作者：[美] Sam Newman

這本書隻有200頁，但是麻雀雖小五髒俱全，完整介紹了微服務設計所涉及的各個方面。包括微服務的優點，微服務如何拆分，大規模微服務化的主機管理、服務部署、服務測試、服務安全、服務監控、服務治理以及康威定律。

• 服務拆分：微服務的拆分需要熟悉業務領域，常見的理論支撐是DDD，對于不熟悉的領域，作者不推薦太着急去服務化，而是保持單塊系統，随着對領域的熟悉逐漸拆分。而對于領域邊界十厘清晰的場景就可以進行細粒度拆分，進行大規模的服務化。保持服務的自治性和獨立部署性是基本原則。
• 服務管理：大規模服務化之後，自然帶來服務的如何管理的問題，是實體機、虛拟機、還是容器化部署。顯然容器化是未來的趨勢，因為容器資源占用更輕量級，啟動速度更快，适合服務的彈性伸縮。
• 服務監控：服務規模增大，複雜性急速增長，企業中服務可能成千上萬，出錯的機率也增大了，如何在出問題時快速定位邊界，就需要對服務調用鍊進行跟蹤，對服務調用名額進行采集，最好是以可視化圖表方式展示出來。
• 服務管控：服務調用鍊路需要在流量超過承載能力後，有容錯措施，比如對上遊服務限流、對下遊服務調用進行熔斷、下遊出問題時上遊直接降級等等。

• 服務測試：對于軟體開發工作來講，測試的重要性不言而喻。測試包括單元測試、服務測試、端到端測試粒度有低到高三個層次。單元測試可以通過持續內建CI能力融合進去，每次送出代碼後都自動一遍單測，可以快速回報開發問題。

  當然還有一些其他的内容，比如服務之間調用時同步還是異步，是采用rpc還是rest協定。以及康威定律講到的組織與軟體架構之間的關系，以及微服務架構下的安全如何去應對。還是推薦可以看一看，對微服務設計需要考慮的點有一個總體把握。

《微服務治理：體系、架構及實踐》

作者：李鑫

看完這本書最大的感受是兩個字—度量，有點像是度量驅動開發的味道。

• 度量驅動開發：告訴了微服務度量的核心名額有哪些，以及如何去度量這些名額的手段。比如對服務調用次數做彙總，而彙總又可以分為分鐘級、小時級别。
• 微服務架構魯棒性：然後，還寫了關于微服務架構魯棒性(或健壯性)的架構保障，指出業界魯棒性的設計原則：備援、彈性伸縮、單點無狀态、不可變基礎設施、故障傳導阻斷(比如熔斷、限流、降級、逾時、幂等等政策)、基礎設施即代碼等。其中，"單點無狀态"是彈性伸縮的前提條件。而"基礎設施即代碼"也是快速部署、彈性伸縮的前提條件。**“基礎設施即代碼”**提供了一個虛拟層，屏蔽了底層資源比如伺服器、網絡、配置、DNS、CDN、防火牆、日志、監控等資源或者服務對于使用者的差異。并将其抽象為一個虛拟世界的對象，通過程式設計的方式可以對這些對象進行編排和整合、排程。**使用者通過這個虛拟層可以将大規模的部署指令化、程式化！**這樣以來，基礎設施才能快速響應快速疊代的産品需求，研發團隊更高效的持續傳遞、devops才成為可能！
• 叢集容錯：叢集的容錯機制有很多如failsafe提供的“調用永遠正确”的機制，即當出現調用異常時傳回一個新建構的結果。還有FailOver失敗轉移機制、Failback失敗重試機制，此模式以固定的時間間隔重新發起遠端調用。這裡需要注意叢集容錯和容錯降級的差別：叢集容錯是用于保證遠端調用的可靠性，而容錯降級是為了保障業務的可用性。

• 服務線上生命周期管理：比如服務的優雅停機、藍綠釋出、灰階釋出、金絲雀測試這些概念。

  ☆藍綠釋出的意思是調整路由及負載均衡政策，将流量統一切換到新版本（綠叢集），但舊服務（藍叢集）不下線。此時兩套叢集并存，隻是舊叢集沒有流量，一旦新版本服務出現異常，通過調整路由及負載均衡政策，快速切換回舊版本（藍叢集）。

  ☆灰階釋出其實是将流量分批次平滑釋出，逐漸擴大範圍，同時将標明的線上流量路由到新版本上，實時收集回報驗證釋出效果，以決定是繼續釋出還是復原。

  ☆那麼什麼是金絲雀測試呢？套用書中的原話：“在灰階釋出中，第一批（或前N批）釋出的服務節點及被切流到該節點上的使用者流量具有特殊意義，它們往往扮演了“先行者”的角色，大部分異常都能在第一批釋出中被發現。由于第一批（前N批）釋出的範圍非常小（一般不超過1%），影響範圍有限，是以又把第一批（前N批）釋出單獨稱為“金絲雀測試”。”

• 服務線上穩定性保障

  ☆ 梳理線上故障場景，根據發生機率排序并制定預案。

  ☆ 預案的效率優先級排序，比如應對大流量場景是擴容，還是限流，各有什麼優劣？

  ☆故障演練，保證出問題時候不手忙腳亂！

  ☆故障複盤，建議全員參與，避免公開指責某個人或團隊。

  此外，還提到了混沌工程，它的本質是制造故障和脆弱點并改進。

• 架構治理：主要涉及服務分層如何演進，比如通用業務層拆分出來形成業務服務層**，個性化功能中與業務無關的部分可以拆分出來，比如協定适配、拆包、安全校驗等拆出來跟網關層合并為 安全網關層，然後就是對業務服務層及通用服務層功能的組裝和聚合的“聚合服務層”。

  

  每個服務分層涉及的業務域各不相同，分工也不同。

  ⭐️通用服務層跨多個業務域，面向整個企業的業務提供共性的服務，比如在基金行業，通用服務層同時給直銷、代銷、高端理财這些不同的業務域提供通用服務。

  ⭐️業務服務層的範圍則被控制在單個業務域之中，比如直銷業務域會根據業務特色形成獨有的業務服務層。不同業務域的業務服務層之間不存在複用關系，如果某個業務域下的服務能夠被其他業務域複用，就應該把它繼續下沉到通用服務層。

  ⭐️聚合服務層**更多和管道關聯，它承載的業務邏輯很少，主要起到對業務服務層和通用服務層的服務進行聚合群組裝的作用。

  是以，聚合服務層、業務服務層、通用服務層三層服務分層的定義換個說法就是：業務前台服務層、業務中台服務層和通用背景服務層。

  在服務分層架構下，各層的服務并不是靜止不動的，通用服務會被不斷下沉。是以越底層的服務抽象度越高，也越通用、越靜态，不會經常改變；越靠近前端的服務越貼近業務，越不穩定，會随着業務的快速變化而不斷改變，客觀上也必須保持更“輕”的體态。

  可以将前台服務拆分得更細，讓前台服務不用通過大量的代碼來處理業務邏輯，隻需要少量的黏合劑代碼來對中台專屬業務領域的通用服務和背景跨業務領域的通用服務進行快速組裝和聚合，從根本上降低了前台服務開發的工作量和成本。

• 研發治理：如設計評審、代碼評審、自動化測試、單元測試、微服務下的調測問題。

• 運維治理：線上和線下環境隔離，持續內建環境搭建等

  ⭐️持續內建是在源代碼變更後自動檢測、拉取、建構和單元測試的過程。持續內建的目标是快速確定開發人員新送出的變更是正确的，新代碼和原有代碼可以準确地內建在一起，并且适合在代碼庫中進一步使用。

  ⭐️持續傳遞：持續內建獲得的構件主要經過單元測試及部分內建測試，這些測試隻能證明分支代碼的合并是沒有問題的，但不能保證構件的整體品質能達到産品要求，還必須将其部署到測試環境中進一步驗證，這時就需要通過持續傳遞流程來基于持續內建生成的構件生成最終部署構件，并結合配置管理将其部署到各種測試環境中，對其進行功能及性能驗證。持續傳遞利用持續內建生成的構件及其他必要構件進行內建編譯或組裝，生成部署構件，并對部署構件及其依賴的上遊服務、資料庫、緩存、消息隊列等資源進行內建測試，以驗證部署構件是否能夠正常工作，以及是否滿足性能上的要求。通過嚴格測試的部署構件就可以根據需要釋出到構件庫，随時被用于生産環境部署.

  ⭐️持續部署：通過持續傳遞環節獲得部署構件之後，就可以實施持續部署。持續部署的目标是把部署構件釋出到生産環境中，但這個過程并非一撮而就的。如果有預發環境，首先會把部署構件部署到預發環境進行驗證，驗證通過後再進行生産部署。

  持續傳遞主要確定有可用于部署的構件，但不一定要部署，重在展現一種能力；持續部署則是一種行為，是價值落地的手段。