在服務協作的設計模式中，所有的流程控制與邏輯決策皆由協作器掌握。一旦協作器遭遇意外故障，將會導致資料遺失，進而無法保證資料一致性。我們可以透過故障轉移（Failover）、備份和還原（Backup and Restore）等機制預防事故的發生，藉此提高服務可用性（ Availability）。

• 故障轉移

  故障轉移是一種常見的高可用性（High Availability, HA）策略，我們可以透過建立多個提供協作器服務的伺服器，在協作器發生故障時自動切換到備用的協作器伺服器。
  實務上我們可以透過使用例如 GCP、AWS 等知名雲端平台提供的「Gateway」或「Load Balancing」的功能，使其自動替伺服器實體進行健康檢測與流量監控，當碰到問題時及時進行流量切換。

• 定期備份

  除了故障轉移，備份和還原也是保證高可用性的重要手段。能夠透過過定期備份重要資料和狀態，來避免由於故障或錯誤導致的資料損失。
  備份和恢復微服務可以使協作器在微服務遭遇重大故障時保存及時的資料。當服務集群中的某個節點崩潰時，可於新節點中重新啟動服務，並連接至損壞節點資料存儲的目標，以處理停擺狀態的協作器，恢復協作器使其重新執行或進行還原。

設計

基於 Anser 協作器的備份元件

Backup 元件共包含以下類別與介面，其工作流程如圖：

• CacheFactory Class：
  開發人員於自定義的 Orchestrator Class 中使用該類別，將欲使用的備援資料庫驅動傳入，以此建構出對應的快取類別。
• BaseCacheHandler：
  抽象類別，所有 Handler 都必須繼承這個類別，它提供了協作器在生命週期中需要定期備份自身快照所需的介面，以及基礎方法。
• RedisHandler Class：
  以 Redis 作為備援儲存目標，該類別繼承 BaseCacheHandler，並實作 CacheHandler Interface，開發者能夠使用 Redis 作為快照留存的外部儲存目標。

Backup 元件位於協作器執行週期

Anser 的備份機制是建立於 Anser-Orchestration 元件之上的。Backup 元件主要負責儲存 Orchestrator 執行狀態時當下的快照（snapshot），它保障協作器遭遇意外中斷的狀況下，分散式交易過程不會遺失且被完整保留。

如同 Anser-Saga 元件一樣，開發人員得以自行選擇是否使用 Backup 元件。一旦開啟，那麼 Backup 元件將在每個步驟完成時進行一次協作器的快照，並將這個快照儲存至外部儲存目標。

協作器故障後湧道圖

關注上述湧道圖，我們可以發現在 Shutdown 前，每個步驟都將觸發一次快照，並將這個快照儲存至 Cache ，這邊的 Cache 不一定是基於記憶體的儲存目標，也有可能是像資料庫或 File System 類型的冷儲存媒介。

無論如何，透過 Backup 機制的保障，若是一個執行過程中的協作器偶遇伺服器斷電、宕機，或是程式意外終止。在異地的 Cache 內必然留存著這個編排器實體的最後樣子，在恢復服務後就可以選擇是否繼續協作器的執行，或是直接透過協作器內部的交易設定進行補償。

結語

Anser-Orchestration、Anser-Saga 以及本章所搭配的 Backup 元件，展現了一套具備份與復原能力的方案，不僅能夠緩和協作器在面對突發事件時的資料一致性問題，更能有效地保障系統的運作不受影響。