產品級微服務的八大原則-- Microservices in production 讀書筆記
雖然微服務架構給開發者帶來很大的自由，但是確保服務的可用性卻要求對微服務進行很好的架構，運維以及組織標準。
O'Reilly這本免費的電子書Microservices in Production介紹了微服務標準化的挑戰，以可用性作為微服務標準化的目標，提出了八個標準化微服務的原則，包括在整個工程組織中實現production-readiness標準的策略。
這本書的作者是 Susan J. Fowler, Uber 的 SRE (site reliability engineer)，她在Uber也主要做促使Uber項目中的各個微服務達到產品級的狀態，所以這本小書也是她的工作思考之作。
微服務的挑戰
一般在剛開始開發應用的時候會採用單體應用的架構(monolithic)。很多應用的架構都是在公司初創的時候設計的，所以那時候追求的是“糙快猛”。隨著公司的發展,應用需要擴大規模，增加更多的功能，這時候開發人員會發現他們被應用最初的架構所制約，比如語言的選擇、可用的庫、開發工具、迴歸測試工具等。對應用的重構都不得不受限於初始架構的制約。顯然，初始架構的選擇決定了應用的未來。
微服務的架構使用給開發人員帶來了縷縷清風，他們不再侷限於過去的架構，他們可以他們所期望的服務：自由的語言、自由的數據庫、自由的開發工具，他們是自己的王，自由的君主。經常聽到的微服務設計的一個原則就是：一個微服務就幹一件事情-只幹一件事情-把一件事情幹好，用你所想建你所要，確保它們工作即可。
是不是太理想化了？當你擁有成百上千的微服務甚至上萬個微服務在運行的時候，它們之間必須無縫的交互，不應該有質量低下的服務影響整個微服務的整體，或者說影響產品的性能和功能。如果要保證產品的整體性能和功能工作的非常好，就需要有一定的標準，它的每一個部分也得遵循這樣的標準。
為一個特定的微服務制定標準非常簡單，但是要想為微服務制定一個通用的標準確實相當難的，這也是production-ready的由來。
Availability：標準的目標
衡量微服務是否成功的一個最通用的方法就是可用性(Availability)。如果一個服務有很高的可用性(宕機時間很少)，那我們就相當信任這個服務。
而且計算可用性的指標也很簡單: uptime (正常服務時間)、downtime(宕機時間)、以及總運行時間(uptime + downtime)。
儘管可用性指標很有用，但是它並不是衡量微服務的一個標準，而是這些標準要達到的目標。之所以不是一個標準法則，是因為它不能指導我們如何開發微服務。告訴一個開發人員提高他們的微服務的可用性，而不告訴他們如何去做就想白說一樣。光說可用性是沒有任何的可實踐的步驟，而這本書後面的章節為我們提供了提高可用性的步驟。
計算可用性一般使用幾個9來表示。
- 99%: 允許宕機的時間為 3.65天/年
- 99.9%: 允許宕機的時間為 8.76小時/年
- 99.99%: 允許宕機的時間為 52.56分鐘/年
- 99.999%: 允許宕機的時間為 5.26分鐘/年
Production-Readiness 標準
Production-Readiness背後隱含的含義是：產品或者服務值得信賴，它們可以滿足產交互。
我習慣將Production-Readiness翻譯成產品級, 它實際的意義代表可以應用在產品中，滿足產品的需要。
有很多產品和庫標榜自己是產品級的，但是我們需要準確的衡量。標準化如果沒有可操作的原則也是沒有意義的，作者提出了衡量服務是否是產品級的八個原則：stability、 reliability、 scalability、 fault-tolerance、 catastrophe-preparedness、 performance、monitoring、 documentation，它們一起為微服務提供了高可用性，但是單一的原則並不能保證微服務的可用性。
Stability
微服務架構的採用為開發者提供了很大的自由度，他們可以每天增加和發佈新特性，修改bug，用新技術代替舊技術，可以重寫或者棄用過時的微服務。
雖然這些自由度允許我們快速修改bug,即時更改服務，但是我們必須小心這些操作避免影響微服務的可用性。
一個穩定的微服務應該是這樣子的：它的開發、發佈、新技術/新特性的增加、Bug的修改、服務的停止使用以及服務的棄用都不應該影響大的微服務生態系統的穩定性。
為了避免開發過程、發佈過程、更改停止棄用時出現問題，我們需要在每個過程仔細考慮，執行到位，不會影響其它服務。
Reliability
穩定性並不是唯一影響微服務可用性的因素，微服務必須保障可靠性(Reliability)。一個可靠的微服務值得它的client所信任，以及它的依賴和整個生態圈。
穩定性和解決微服務的改變帶來的副作用相關，而可靠性是和信任相關，這兩個原則密不可分。每一個穩定性的需求都帶來可靠性的需求。
通過cache可以提供可靠性的保證。通過defensive cache在服務出現問題時提供兜底。我記得淘寶前端的同學寫過使用這個技術的文章： 淘寶首頁兜底容災方案
在路由routing和服務發現的處理中，為了保證可靠性，health check應該是準確的，request和response應該送達、錯誤處理應該仔細的被處理。
Scalability
微服務的業務處理很少是恆定的，成功的微服務總能平穩地處理業務量的增大。不能規模擴展的微服務在業務量增大的情況下會增加服務的延遲、低可用性，極限情況下還可能導致意外事故或者停機。
一個可擴展的微服務可以同時應付大量的任務或請求。為了確保微服務可擴展規模，我們需要知道它的定性的增長規模(它是擴展頁面瀏覽還是客戶訂單)，還需要知道它的定量的增長規模(每秒它能處理多少請求)。一旦我們知道了擴展規模，我們就可以為未來的容量進行規劃，找出資源瓶頸和需求。
可擴展的微服務應該能應對突然爆發的請求，比如秒殺，防止服務整體垮掉。當然這說起來簡單，做起來很難。想想每年的電商做活動的時候或者春節買火車票時候的系統就理解了。
我們還得從整個微服務系統考慮可擴展性，當服務業務量超過它的預期的時候應該報警。服務擴展的時候也會要求它的依賴能滿足擴展的需求。
微服務的數據存儲也必須滿足可規模擴展。
Fault Tolerance and Catastrophe preparedness
即使最簡單的微服務系統也是複雜的系統。複雜系統經常會出現失敗，失敗的場景會出現在微服務的整個生命週期的每個環節。微服務並不是完全隔離的，它們是整個微服務系統中的一環。每一個微服務都應該是容錯的和提供災備。
容錯和災備的微服務應該能夠承受內部錯誤和外部錯誤。內部錯誤可能是微服務自己導致，例如內部代碼的導致的未捕獲的錯誤，外部錯誤可能是數據中心的停電、錯誤的配置等。
我們可以充分地(不一定完全)為這些錯誤和潛在災難準備預案。識別錯誤和災難場景是創建可容錯和災備的第一個需求，難點在於對這些失敗和災難的處理預案，它出現在整個微服務生態圈的每一個環節。
Performance
我們在談論微服務的時候，scalability談論的是服務能處理多少請求 (how many)，而性能performance談論的是微服務處理這些請求的性能 (how well)。
一個高性能的微服務處理處理請求很快，任務處理很高效，正確地使用資源。
處理一大堆網絡調用的微服務不是有效的。同步處理任務性能也不是很高，異步(非阻塞)地處理任務能提供服務的性能和可用性。
佔用大量資源比如CPU的微服務而不是使用它們，這不是有效的使用方法。使用硬件資源會影響服務底線，因為硬件資源不便宜。需要規劃好容量。
Monitoring
另一個保障微服務可用性的原則就是正確的服務監控。好的監控要包括三大組件：
- 所有重要的正確的日誌和相關信息
- 使用圖形化的顯示(dashboard)
- 關鍵指標的告警
作者指出，版本化的微服務是不被鼓勵的，所以你的日誌不會包含服務的版本信息，這要求你的日誌要包含足夠的信息。
所有關鍵的監控指標，比如硬件的使用率、數據庫的連接、響應時間、API的狀態等，應該圖形化的顯示，可以直觀的觀察到服務的狀態。
告警信息應該傳達給負責的工程師，為監控指標設置合適的閾值。
告警信息應該有用，並且可以處理，通常會有對應的處理文檔。
Documentation
微服務的架構會帶來技術債，減少它的辦法就是文檔。
即使是一群工程師面對面的在一個會議室內討論一個微服務的細節，肯定也會有工程師理解的不全面，每個工程師在心裡都有自己的理解。
最好的文檔包含微服務的所有的基礎知識：架構圖、入手和開發手冊、請求流的細節、API、告警的運維手冊等。
後記
作者在每一個原則後面都列出了每個原則的需求，它們提供了檢查微服務的可實踐的方法和步驟。作者最後介紹了一下應用這個標準的實踐過程。
不僅在Uber,在其它一些公司, 都存在著SRE (site reliability engineering)組織。比如今年Google的工程師推出了一本 《Site Reliability Engineering: How Google Runs Production Systems》,專門介紹SRE，已經出中文版了，名字叫《SRE:Google運維解密》，有興趣的讀者可以買來看看。
