口述／孫培然‧彙整／CIO編輯室
在整個微服務架構當中，之所以要借助事件驅動（Event-driven）或訊息佇列（Message queue）之類的服務模式，讓使用者可以馬上收到資料變動的訊息，除了要做到資料同步一致性外，另一個重點在於當網路中存在很多微服務時，在微服務架構中的故障也會更為普遍，但也更具挑戰性。
所以首先不要擔心，要把「故障」認為是理所當然，需要思考的是要怎麼去克服故障，而且還能繼續使用。事實上，微服務通常都是運行在自己的容器中，所以故障的微服務通常是不會直接影響到其他的微服務程序。
但是為什麼某個微服務故障時，還是有可能會擊倒整個應用呢？主要的原因是出現無窮迴圈的呼叫，造成系統資源耗盡，最後引發整個系統故障。所以只要有適當的工具或產品，可以用來監控在無窮迴圈出現時，會自動中斷也就是熔斷，就可以避免因為故障而影響營運。
容錯和彈性確保服務穩定性
其實不管是單體或是微服務，都沒辦法百分之百保證，服務是不中斷的。但是我們至少可以確保，服務可以有百分之幾不會中斷。所以就需要有一個對故障進行合適的處理，也會對應到正常執行時間的服務級別協定 ─ SLA（Service-Level Agreement）標準。
如果某系統號稱 SLA 為 99.9%，表示一年之中必須要有 99.9% 的時間可以正常營運。市面上有些較知名的公有雲甚至會提出 SLA 可以達到 99.99%。
這代表系統只能允許一年當中無法提供服務的時間，只有（365天×24時×60分×60秒）× 0.1% 等於 31,536 秒，換算回來就是一年當中可以當機的時間，只有 8 小時 45 分鐘 36 秒。如果當機的時間超過前述的時間，系統就不能號稱有 99.9% 的 SLA。
追蹤診斷探究原因加以改善
雖然在 Kubernetes 容器化中的服務就算死了也會再起來。但你終究還是要去解決到底問題出在哪裡，所以若想要監控微服務應用中的服務有沒有死掉或者是否可以正常營運，就得透過日誌（Log），將服務可能出現的異狀記錄起來，所以你需要針對 Log 制定合理的追蹤策略去做統計分析，看整個微服務中間有哪些服務死掉又起來，才能去探究分析原因並進行改善。
但因為微服務應用中有成百上千支服務，會生成大量的日誌，除了很耗資源外，請求通常也會跨越多個服務，所以為了節省成本及資源浪費，我們通常的做法會把日誌上傳到雲端，尤其是公有雲，因為目前許多公有雲上傳還不需要費用，而下載才需要花錢，只要將日誌上傳到公有雲，再利用公有雲所提供的雲端工具去做分析，這樣子也不會占用到本地運算的資源。
但這麼多的服務，要怎麼去做分析呢？所以，找到一種方法在整個系統中對請求進行標記就非常重要。每一個服務區都需要一個標記，進行分群分類才有辦法去看清楚整個服務請求過程的路徑。
通常的作法，都是透過使用關聯或者傳遞給所有下游服務的活動 ID 來實現，所以每一個服務都要專屬的 ID，你就可以透過 ID 去追蹤這個服務。由於在做成微服務以後，可能會把整個服務分給不同的團隊去開發，所以一定要規範好統一的日誌格式，服務跟服務之間要規劃好，不同團隊之間就可以溝通，一旦服務有狀況或問題時，未來才有辦法追蹤診斷，才能得到很好的分析結果。
完善版本控制機制 DevOps 才能有效部署
接下來要注意的是版本控制，在單體系統中，呼叫一個 API 的程式碼，通常與實作 API 的程式碼都是寫在一起，所以 API 如果有變更，在整合測試或者建構期間就會知道。但是在微服務的世界中，微服務 API 的程式碼一旦變更，呼叫這個微服務的程式碼並不需要立即進行處理，因為它們可能是在不同時期發佈的，兩者之間根本沒有互相關聯。
假如呼叫你的是微服務的版本v1，但微服務卻已經變成版本 v2 的時候，就可能會出現問題。所以一定要確保微服務有良好的版本控制機制，每一個服務都要有它的原始碼版控機制，才能保證呼叫服務仍然能夠按照預期進行工作。
所以，微服務的 DevOps（Development & Operations）必須要放在一起思考，才能做到自動化，且能夠即時監控。DevOps 中開發與維運如果是分開運作時，通常會碰到一個鴻溝，就是程式在開發環境測試時沒有問題，但真正放到正式環境時有時候會卻出了問題，這是因為開發與維運的環境不同，所以我們現在要把開發與維運整合在一起，希望能讓正式環境跟開發環境盡可能相同，所以微服務架構必須要建立在定義良好的工作流程，讓開發和維運一起工作才能帶來敏捷、高品質的發佈。
(本文授權非營利轉載，請註明出處：CIO Taiwan)
