無市區生態系統更新

（部分： 生態系統和網絡）

1）零下時間目標和原則

• 在合同邊界上前進/後退（後退/前進）兼容性。
• 漸進性（漸進式交付）而不是「大切換」。
• 可觀察性和可逆性：度量，跟蹤，快速回滾。
• 用於網絡和支付流的Idempotity和安全回程。
• 故障隔離：細胞體系結構，電路斷路器，粉絲限制。

2）無市區發布策略

Blue-Green是兩個相同的堆棧（Blue=prod，Green=new）。流量在平衡器級別以原子方式切換，並且可以立即回滾。
金絲雀是SLO門的分階段流量份額（1%→5%→20%→50%→100％）。
滾動-帶有就緒性檢查（準備）和連接排水功能的節點池更新。
Shadow/Traffic Mirroring-鏡像新版本的請求,而不影響響應。
Feature Flags-在不變的API （gradual rollout）之上進行業務信息切換。
Dark Launch-包含用於遙測和剖析的隱藏邏輯分支。

建議：對於關鍵服務-canary+rolling+feature flags的組合；對於網關和API-藍綠色,短切換。

3）合同互操作性（API/事件/協議）

API：通過URI/標題進行驗證；僅通過「deprekate窗口」添加字段-有效,刪除/重命名。
事件（事件總線）：「僅添加」字段；密鑰不可變；新類型-作為新主題/版本。
電路（Avro/JSON-Schema/Protobuf）：電路註冊表，「BACKWARD'FULL」兼容性。
網絡/P2R協議：版本的握手和功能性negotation（節點聲明支持的版本/fici）。
網關：遷移期間的vN和vN+1（傳輸編碼/現場映射）之間的適配器。

Deprekate Policy（示例）：公告→ ≥90天的警告→ 「deprecated」復選框→刪除字段/端點。

4）數據不間斷遷移（Expand → Migrate →合同）

1.Expand-在舊格式和新格式中添加新結構/索引/列（nullable/c默認）、二元組（dual-write）。
2.Migrate-背景遷移，backfill，一致性驗證器；通過支持這兩個方案的適配器讀取。
3.合同-禁用舊方案中的讀/寫,在完成「刪除窗口」後刪除技術債務。

sql
-- Expand
ALTER TABLE payouts ADD COLUMN payout_ref TEXT NULL;
CREATE INDEX CONCURRENTLY ix_payouts_ref ON payouts(payout_ref);

-- Migrate (batch + idempotent)
UPDATE payouts SET payout_ref = concat('ref_', id) WHERE payout_ref IS NULL;

-- Contract (after compatibility window)
ALTER TABLE payouts ALTER COLUMN payout_ref SET NOT NULL;

事件事務性：使用Outbox（事件記錄事務）+CDC保證交付。

5）長壽連接和排水

Graceful shutdown： SIGTERM →停止接收新的請求→顯示「readiness=fail」 →等待WebSocket/HTTP2/QUIC流的排水→關閉。
在平衡器上繪制連接：「deregister_delay」 30-120 s, sticky會話-通過令牌而不是IP。
Back-pressure：在p99_latency增長時限制新的應用程序。

6） Version SDK和客戶

SDK的SemVer；具有擴展支持窗口的LTS分支（例如12個月）。
政策：「至少兩個活躍的小版本」；按版本劃分的客戶比例遙測；自動警告升級。
關鍵更改（security）-在截止日期後通過網關強制關閉舊版本的標誌。

7）網絡協議和節點更新

軟叉：在不破壞舊節點的情況下擴展規則。
硬叉：預先聲明的窗口，雙重驗證，「金絲雀驗證器」，防止「reorg/rollback」沖突，時間鎖定激活。
跨鏈升級：政府橋梁傳遞激活信號；如果是同步的-本地電路斷路器。

8）配置和秘密作為數據

集中式配置服務,包括轉換、數字簽名和回滾。
沒有市中心的秘密輪換：雙鍵（舊/新），交替包含；KMS/PKI的零停機時間。
在單獨的堆棧中顯示功能閃光燈,審核啟用/禁用。

9）管道發布和自動「門」

Стадии: build → unit → security scan → e2e/stage → shadow → canary → 100%.

• Error-budget burn-rate，p95/p99 latency，error-rate，降低成功率event/payment，dead-letter隊列增長。
• 在任何階段違反SLO時自動回滾。

yaml release:
strategy: canary steps:
- name: shadow traffic_mirror: 5%
gates: [no_data_loss, no_pii_leak]
- name: canary_1 traffic: 1%
gates: [error_rate<0. 2%, p99<400ms]
- name: canary_2 traffic: 10%
gates: [slo_ok_1h, zero_deadletters]
- name: rollout traffic: 100%
gates: [stability_6h]
- name: bake duration: 24h action: finalize_or_rollback

10）版本的可觀察性和SLO

• p95/p99殘局；error-rate （5 xx+致命的4 xx）；事件的成功率；retrais的比例；排隊；「中繼」在P2P中的份額；按版本劃分的客戶份額。

• p99 API ≤ 400毫秒；error-rate ≤ 0.2%;成功率事件≥ 99。5%;隊列變量≤ 2 c；MTTR回滾≤ 15分鐘。
• Dashbords發行版：「前/之後」比較，金絲雀圖，依賴性圖（服務地圖），burn-rate 1h/6h。

11）回滾和「kill-switch」

自動回滾：儲存最新的「好」文物和configs；平衡器上的「1按鈕」滾動（Blue←Green）。
Partial rollback： ficheflag關閉新邏輯,同時保留binar。
數據回滾：僅適用於「讀取路徑」；對於「write-paths」-受保護的遷移（在窗口結束之前,切勿刪除舊揚聲器）。
Kill-switch：用於禁用不穩定子系統的集中式標誌。

12）無停機測試

合同散裝測試與客戶穩定（消費者駕駛）。
具有兼容性檢查（schema-compat）的電路測試。
站點的混沌測試：％的節點/區域故障，DHT/TURN/KMS/DNS降解，「後退風暴」。
負載/轉售測試：金絲雀地區和「熱門」路線。

13）通信法規和合規性

發行說明：更改的內容、影響、刪除的窗口/截止日期、合作夥伴的活動。
事件響應的SLA：MTTA ≤ 5分鐘，第一個升級狀態≤ 15分鐘，後太平間≤ 72時。
跟蹤審核：將所有config更改和版本綁定到應用程序/前端,工件簽名。

14）特殊情況

支付/資金流：嚴格的idempotency、idempotency-key、outbox+CDC、「無損」遷移。
WebSocket/Strims： handshake中的協議版本,帶摘要的重新定義（resume tokens）。
緩存/邊緣：「stale-wile-revalidate」，緩存的雙重版本，發布期間的TTL衛生。
移動客戶：分階段滾動,強制升級安全發布。

15）零下限時間支票清單

1.合同兼容性和註冊表方案已配置。
2.Expand→Migrate→Contract描述和自動化。
3.Balance/Ingress支持藍色綠色和排水連接。
4.帶有SLO門和自動回滾的金絲雀管線。
5.全天候提供Feature-flags和kill-switch。
6.所有寫入路徑都包括Outbox+CDC和冪等性。
7.Dashbords「釋放健康」和alerta burn-rate是活躍的。
8.預先向合作夥伴宣布通信和撤資政策。
9.每周回滾排練；季度混沌日。

16）詞匯表

漸進式交付-分階段發布具有風險控制的幻燈片。
Schema registry是具有兼容性策略的方案版本存儲庫。
Outbox/CDC-從事務中保證發布事件的模板。
Blue-Green是具有原子流量切換的並行堆棧。
金絲雀-逐步增加新版本的流量份額。
Graceful shutdown/draining-正確終止活動連接。

底線：零中心不是一個特技,而是系統：合同、電路兼容性、分階段發布策略、可觀察性、安全遷移和保證回滾。遵循此框架，生態系統可以快速，可預測地更新，並且不會給用戶和合作夥伴帶來痛苦。