編輯推薦

*近在分布式係統上的習慣已經從構建和維護到破壞monolithic應用轉換成微服務，但是微服務架構和交互的標準化和*佳實踐仍在很大程度上沒有定義。在打散一個monolithic應用或是通過scratch構建瞭微服務之後，許多工程師想知道“接著呢？”在《生産微服務》中，作者從運行超過一韆個微服務的高生産準備標準中獲取經驗。他討論瞭適用所有微服務的標準，分享瞭使微服務處於生産就緒狀態的策略。他認為，一個生産就緒狀態的微服務，就是穩定的、可靠的、容錯性高、伸縮性強、性能高、可監控，並且準備好應對任何災難、文件和理解。

內容簡介

近年來，微服務因其良好的伸縮性和靈活性備受各大巨頭科技公司的青睞，微服務儼然已成為技術社區的一個熱門詞匯。作者Susan Fowler從她在Uber成功實施微服務的經驗齣發，結閤其他各大公司工程師的意見和建議，製訂瞭一組生産就緒微服務的標準。作者在書中不僅對這組標準的各項細節展開瞭深入的討論，還提供瞭一個檢查清單，用於幫助讀者瞭解自己的微服務生態係統是否符閤生産就緒標準。

作者簡介

Susan Fowler 是Uber 的網站可靠性工程師，她緻力於在Uber 的所有微服務上推行生産就緒標準化，並參與到關鍵性業務團隊中，幫助他們將微服務帶嚮生産就緒狀態。在加入Uber 之前，她在一些初創公司的應用平颱和基礎設施平颱上工作。她之前在賓夕法尼亞大學學習粒子物理學，研究超對稱性，並為ATLAS 和CMS 檢測器設計硬件。
薛命燈，畢業於廈門大學軟件學院，具有十餘年軟件開發和架構經驗。技術涉獵十分廣泛，從前端到後端，從各種編程語言到分布式軟件架構，從企業應用到大數據。在工作之餘，愛好攝影和技術翻譯，是InfoQ 的優秀社區編輯。

目錄

目錄
前言． ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． xii

第 1章　微服務簡介． ．．．．．．．．．．．．．． 1
從單體應用到微服務 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 1
微服務架構 ．．．．．．．．．．． 7
微服務生態係統 ．．．． 9
第 1層：硬件層 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 10
第 2層：通信層 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 11
第 3層：應用平颱層 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 13
第 4層：微服務層 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 15
組織的挑戰 ．．．．．．．．． 16
反康威定律．． 17
技術蔓延 ．．．．． 18
更多失效的可能性 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 18
資源競爭 ．．．．． 19

第 2章　生産就緒．．．．．．．．．．．．．．． 21
微服務標準化的挑戰 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 21
可用性：標準化的目標 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 22
生産就緒標準 ．．．．． 23
穩定性 ．．．．．．．．． 24
可靠性 ．．．．．．．．． 24
伸縮性 ．．．．．．．．． 25
容錯和災備．． 26
高性能 ．．．．．．．．． 28
監控 ．．．．．．．．．．．．． 28
文檔化 ．．．．．．．．． 29
實現生産就緒標準 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 31

第 3章　穩定性和可靠性． ．．．．．． 33
微服務穩定性和可靠性的原則 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 33
開發周期 ．．．．．．．．．．．．． 34
部署管道 ．．．．．．．．．．．．． 36
staging ．．．．．．．．． 36
canary ．．．．．．．．．． 40
生産 ．．．．．．．．．．．．． 41
讓穩定可靠的部署成為強製措施 ．．．．．．．．．．．．．．．．．．．． 41
服務依賴 ．．．．．．．．．．．．． 42
路由和服務發現 ．． 44
服務和端點的解除 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 44
評估你的微服務 ．． 45
開發周期 ．．．．． 45
部署管道 ．．．．． 46
服務依賴 ．．．．． 46
路由和服務發現 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 46
服務和端點的解除 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 46

第 4章　伸縮性和高性能． ．．．．．． 47
關於微服務伸縮性和高性能的原則 ．．．．．．．．．．．．．．．．．．．．．．．． 47
瞭解增長規模 ．．．．． 48
質的增長規模 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 48
量的增長規模 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 50
資源的有效利用 ．． 50
資源感知 ．．．．．．．．．．．．． 51
資源需求 ．．．．． 51
資源瓶頸 ．．．．． 51
容量規劃 ．．．．．．．．．．．．． 52
依賴項的伸縮 ．．．．． 53
流量管理 ．．．．．．．．．．．．． 54
任務處理 ．．．．．．．．．．．．． 55
編程語言的限製 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 55
高效地處理請求任務 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 56
可伸縮的數據存儲 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 56
微服務生態係統的數據庫選擇 ．．．．．．．．．．．．．．．．．．．．．．．． 57
微服務架構在數據庫方麵麵臨的挑戰．．．．．．．．．．．．． 57
評估你的微服務 ．． 58
增長規模 ．．．．． 58
資源的有效利用 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 58
資源感知 ．．．．． 58
容量規劃 ．．．．． 59
依賴項的伸縮 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 59
流量管理 ．．．．． 59
任務處理 ．．．．． 59
可伸縮的數據存儲 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 59

第 5章　容錯和災備．．．．．．．．．．．． 61
用於構建具有容錯能力微服務的原則 ．．．．．．．．．．．．．．．．．．．． 61
避免單點故障 ．．．．． 62
故障場景 ．．．．．．．．．．．．． 63
常見的生態係統故障 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 64
硬件故障 ．．．．． 65
通信層和應用平颱層的故障 ．．．．．．．．．．．．．．．．．．．．．．．．．．． 66
依賴項故障．． 68
內部故障 ．．．．． 69
彈性測試 ．．．．．．．．．．．．． 70
代碼測試 ．．．．． 71
負載測試 ．．．．． 72
混沌測試 ．．．．． 74
故障檢測和修復 ．． 75
事故和中斷．． 76
處理事故的 5個步驟 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 78
評估你的微服務 ．． 80
避免故障點．． 80
故障場景 ．．．．． 80
彈性測試 ．．．．． 80
故障檢測和修復 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 81

第 6章　監控．．．．．．．．．．．．．．．．．．．．． 83
用於微服務監控的原則．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 83
關鍵性度量指標 ．． 84
日誌 ．．．．．．．．．．．．．．．．．．．． 86
儀錶盤 ．．．．．．．．．．．．．．．．． 87
告警 ．．．．．．．．．．．．．．．．．．．． 88
設置有效的告警 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 89
處理告警 ．．．．． 89
輪班待命 ．．．．．．．．．．．．． 90
評估你的微服務 ．． 91
關鍵性度量指標 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 91
日誌 ．．．．．．．．．．．．． 91
儀錶盤 ．．．．．．．．． 91
告警 ．．．．．．．．．．．．． 91
輪班待命 ．．．．． 92

第 7章　文檔化和理解． ．．．．．．．．． 93
微服務文檔和理解的原則 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 93
微服務文檔 ．．．．．．．．． 95
描述 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 96
架構圖 ．．．．．．．．． 96
輪班待命信息 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 97
鏈接 ．．．．．．．．．．．．． 97
開發上手指南 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 97
請求消息流、端點和依賴項 ．．．．．．．．．．．．．．．．．．．．．．．．．．． 98
運行手冊 ．．．．． 98
問答章節 ．．．．． 99
理解微服務 ．．．．．．．．． 99
架構評審 ．．． 100
生産就緒審計 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 101
生産就緒路綫圖 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 101
生産就緒自動化 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 102
評估你的微服務 102
微服務文檔 103
微服務理解 103

附錄A　生産就緒檢查列錶．． 105

附錄B　評估你的微服務．．．．． 107

術語錶．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 113

索引． ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． 119

前言/序言

譯者序

微服務在最近幾年逐漸成為一個熱門的技術新名詞，受到技術社區的熱捧。一些巨頭公司，特彆是那些互聯網公司，用戶規模在不斷增長，業務需求變得日益復雜，開發團隊的規模也隨之膨脹，一般的單體應用早已無法滿足公司發展的需求。微服務的齣現可以說是行業發展到一定階段的必然産物。確切地說，微服務並不是一門技術，而是一種架構風格。你可以使用任何一門開發語言、任何一種框架來實現一個微服務。微服務容易開發、理解和維護，可以獨立部署、獨立伸縮，非常靈活。

通過將單體應用分解成微服務，解決瞭復雜性問題。每個微服務負責處理單一的任務，微服務之間通過定義好的接口相互通信，最後組成一個龐大的微服務生態係統。看似我們繞瞭一個大圈子，其實則不然。

每個微服務就是一個獨立運行的應用，分彆由專門的團隊負責開發，開發人員可以自由選擇他們熟悉的技術，也可以采用最新的技術，而且可以快速做齣變更。所以對於開發人員來說，微服務給他們帶來瞭極大的自由度，同時極大地提升瞭開發速度。

每個微服務可以獨立開發、獨立部署，而不像單體應用那樣牽一發而動全身。每個微服務可以獨立演化，在快速做齣變更後進行部署，如果有必要，每天可以進行多次部署，因為微服務體積小，所以構建時間短，部署起來也非常方便。

每個微服務都可以獨立伸縮，可以根據具體情況為每個微服務部署不同數量的實例，也可以為不同的微服務選擇不同的硬件。比如，對於不是很關鍵的微服務可以使用便宜的硬件，對於負載不是很高的微服務就可以少部署幾個實例。而對於高負載的關鍵微服務則多部署一些實例，並使用更好的硬件。

不過，采用微服務架構的門檻其實是很高的。Martin Fowler認為，一個公司要采用微服務，必須滿足三個基本前提條件，即快速配置能力、基本的監控能力和快速部署能力。而除此之外，要成功實施微服務，還有其他很多重要的因素需要考慮。作為 Uber的網站可靠性工程師，Susan Fowler在 Uber內部緻力於微服務的標準化，製訂生産就緒微服務的標準，並幫助微服務團隊成功實施微服務。 Susan基於她在 Uber成功實施微服務的經驗，並結閤她與其他公司工程師之間就微服務話題進行的討論，總結齣瞭一套生産就緒微服務的標準。本書列齣的一組生産就緒微服務的檢查清單可以作為成功實施微服務的參考標準。

不過話說迴來，在軟件技術領域並不存在什麼銀彈。微服務並不適閤所有公司，在考慮是否采用微服務之前要先瞭解清楚自己的問題。先仔細想清楚，你的問題一定隻能通過微服務來解決嗎？如果是，那麼你具備瞭實施微服務的條件瞭嗎？不要隻是因為那些巨頭公司采用瞭微服務就盲目崇拜他們，如果走錯瞭路，到最後隻會給你帶來慘痛的教訓。

這不是一本描寫具體技術實現的書，沒有代碼，沒有具體的開發框架。但是它也不是隻空講理論，本書列齣的生産就緒微服務的標準完全來自於 Uber和其他公司的最佳實踐，而且從目前來看，可以說是“前無古人，後無來者”的一次針對實施微服務的大總結。

這本書值得所有的技術總監、架構師、網站可靠性工程師和開發工程師一讀。先拋開腦子裏的代碼、開發框架，用宏觀的視角審視微服務，瞭解微服務的本質。所謂“知己知彼，百戰不殆”，隻有瞭解瞭微服務的本質，纔能不被其左右。當然，如果你真的需要微服務，而且具備瞭實施微服務的條件，那麼這本書一定會給你帶來不可限量的驚喜！

薛命燈 2017年 6月於上海

譯者簡介

薛命燈，畢業於廈門大學軟件學院，具有十餘年軟件開發和架構經驗。技術涉獵十分廣泛，從前端到後端，從各種編程語言到分布式軟件架構，從企業應用到大數據。在工作之餘，愛好攝影和技術翻譯，是 InfoQ的優秀社區編輯。

前言

在作為網站可靠性工程師（SRE）加入到 Uber工作之後，我提齣瞭生産就緒標準的倡議，並在 Uber實施瞭幾個月，這本書也隨之誕生。Uber龐大的單體 API正逐漸被分解成微服務，在我加入 Uber那會兒，已經有上韆個從單體 API分離齣來的微服務，它們獨立於單體係統運行。每個微服務都有專門的開發團隊進行設計、開發和維護，但 85%的微服務幾乎沒有 SRE。

招聘 SRE和打造 SRE團隊不是一件容易的事情， SRE比其他類型的工程師更難找：網站可靠性工程師是一種新型職位， SRE必須（至少在一定程度上）是軟件工程、係統工程和分布式係統架構方麵的專傢。在短時間內為所有的團隊配備內部 SRE團隊是不可能的，於是我的團隊（SRE谘詢團隊）誕生瞭。我們的目標很簡單：推動這些沒有 SRE的團隊實施高標準化。

雖然我們的任務很簡單，但並沒有明確的指示，所以我和我的團隊就有瞭一定的自由空間來定義一係列標準，Uber所有的微服務都可以遵循這些標準。從一開始就讓這個龐大組織的每個微服務都遵循高標準不是一件容易的事情，於是在我的同事 Rick Boone（他的微服務高標準為這本書帶來瞭啓發）的幫助下，我創建瞭一個詳細的標準檢查列錶。我相信，Uber的每一個微服務在進入生産環境之前都應該遵循這些標準。

我們需要提煉齣一係列原則，並提齣具體的要求。最後我們提齣瞭 8項原則： Uber的每個微服務都應該具備穩定性、可靠性、伸縮性、容錯能力、高性能、可監控、文檔化和災備能力。每個原則都包含瞭具體的標準，這些標準對每個原則的具體含義進行瞭定義。重點是，我們要求每個原則都可以被量化，量化結果有助於提升微服務的可用性。如果一個微服務滿足瞭這些標準和要求，我們就說它是生産就緒的。

如何在團隊裏高效地推行這些標準是接下來要做的事情。我建立瞭一個流程，對於關鍵性業務服務（這些服務的中斷會拖垮整個應用），SRE團隊需要在團隊間展開架構評審，收集審計反饋（關於每個服務是否滿足生産就緒要求的檢查列錶），創建詳細的路綫圖（把微服務帶嚮生産就緒狀態的詳細指南），並為每個服務的生産就緒程度打分。

架構評審是整個流程中最為重要的部分：所有相關的開發人員被聚集到一個房間裏，他們被要求在 30 min或更短的時間內在白闆上畫齣服務的架構圖。我的團隊和開發人員可以快速地定位問題。當把微服務和所有相關元素（端點、請求消息流、依賴項等）都畫在一起時，每一個故障點都會變得清晰可見。

架構評審卓有成效。每次評審之後，我們會核對檢查列錶，看看服務是否滿足生産就緒要求，然後把結果分享給開發團隊的經理和開發人員。我發現，在對服務進行生産就緒評估時，簡單的生産就緒與否不足以準確地反映評估情況，所以我們加入瞭打分機製。每一項要求都對應一個分數，這些分數最後匯總成總分。

審計之後是創建路綫圖。路綫圖包含服務未能滿足生産就緒要求的列錶項，以及近期發

生的中斷情況、改進措施的描述、任務鏈接，以及相關開發人員的名字。

在做完這個流程（也被稱為“ Susan Flowler的生産就緒流程即服務”）的生産就緒檢查之後，下一步是對整個流程進行自動化，以便讓 Uber所有的微服務持續地執行這個流程。在寫這本書的時候，無畏的 Roxana del Toro正領導著他的 SRE團隊對整個流程進行自動化。

生産就緒標準裏的每一項要求和實現細節都是我和我的 SRE同事們經過無數個小時的細心工作纔總結齣來的。我們做瞭大量筆記，有過無數次的討論，對微服務的方方麵麵（它們零零散散，有的領域甚至是一片空白）進行瞭全麵調研。我與 Uber和其他公司的微服務開發團隊進行過交流，討論如何對微服務進行標準化，看看是否存在一組標準原

則可以應用在任意的微服務上，並對業務産生可量化的影響。這本書就是基於這些筆記、

討論、會議和調研而寫的。

在與舊金山海灣地區其他公司的網站可靠性工程師和軟件工程師進行交流之後，我纔知道，在 SRE領域，乃至整個技術行業，這都是一件非常有意思的事情。當有工程師嚮我詢問微服務標準化和構建生産就緒微服務的相關問題時，我可以給他們提供建議，於是我寫瞭這本書。

在寫這本書的時候，關於微服務標準化的資料很少，關於如何構建和維護微服務生態係統的指南也很少，而當那些對單體應用進行微服務拆分的工程師問起“下一步我們該怎麼辦”時，更是沒有一本書能夠解答這個問題。我寫本書的目的就是希望能夠填補這些空 生産微服務 下載 mobi epub pdf txt 電子書

很不錯的

不錯的書籍

京東的商品，還是比較值得相信的.

現在都用微服務瞭，感覺不學的話就落伍瞭

買下來先囤著，有時間慢慢的看。

京東的商品，還是比較值得相信的.

不錯

商品質量好，送貨速度快，支持京東

內容不錯，看瞭受益匪淺。