書摘《高品質微服務》

圖片來源：Amazon

第一章 微服務

採用微服務的公司的組織架構必須大幅的改變以配合微服務架構，而團隊架構也會有計列的變化。但微服務架構最大的挑戰是服務架構與每個微服務的可信賴和可用性需求的標準化。 _{p. 1}

微服務是小元件，容易替換、可獨立開發、可獨立部署。但微服務無法單獨生存 — 微服務不是孤島 — 它是大型系統中與其它微服務協同工作已完成以前通常有單獨一個應用程式完成的工作。 _{p. 5}

儘管可能有許多正確的方式將一整塊分解成服務組件，但是錯誤的方法更多。 _{p. 6}

拆分一整塊成微服務時，負責提供穩定平台供開發與執行微服務的基礎建設組織會變得更重要。基礎建設團隊必須提供穩定的基礎建設給微服務團隊以降低微服間的互動的複雜性。 _{p. 7}

成功轉移的關鍵是完整、仔細、不厭其煩的計劃與執行文件，加上對大型一整塊的轉移需要需要好幾年功夫的認識。 _{p. 7}

處於早期階段的公司對找出需要維服務的關鍵領域與元件特別困難：新公司的應用程式不會有很多的功能，也不會有適合拆分成微服務的功能。 _{p. 7}

微服務的 API 端點應該要標準化。 _{p. 8}

API 端點的版本話同樣應該避免。 _{p. 8}

基本上就是盡可能維持向下相容，使用你的微服務的人不一定有閒工夫配合你升版。

在設計良好、可持續的微服務生態系中，微服務與所有基礎建設是抽象分離的。微服務與硬體、網路、建構與部署管道、服務查詢與負載平衡是抽象分離的。 _{p. 9}

基礎建設必須支持微服務生態系。基礎建設工程師與架構的目標必須將低階運維考量從微服務開發中排除並建構出可擴充的穩定基礎建設，讓開發者可以在上面輕鬆的建構與執行微服務。 _{p. 9}

相較於嘗試教導每個開發者生態系中所有工具與服務的細節，應該要為生態系的每個部份建構容易使用的使用者介面然後訓練他們如何使用。將所有東西變成黑箱並以文件說明如何運作與使用。 _{p. 14}

所有微服務都應該具有微服務層日誌記錄所有對微服務的請求與回應。 _{p. 15}

微服務架構有四個特別大的缺點。第一個是跨團隊溝通不良的組織結構的改變——康威定律的反述。第二個是大幅的增加技術性浪費，浪費不只增加整個組織的成本，也增加工程師的成本。第三個缺點是提高系統故障的可能。第四個是工程與基礎建設資源的競爭。 _{p. 17}

康威定律的反述表示使用微服務架構的公司的組織結構會由大量較小、隔離、獨立的團隊組成。這種團隊結構不可避免地會造成封閉與浪費，微服務生態系越複雜、並行、與高效率時問題會更惡化。 _{p. 17}

很少有工程組織能夠承擔起其所謂的專用工程資源。選擇支援較少的語言並確保所有函式庫和工具與這些語言相容更為務實，而不是常識支持各種語言。 _{p. 18}

第二章 高品質

雖然很好用，但可用性不是微服務的標準，而是目標。它並非標準是因為它無法指示如何設計、建構或執行微服務：告訴開發者微服務的可用性要更高但沒有說明如何進行 (或原因) 是無用的。 _{p. 22}

真的。無用的。

穩定、可靠、可擴充、容錯、高效能、受控、文件良好，且能夠應對災難。這些基本原則的目的是推動微服務的可用性。 _{p. 24}

為確保可用性，我們必須克服高速開發節奏與微服務生態系變化產生的不穩定性。 _{p. 24}

成功的微服務 (與微服務生態系) 的標誌是穩定增長的處理量。 _{p. 25}

定期與用戶以及相依服務溝通服務的擴充需求、狀態，與瓶頸以確保相互依賴的服務均準備好面對成長與可能出現的問題。 _{p. 26}

故障狀況的解決方案的組織層級標準化表示個別微服務、基礎建設元件，或整個生態系的意外與停機應該要有仔細規劃、容易理解的處理步驟。 _{p. 27}

誠心建議：千萬別在步驟裡加「找出 root cause」。能先重開機就先重開，任何可舒緩狀況的動作都應該先做。你絕對不會希望機師在引擎起火時，找出為什麼起火，而是想辦法在墜機前先讓飛機穩下來。

好的監控有三要素：重要資訊的日誌紀錄；正確反映服務健康狀態且容易理解的圖形顯示 (儀表板)；可供採取行動的重要數據警示。 _{p. 28}

警戒線應該要：夠高以避免噪音，但又夠低以捕捉所有確切的問題。 _{p. 29}

第三章 穩定性與可靠性

創新、提升開發者衝勁與生產力、快述技術演進，與不停變化的微服務生態系在某個部分不穩定或不可靠時將會中止。在某些情況下，一個關鍵微服務的錯誤會導致整個業務停擺。 _{p. 33}

最後，微服務與其端點必須能夠在不影響其他維服務下除役。 _{p. 33}

大部分的停機與微服務故障來自程式開發過程、測試，或部署程序中沒有捕捉到的錯誤。問題通常靠回復上一個穩定建置、取消有問題的提交，與重新部署 (沒問題) 版本程式來緩和與解決。 _{p. 34}

可靠的開發環境 —— 精確複製上線環境 —— 是關鍵，特別是受測服務需要與其他微服務互動或存取資料庫時。 _{p. 35}

由於相依性的複雜性，在微服務生態系中設置階段環境不容易。如果你的微服務依靠其他九個微服務，則發出請求或存取時需要相依服務或相關資料庫做出精確的回應。由於這些複雜性，階段環境需要階段部署的標準化。 _{p. 37}

我是不知道標準的翻譯應該是什麼？但大家真的能猜到階段環境是 staging 嗎？我一直覺得翻譯不用全部都翻成中文...

逐步絕對需要自動回復：若發生錯誤，部署系統必須自動回復到上一個穩定版本。要記得逐步處理的是真實工作，任何問題會影響真實世界。 _{p. 41}

canary 翻譯成逐步我是真的傻眼了...

讓開發者直接部署上線應該只用於發生重大問題時。若不嚴格執行，就有可能會忽略程序並直接上線：大部分開發者都會認為每個修改與部署很重大而略過階段與逐步，進而影響整個微服務生態系的穩定性與可靠性。 _{p. 42}

作為多年的 release manager，看到這句話很感動，我常是那個阻止直接上線的人...

認識微服務的相依性與故障計畫是建構穩定又可靠的微服務的最重要角度之一。 _{p. 43}

微服務的相依性必須被辨識、紀錄，與追蹤。任何會影響微服務的 SLA 的相依性必須包含在微服務的架構圖與文件與服務的儀表板中。 _{p. 43}

我沒打錯字喔，但讀起來很怪吧！

第四章 擴充性與效能

在工作由數百 (或數千) 個微服務合作處理工作的大型微服務生態系中評估與提升效率是非常的困難。它也受限於電腦架構與分散式系統的法則：系統越分散且微服務越多，個別微服務的效率對整個系統的影響越小。 _{p. 47}

我們必須有效率的使用硬體資源、知道資源的瓶頸與需求、並進行合適的容量計畫。 _{p. 47}

各方面都完美的微服務在相依服務不能跟著擴充時還是有擴充性的問題。就算只有一個重要相依服務無法跟著擴充，則整個相依鏈都會受影響。確保所有相依服務會跟著微服務擴充是高品質服務的基礎。 _{p. 53}

找出工作量模式後，修改、計畫中的停機，與部署都可以避開尖峰時刻以減少尖峰時刻出問題時的停機。 _{p. 54}

開發團隊應該要能回答與微服務有關的三個問題：微服務如何處理工作、微服務的工作處理效率，與請求數量增加時微服務的效能。 _{p. 55}

微服務必須以可擴充與高效能的方式處理資料。微服務儲存與處理資料的方式很容易會是擴充性與效能最重要的限制：選擇不對的資料庫、錯誤的結構設計，或資料庫不支援借測會影響微服務的可用性。 _{p. 56}

第五章 容錯與災難預防

緩和災難與避免整個系統的可用性的受影響的唯一方是要求生態系中的每一個微服務容錯並準備好應對災難。 _{p. 61}

為預防與擴充相關的意外與故障並完全準備好應對未來增加的工作量，我們可以用負載試驗檢查服務的擴充性。 _{p. 72}

知道工作量，通知負責待命的相關團隊，從階段環境跑過測試之後，你絕對需要在線上執行負載測試。 _{p. 73}

這真的很考驗心臟，但我也聽過另一種說法，千萬別在正式環境執行負載測試。

故障發生時，故障檢測與補救的目標必須是：減少對使用者的影響。 _{p. 76}

這些處理意外的步驟加起來共有五個階段：評估、協調、緩和、解決，與跟進。 _{p. 78}

我再加一個：把不按這步驟處裡的人趕出去。感覺我對這件事怨念很深...

緩和和解決不同：它並非完全改正問題的根源，只是減少影響。 _{p. 79}

意外或停機緩和後，工程師可以開始解決問題的根源。 _{p. 79}

跟進階段有三件事：撰寫檢討報告來分析與認識意外或停機、嚴重意外或停機必須公布並審核、列出讓開發團隊採取行的清單以讓受影響的微服務回復到高品質狀態。 _{p. 79}

第六章 監控

若不知道微服務的狀態、沒有追蹤關鍵數據、則累積的不明故障會引發停機。 _{p. 81}

可採取行動的重要數據警示讓開發者可以在停機前緩和與解決問題。最後一個要素是實作可持續的待命輪班以應對警示。 _{p. 81}

監控服務的可用性、服務層級協議 (SLA)、延遲 (整個服務與其 API 端點)、API 端點成功、API 端點回應與平均回應時間、服務 (用戶) 的 API 請求來源 (與發送請求的端點)、錯誤與例外 (有處理與未處理)，以及相依性的健康狀態。 _{p. 83}

有些東西絕對不應該紀錄。日誌不應該有身分資料，例如客戶的姓名、身分證字號，與其它隱私。大部分情況下，使用者 ID 與使用者名稱等看起來沒關係的資料在沒加密下不應該被記錄。 _{p. 85}

有時候某些資料在處理客服來的問題時是有用的，但確實要小心處理。

所有警示都必須可採取行動。不能採取行動的警示由待命開發者解決 (或忽略)，因此不重要、不相關、沒什麼錯，或不能由開發者解決，任何不能立即由待命開發者採取行動的警示應該拿掉、重新非配給相關的待命工作，或 (若能) 轉換成可採取行動的警示。 _{p. 87}

建構逐步指令描述如何補救、緩和，與解決警示。這些逐步指令應該放在集中的操作手冊中以讓待命者方便查詢。 _{p. 87}

識別警示的反模式。若微服務的待命者背景是煩死但微服務又沒有問題，則超過一次以上且容易緩和或解決的警示應該要自動化排除。 _{p. 88}

待命輪班應該要簡單且平均分擔：同一時間不少於兩個開發者。且待命期應該不超過一週且每月不超過一次。 _{p. 88}

說是這麼說，但如果考慮大家的感受，排班其實蠻複雜的。

第七章 文件與教育訓練

重點是更新微服務的文件。問微服務生態系中的開發者主要的憂慮，... (略) ... 通常會有相同的答案：它是黑盒子，不知道它如何運作，且文件是廢物。 _{p. 91}

最好的辦法是將文件更新放在開發流程中。若文件與開發工作分開 (次要)，則不會被完成並變成微服務的技術負債的一部分。要減少技術負債，開發者應該 (或被要求) 修改程式時要更新文件。 _{p. 93}

閱讀程式是不可能知道微服務如何運作，而好的架構圖示是容易理解的微服務視覺描述與摘要。這些圖示還透過將微服務的內部運作抽象化以幫助新功能的開發者知道新功能如何 (或不能) 運作。最重要的是它描繪出只有視覺表現才看得出來的架構問題：很難從閱讀程式看出服務的故障點，但在精確的架構圖示下就很明顯。 _{p. 94}

不確定原文是什麼，但這是我第一次看到「架構圖示」的說法...

在上千個不同微服務與開發團隊間推動這些高品質標準讓我知道微服務的教育訓練最有效的方式是為每個微服務排定架構審核。 _{p. 98}

內容十分精實，一百多頁很薄的一本書，但含了很多有用的資訊，就算不是開發微服務，書中的內容也可以用在很多雲端服務的開發與維運上。中文版唯一可惜的地方，翻譯非常不通順，很多不像中文的句子，會看到好幾個「與」連在一起用，標點符號的用法也有點怪，閱讀的痛苦指數有點高...