微服務架構下常見的四個技術難題
實務上時常與之對決的痛點
引入微服務架構後，服務顆粒度縮小了許多，一般開發者要面對更多細節和以前很少出現的問題。原本習慣的開發方法和程式架構，也被迫要改變，甚至要思考更多未曾思考過的議題。
尤其是過去很輕易的程式內部呼叫、方法、模組化機制，在微服務架構下，被暴露在整體伺服器叢集之中，不再只是包裹在單一 CPU、記憶體等硬體之上，各種呼叫的安全性、延遲性或是額外的成本，都變成必須要考量的課題，不再容許開發者可以選擇忽略。
實務上有一些常見的技術難題，開發者和架構師在設計自己的微服務應用程式時，時常會與之對決。無奈的是，有些時候遭遇了也只能選擇臨時的 Workaround，除了埋下技術債之外，也免不了為未來埋下了炸彈。因此，很多時候，提前避開才是比較好的作法。
有鑑於此，本文將試著整理出四個比較常見的技術難題：
- 來回網路通訊問題（Round-trips Problem）
- 跨服務呼叫導致的可用性降低
- 跨服務的資料維護問題
- 資料一致性問題
來回網路通訊問題（Round-trips Problem）
當我們試圖切割服務並設計好 API 後，常會發現在單一個任務需求下，服務和服務之間會產生大量的呼叫。例如有個服務要對原始資料做豐富化（enrichment）的工作，所以大量呼叫另一個服務的 API，進行各種查詢作業。
你可以這樣想像，每當一個外部需求觸發，你的其中一個服務就開始對另一個服務進行阻斷服務攻擊（DDoS），大量的來回網路通訊，除了對網路環境有壓力之外，對於被呼叫的服務來說，也是相當重的負擔，甚至會嚴重影響服務的反應速度。
若要解決這個問題，比較簡單的做法，是考慮將 API 設計成批次（Batch）處理的形式，避免大量單獨的 API 呼叫。但是要特別注意的是，如果整批資料處理需要花比較久的時間，就要考慮是否要將 API 設計成非同步（Asynchronous）機制，避免服務間通訊期的意外發生。
如果服務的關聯性很高，又沒有其他服務共用的需求，則可以考慮合併兩個服務，來減少跨服務通訊。設計上，甚至可以試圖將需求轉成「生產者—消費者」的模式，對需要長時間的業務處理工作進行比較妥當的管理。
此外，就算有與其他服務共用的需求，還是可以考慮合併服務。至於在資料的同步上，則可以引入 CQRS 模式，實現資料庫私有化（Database Per Service）。關於 CQRS 的說明和實現方式，可以參考另外兩篇舊文「淺談 CQRS 的實現方法」和「應用層 CQRS 的實現與困難」。
當碰到此問題，有時候也要檢查並思考一下，是否不小心過度以「重用性」拆分服務，過分的模組化和共享性會為網路通訊帶來許多壓力。
跨服務呼叫導致的可用性降低
微服務架構下的服務間溝通機制都依賴著 API 進行，而且往往一環扣一環，一個服務後面還緊接著下一個服務。一旦其中一個呼叫失敗，整個任務就等於失敗。這意味著，API 的穩定性代表了整體系統的穩定性。
你或許會說，服務出錯代表有臭蟲（Bug），只要將問題解決就可以。但現實是，有時候不完全是應用程式的問題，而是部署平台導致。現代的容器部署平台，都提供了良好的高可用（HA, High Availability）機制，但問題是平台在轉移、管理我們的容器時，免不了短暫停止容器中的服務實例。這就導致了服務的極短暫中斷，甚至是上面做一半的工作，都可能被強制中止。
為了解決這樣的問題，重試和容錯機制就必須要實現，但這容錯機制的壓力會落在呼叫方身上，相當麻煩。不過無須擔心，大多數建立連線的問題，平台上的 Load Balancer 和 Proxy 會幫我們避免。
只是但意外還是在所難免，尤其是每個呼叫處理如果花的時間比較長，導致保持連線的狀態比較久，意外中斷的機率比較高。又或是每次 API 被呼叫後執行的工作量很大，每次中斷重連後重新處理很耗系統效能。
為了減少 API 的連線狀態時間，以及資源佔用問題。這時，採用非同步傳遞模式的 API 會是比較妥當的作法。而非同步傳遞模式的做法有兩種，例如 Asynchronous API 的形式，或是採用訊息佇列（Message Queue）傳遞資料。
跨服務的資料維護
資料庫私有化（Database Per Service）是微服務架構下會出現的資料管理模式，而外部系統存取服務的資料庫時，只能透過該服務所提供的 API。這樣的架構意味著，資料被分散存放在不同的服務和資料庫中，無論資料有沒有關聯性，導致資料管理維護上麻煩了許多。
關於資料維護涉及到兩個層面的議題：
- 交易機制（Transaction）
- 資料一致性
關於資料一致性，會在本文的最後一點提及，因此我們在這一小節只討論交易機制（Transaction）的議題。此外，因為分散式交易機制是一個重要且相對複雜的議題，本文只單純提及概念，更進階的作法和細節，甚至涉及了程式的實作及 API 的定義，比較難三言兩語交代清楚，日後另撰文說明。
過去實現交易機制（Transaction）的方法，多半依賴著資料庫系統本身支援的機制，在單一資料庫中實現。但在微服務架構下，因為資料庫不再是分享共用的形式，若我們要再多個資料庫間實現交易（Transaction）機制，傳統在單一資料庫內部的兩階段提交（Two-Phase Commit）便不再適用，而要轉向尋求分散式交易的機制。
要實現跨服務的分散交易機制，比較常見的會引入 SAGA 模式，而 SAGA 又分為兩種實現方式：
- 中心化設計的 Orchestration （編排式、協作式）
- 去中化設計的 Choreography（編舞式）
由於其複雜程度是開發者的一大痛點，我們除了提供顧問諮詢外，也為此提供客戶一個開箱即用的分散式交易解決方案「Brobridge Twist」，簡化客戶在實現交易機制上的工作。
中心化設計的 Orchestration
Orchestration 實現上比較能受到開發人員的掌握，因為所有的交易邏輯和控制，掌握在一支程式手上，由該支程式去發號施令，無論是要進行資料變更，還是要回滾、退回，都在同支程式可以完成。
去中心化設計的 Choreography
而 Choreography 在實現上，雖然概念上並不困難，對開發人員來說也只需要看著事件觸發而做事情，相對來說比較彈性。但缺點是比較難以看見整個系統對該交易任務的全貌，中間的事件處理分支，會隨著系統長大而跟著變複雜，需要在維護工作的配套措施裡下一些功夫。
在導入微服務架構之後，交易機制的意義，不再只限於資料層面，而提升到了應用層面。許多工作和任務之間有相依性，保持其行為上的同步，也是我們需要面對的議題。
資料一致性
延續前一節所敘，資料一致性是另一個在資料分散管理維護後，會產生的問題。交易任務產生的資料變更和同步問題，可以利用交易機制的實現來解決，但非交易任務下所產生的資料狀態不一致的問題，則要尋求 CQRS 這類方法進行資料庫和服務狀態的同步。
另外，縱使我們已經採用了各種資料同步的機制，但仍然在資料一致性上仍有些狀況會發生，一般來說問題發生的成因如下：
- 服務間訊息傳遞、處理的時間差
- 系統短暫異常
首先要暸解，分散式系統下的延遲問題肯定會存在，因為任務被分散在不同的系統之上運行，其中的網路連線延遲、運算時機以及結果聚合的時間消耗，都是造成延遲的主因。只不過，這些延遲非常的少，尤其當服務處於同一個內部網路、甚至同台機器上，其中的延遲時間幾乎可以忽略不計。
雖然說大部分應用上，這些延遲可以忽略不計，但在一些特定的應用上，卻不能完全容忍這些延遲，針對這些應用，系統需要特別做評估和優化。所以想要解決服務間訊息傳遞的時間差，請先確定任務是否有針對延遲的強烈要求，如果沒有，就沒有解決的必要。
至於系統短暫異常（例如網路、系統環境等問題），導致原本資料的同步機制失效，使得資料不一致的狀況發生。如果是自己實作同步機制，則可以利用 Event Sourcing 來重放事件，達成資料最終一致的要求。
如果是採用現成的 CQRS 方案，則不用擔心，這通常都是在相關解決方案的支援範圍內。
後記
微服務架構的各種設計模式（Design Pattern），其實同時都涉及了不同的實務問題，所以你會在不同問題中看到同一種設計模式的不同面向，例如 CQRS 就會大量出現在資料一致性、合併服務、領域邊界等場景下。所以，熟悉各種設計模式，是微服務架構的重要功課。
最後，如果您對微服務架構及其生態有任何疑問，或是需要技術上的評估與建議，歡迎與我們 Brobridge 聯絡，取得專業的教育訓練和顧問服務。
