前言

隨著互聯網對各個行業的深度滲透，它對行業的改變除了使行業有了新的業務形式，還有對業務更新節奏的提速，近兩年在與處于各種不同行業的朋友的交流中，感受最深的一點就是“這世界變化太快了”，如果前兩年這種“快”的影響還只在互聯網領域，那么現在幾乎所有的行業都已經被裹挾到這個浪潮中來了，而“微服務”便是在這樣的大勢之下應運而生，由前兩年互聯網公司的“玩具”轉變為被更多企業級IT系統所接受和嘗試東西，

從計算機的發展歷史來看，微服務是一一個新生產物，但它不是從石頭縫里突然蹦出來的，它的設計思想其實是分布式系統與SOA的延續，同時又汲取了DevOps、持續集成、持續交付等工程實踐，并借著云計算和容器化的春風開始了它的馳騁之旅，因此，要做好微服務架構，既需要在業務和技術方面鉆研得夠深，又需要具有涵蓋整個生命周期的廣博知識，但兩者很難兼得，但本書的內容恰恰在這兩方面都得到了很好的體現，我想，這一方面得益于本書已是第2版，在前一版全面介紹微服務架構的基礎之上，是一次體 系化的精進，內容臻于成熟，華為親身經歷的眾多大型專案，識訓了大量實踐微服務架構的經驗，

與時俱進，從Martin Fowler提出“微服務”概念至今，不過三、四年時間，這其中已經誕生了許多能“呼風喚雨”的平臺和框架，在軟體設計領域，實作技術瞬息萬變，唯有設計思想方能歷久彌新，

下面我們就進入微服務架構之美吧

微服務架構與實踐

目錄

第一部分、基礎篇

第1部分為基礎篇，介紹應用架構的演進歷程以及微服務誕生的背景，并通過對微服務概念、特征的探討，幫助讀者深刻理解微服務的本質，同時，本部分的內容也客觀地闡述了實施微服務時所面臨的挑戰，

• 軟體架構發展回顧以及微服務誕生的背景，
• 微服務架構的本質及落地時面臨的挑戰，
• 微服務與SOA、Serverless 的關系，
• 下一代微服務Service Mesh.

微服務架構綜述

單體架構( Monolithic Architecture )

計算機科學領域自成立以來就遇到了與復雜性有關的問題，開發人員通過選擇正確的資料結構，開發演算法以及應用關注點分離的概念來解決早期的復雜問題，當時的企業組織結構多為功能型組織，同時服務只能部署在性能、可靠性強大但價格不菲的大型機上，在這樣的條件下，應用的呈現、邏輯處理和資料存盤等功能，都集中部署和運行在同一臺服務器上，通常稱為單體架構，

分層架構( Layered Architecture )

隨著服務器開始在Web世界中承擔更多的職責，如服務UI、事務處理、資料存盤等，由于受到面向程序的思維及設計方式的影響，所有的邏輯代碼并沒有明顯的區分，因此代碼之間的呼叫相互交錯，錯綜復雜，

微服務架構的特征

從業界的討論來看，微服務架構的特征通常包括以下六個部分:

• 服務作為組件
• 圍繞業務組織團隊
• 關注產品而非專案
• 技術多樣性
• 業務資料獨立
• 基礎設施自動化

Serverless的應用場景

第二部分、策略篇

從概念的維度看，微服務架構是一種架構模式，但從實作的維度看，微服務的落地程序絕不能僅關注微服務架構本身，實際上，微服務的落地程序通常會涉及IT領域過去多年的“最佳實踐集”，包括但不限于持續集成、敏捷實踐、運維自動化、測驗自動化、DevOps 以及全功能團隊等，對于落地微服務的團隊而言，如何系統化地、有效地應用這些實踐呢?優先考慮哪些實踐，哪些實踐依賴于其他實踐呢?

針對上述這些問題，本書的第2部分將重點講述微服務落地的思路和實作方式，其主要內容包括:

• 如何系統化地理解微服務全景圖一微服務 生態系統，
• 什么是微服務實施參考模型，以及如何通過參考模型循序漸進地制定微服務演進路線，
• 在微服務演程序序中，涉及哪些重要的實踐，如自動化測驗、部署管理、運維等，
• 對遺留系統進行改造的方式，如絞殺者模式，以及改造案例，

微服務生態系統

基于筆者過去的經驗，在幫助企業實施微服務的程序中，如果只是從架構解耦的角度入手，很難產生效果，從架構上看，微服務架構雖然是一種架構模式，但從實作上看，已經不能僅僅關注架構本身，需要從分布式、流程、工具、組織、文化、DevOps以及端到端的整體交付等考慮，這其實就是筆者所理解的微服務生態系統，構建好微服務生態系統，微服務的落地才能事半功倍，才能更高效地為業務創造價值，

 

微服務生態系統的核心內容

微服務生態系統主要包括兩部分，即核心內容和工程實踐，如圖2-2所示，其中，核心內容是微服務演程序序中的重要部分，包括注冊發現、配置管理、監控告警、日志聚合、呼叫鏈等內容，工程實踐是微服務演進中的重要保障，包括交付流水線、開發框架，以及工程實踐(全功能團隊的落地實踐)，

 

微服務關鍵技術

然而在微服務的實施程序中仍將面臨許多挑戰，例如如何設計出合理的微服務架構，以便高效地實作業務需求，同時，隨著服務數量的增多，如何有效地實作大規模微服務的治理和運維，也會成為新的挑戰，

 

服務劃分

基于非功能性因素

CQRS的實作方案

三階段提交

針對兩階段提交的問題，主要是協調者失敗引發的問題，三階段提交進一 步將準備階段又劃分為兩個階段，并引入了超時策略來緩解阻塞的問題，所以三階段提交就變成了:確認能否進行事務操作、預提交和提交，

 

TCC模式

在微服務的分布式場景下，業務運行流程可能較長，采用傳統ACID的事務方式會造成運行等待時間過長，除了前面提到的2PC/3PC的事務處理方式，還可以采用事務補償的方式，即先執行正常的業務邏輯，當出現問題時，如流程中某些環節出錯，再執行補償的動作，即取消或者重試，

 

微服務參考模型

微服務參考模型梳理了產品在微服務實施程序中的適用性評估、成熟度參考、度量體系以及能力提升計劃，旨在幫助團隊盡早識別微服務實施程序中的風險，并有效地推進微服務相關實踐的落地，

程序類度量指標

程序類度量指標又稱輔助類度量指標，是團隊實施微服務程序中的“放大鏡”，能有效觀察區域改進的效果，衡量的是團隊在某個方面的能力提升和水平高低，對于交付程序中各個區域環節，筆者推薦的程序類度量指標如下表所示，筆者可以根據具體場景，采取部分或者全部指標進行度量，

基于參考模型的實踐

有了充實的理論基礎、豐富的工具以及明確的目標，如何在這些基礎上，以多、快、好、省的方式，落實理論，選擇合適的工具，就變成了實際的問題，本章將從微服務團隊、核心敏捷實踐、服務設計與實作、運維管理、測驗管理、交付流水線、部署管理等維度出發，介紹筆者過去對不同專案實施微服務的實踐，這些實踐曾經幫助筆者在多個團隊中順利完成架構、組織的演進和工程能力的提升，希望這些內容能對讀者有所啟發和幫助，提高微服務實施的投入產出比，

 

作業任務可視化

架構即代碼

監控機制

通過資料流水線統監控方式

對微服務測驗的系統化思考

與測驗活動相關的角色劃分與協作

構建服務靜態依賴圖

由于內容細節過多就不一一展示了

遺留系統的微服務改造

隨著時間的推移，遺留系統的維護和管理的成本越來越大，在向微服務架構全面轉型的程序中，這些遺留系統就像一只只“攔路虎”，阻擋微服務轉型之路，如何在不影響業務的同時，以更安全、更高效、更低成本的方式將這些遺留系統進行微服務改造，使之順利融入微服務架構，并充分利用到微服務架構的優勢呢?本章將詳細介紹如何解決遺留系統的微服務改造問題，

絞殺者模式

遺留系統改造場景

第三部分、實戰篇

在本書的第1部分基礎篇中，闡述了微服務架構的理論基礎以及其本質，理解這部分是落地微服務化的前提:在第2部分策略篇中，探討了微服務生態系統、微服務參考模型以及相應的工程實踐，幫助讀者有效地落地微服務:在第3部分實踐篇中，將以開源專案SockShop 為背景，探討如何使用ServiceComb作為開發框架，ServiceStage作為基礎設施，構建SockShop系統，本部分的主要內容包括:

• ServiceComb與Service Stage綜述，
• SockShop系統的分析、設計以及服務實作，
• SockShop系統的部署、編排以及服務治理，

微服務開發框架ServiceComb

微服務云應用平臺ServiceStage

AOS編排服務

SockShop系統分析與設計

建立統一語言

架構設計

實作SockShop系統的第一個服務

本章將介紹SockWorks團隊，如何實作SocksShop系統的第一. 個服務，并完成端到端的自動化測驗、打包、部署及發布程序，

商品服務自動化測驗

實作SockShop系統的其他服務

運行SockShop系統

部署SockShop系統

運維SockShop系統

ServiceStage相關概念

集群:一個集群指容器運行所需要的云資源組合，關聯了若干云服務器節點、負載均衡等云資源，

節點:每一個節點對應-臺虛擬機， 容器應用運行在節點 上，節點上運行著代理程式( kubelet),用于管理節點上運行的容器實體，節點規格最小是CPU為lcore,記憶體為2048MB;最大是CPU為32core,記憶體為128GB，

容器:一個通過Docker鏡像創建的運行實體，一一個節點可運行多個容器，

Docker鏡像:Docker鏡像是容器應用打包的標準格式，在部署容器化應用時可以指定鏡像，鏡像可以來用于ServiceStage 公有倉庫，或者用戶的私有鏡像，

Pod: 以組容器(一個或者更多)，共享網路和存盤，并且包含容器如何運行的規范，

編排:編排模板包含了一組容器服務的定義和其相互關聯，可以用于多容器應用和虛機應用的部署和管理，

設計包:運維人員對應用的拓撲、生命周期管理計劃進行設計，并輸出堆疊模板(也可稱為應用設計包)，

設計器:圖形化設計器工具，用戶可通過拖拽方式完成復雜應用的編排及拓撲設計，可以保存成堆疊模板，使用堆疊模板創建堆疊，簡化應用部署難度，提升效率，

堆疊模板:堆疊模板是對堆疊的描述，包括基于應用模型的堆疊拓撲定義、堆疊生命周期描述、運行時資源描述、軟體組件描述等，堆疊模板通過設計包創建而來，本質與設計包相同，

堆疊:由應用、服務、資源等元素組成的一個部署實體，平臺將相關編排元素通過“堆疊”進行集中管理，

容器應用:一個容器應用可通過單個鏡像或一個編排模板創建，每個容器應用可包含1個或多個容器，和Kubenetes Pod的概念等同，

倉庫:倉庫包括鏡像倉庫和軟體倉庫，鏡像用于容器類應用，軟體包用于虛擬機或物理機應用，用戶在創建應用前，需要將應用所需的鏡像或軟體包上傳到倉庫中，

各個模塊的關聯和關系:

• 一個集群由多個節點組成，
• 一個節點上可以部署多個應用，
• 一個應用由一個或多個容器部署而成，
• 堆疊是由應用、服務、資源等元素組成的一個部署實體，

AK(AccessKeyID):訪問密鑰ID，與私有訪問密鑰關聯的唯一識別符號:訪問密鑰ID和私有訪問密鑰一起使用，對請求進行加密簽名，

SK (Secret Access Key): 與訪問密鑰ID結合使用的密鑰，對請求進行加密簽名，可標識發送方，并防止請求被修改，

密鑰(Key Pair): SSH 密鑰對，用于ECS主機初始化時使用，方便用戶通過SSH免密登錄，

總結

隨著數字化轉型的推進，越來越多的企業開始嘗試基于微服務框架構建和重構自己的系統，微服務實施不僅僅是微服務框架的技術選型和服務拆分，它涉及到方方面面，是一個系統化的體系工程，本書從架構演進、微服務拆分、介面契約測驗，流水線構建到微服務實戰，涵蓋了微服務實施程序中的重要環節，是一本難得的系統化、全面介紹微服務的書籍，值得大家認真研讀，

這份【微服務架構與實踐2】筆記檔案共為515頁，需要完整版的朋友，可以點贊此文關注小編，【掃碼后】即可獲取！！

標籤：其他

上一篇：flink 處理實時資料的三重保障

下一篇：華為技術官又曝神作，兩份堪稱‘千古絕唱’作業系統筆記現已瘋傳