圖自官網

others: https://seata.apache.org/docs/user/configuration/consul/

思考

keyword:state machine
Q: 當服務中斷到服務回線，會需要全部重來，還是會自動重試?

apisix 以 standalone deploy ，遇突發性單點故障，怎麼處理接續或是待會的服務

當 APISIX 以 Standalone 模式 部署時，如果發生突發性單點故障，處理後續服務的方式取決於系統設計和運行環境。Standalone 模式下，APISIX 並未依賴 etcd，而是依賴本地或分布式文件系統中的 YAML 配置文件，這在一定程度上減少了外部依賴，但仍需要考慮以下幾種應對策略來處理單點故障問題：

1. 自動重啟與健康檢查：
   在 Kubernetes 或其他容器化環境中，通常會使用 Liveness Probe 和 Readiness Probe 來檢查 APISIX 的健康狀況。如果發生單點故障，K8s 或容器編排工具可以自動重啟故障的 APISIX 節點，讓其重新加載配置並繼續提供服務。
   這種方式能夠快速恢復故障節點，並減少服務中斷時間。
2. 多實例部署和負載均衡：
   部署多個 APISIX 節點，並使用負載均衡來分配流量。當一個節點發生故障時，負載均衡器（例如 Nginx 或 Kubernetes Ingress Controller）會自動將流量轉移到其他健康的節點，確保整個系統仍然能夠提供服務。
   這是一種較為常見的做法，用於提高系統的高可用性 (HA) 和容錯能力。
3. 故障恢復與配置同步：
   在 Standalone 模式下，APISIX 依賴 YAML 文件來進行配置。可以將這些 YAML 文件儲存在分布式文件系統（如 NFS、Ceph 等）或版本控制系統中，讓所有 APISIX 節點能夠從統一的位置獲取配置文件。這樣，即使某個節點故障，恢復後能夠從分布式文件系統中自動獲取最新配置，避免配置不同步的問題。
   同時，APISIX 可以設置定時檢查配置文件的變更，確保恢復後節點能及時同步最新配置。
4. 重試機制：
   若某個服務請求在 APISIX 節點發生故障時中斷，應設計重試機制，允許該請求在其他健康節點上重新處理。重試機制可以在應用層實現，也可以通過外部的 API Gateway 或負載均衡器實現。
   此外，APISIX 自身也支援插件，可以配置特定的重試策略來處理後端服務故障，確保服務的連續性。
5. 觀察與告警：
   使用監控和日誌系統來觀察 APISIX 節點的運行情況。常見的監控工具如 Prometheus、Grafana 以及告警系統可以幫助及時發現單點故障並通知運維人員進行修復。
   結論：
   當 APISIX 以 Standalone 模式部署並遇到單點故障時，可以通過 多實例部署、自動重啟、負載均衡 和 重試機制 來應對，確保服務不中斷。對於配置同步，可以考慮使用分布式文件系統或版本控制工具來管理配置文件，確保節點故障後能夠快速恢復並自動同步配置。

參考

https://apisix.apache.org/docs/apisix/deployment-modes/#standalone