反金字塔模型

建築中的「反金字塔模型」是什麼

反向金字塔模型是一種系統和協議的設計方法，其中最重要，最起碼所需的信息/功能首先被傳遞並得到保證，並且以漸進和可選的方式添加不太關鍵的零件。該術語借鑒了新聞學的想法（最重要的是-首先），但適應了工程任務：關鍵路徑在任何條件下都有效，其他一切都是「豐富層」。

直觀畫面：上面的狹窄頂點是「最低保修合同」（MGC）,下方是擴展、優化和系統在有資源/兼容性時應用的豐富功能。

在哪裏應用它

網絡協議和API：REST/gRPC/GraphQL，webhooks，事件經紀人。
流媒體：WebSocket，SSE，Kafka/NATS，RTC。
服務體系結構：關鍵路徑與副作用（審核、分析、緩存預熱）。
Mobile/Web客戶端：首先是UI的「骨架」和關鍵數據，然後是媒體和指南的懶惰裝載。
支付和風險鏈：授權/保留-優先級；反親緣關系/分析-異步,帶有截止線。
可觀察性：始終是最低水平的邏輯/度量；trace/profilation-通過采樣。

模型原理

1.最低保修合同（MGC）

一組沒有腳本的字段和操作是沒有意義的。它是穩定的，向後兼容的，並且首先通過。

2.漸進式豐富

其他字段/功能可作為可選的擴展（capabilities/feature flags/Negotation）提供。

3.無故障退化

當擁塞或部分不可用時，系統會丟棄可選圖層，同時保持MGC的運行狀態。

4.明確優先級和SLA

每個層都有自己的SLO（潛在性、可用性）、隊列和服務類（QoS）。

5.方案的加性演變

新字段被添加為nullable/optional，不會破壞客戶；剛性變化-僅通過新版本。

6.各層的可觀察性

度量和日誌按臨界值標記：「core.」，「enh.」，「batch.」，以查看系統在負載下犧牲的內容。

與「經典」層金字塔的比較

古典建築（底層是基礎，上層是UI）強調依賴性。
反金字塔強調傳遞的重要性和順序：首先是「核心」，然後是「nice-to-have」。

按模型設計協議

1) REST/HTTP

MGC：最小資源/終端和必填字段。

• 內容不激活（「Accept」，「Prefer」），
• 參數'?include='/'?fields='用於選擇性細節，
• 引用「重」附件（pre-signed URL）而不是inline。
• 退化：在taymout中，給予MGC而沒有嵌套收藏；206 Partial Content for Big Top。
• 轉化：加法場不改變舊合同；主要版本僅用於中斷更改。

2) gRPC

proto：具有安全標簽編號的新「可選」字段；不要再使用已刪除的標簽。
Server side deadlines和per-method QoS（優先級以上的關鍵RPC）。
Streaming：第一條消息是標題/總數,然後是chankami的詳細信息。

3）事件輪胎（Kafka/NATS）

事件核心：「event_type」、「id」、「occurred_at」（最小業務字段）。
豐富：帶到outbox/CDC和個別主題「-enriched」。
首先匯總，然後是細節：消費者可以通過內核完成業務流程，然後異步趕上零件。

與反金字塔完美結合的模式

Critical Path First：將同步「強制性」與異步副作用分開。
Write-ahead/Outbox：記錄事件的事實，其余的是背景交付。
Lazy＆Incremental Fetch：分離，遊標，「If-Modified-Since」/ETag。
Capabilities Discovery：服務器/客戶端明確報告支持哪些擴展。
Backpressure&Budgets：截止日期，每層CPU/IO限制；取消負荷下的次要任務。
SLO-Scoped Caching：緩存「內核」更具攻擊性,富集更短/更薄。

實施算法

1.腳本映射：寫出用戶旅程並突出顯示「價值時刻」。
2.定義MGC：實現價值的最小字段/操作。
3.分為：「core」、「extended」、「analytics/batch」。
4.為每個圖層設置SLO/SLA和QoS。
5.設計降解：在N% 的故障/p95生長下丟棄什麼？
6.方案的演變：版本策略，additive-first。
7.可觀察性：度量/logs/trace中的圖層標簽，「核心」上的差異。
8.測試：混沌工程和斷層噴射。
9.啟動和反饋：包括ficheflags擴展和金絲雀滾動。

按層劃分的度量和SLO

Core：p95/p99潛伏期，成功的關鍵操作比例，降解時的容錯性。
擴展：豐富響應的百分比，平均趕上時間。
Batch/Analytics：實時脫落,每個窗口處理的事件比例。
業務指標：過載vs.時轉換為「價值點」是正常的。

反模式

「一切都是核心」：擴展成為強制性的，降解變得不可能。
MGC的突破性變化，沒有新的主要版本。
隱性脆性：關鍵路徑依賴於外部「次要」依賴性（例如，同步反同步調用）。
隱式擴展：客戶不知道可以打開/關閉什麼。
缺乏觀察能力：系統「默默」降級，你看不到在哪裏。

示例

A.用戶配置文件（REST）

MGC: `id`, `display_name`, `avatar_url`, `tier`.

擴展："badges［］"，"social_links［］"，"recent_activity［］"通過"？include='。
退化：在定時時給出MGC和預制資源鏈接（HATEOAS/URL）。

B.付款授權

MGC：授權結果（proved/declined），「transaction_id」，「amount」，「currency」。

擴展： 3 DS遙測，風險調查，地理，合作夥伴歸屬-異步通過事件「付費」。authorized`.

退化：在分析失敗的情況下，付款正在進行，審計/評分正在趕上。

B.流媒體報價

MGC：最新價格的「快照」。
擴展：杯子深度，合並指示器-狙擊後流。
退化：在負載下，擴展更新頻率下降，但快門穩定。

轉化與演化

附加第一：新字段「optional/nullable」,舊字段仍然存在。
語義版本：內核的「v1」；v1。x'-擴展；'v2'-當MGC發生變化時。
代碼中的合同：JSON Schema/Protobuf+CI驗證「不打破」誹謗。

安全性和合規性

MGC已簽名/身份驗證：最小字段集具有加密完整性。
Least Privilege：通過單獨的漏洞獲得濃縮。
PII/贈品：擴展外賣，鑰匙共享和TTL。

可觀察性和調試

前綴度量： 'core。request.duration`, `enh.attach.load_time`, `batch.lag`.

采樣：100%用於核心錯誤的日誌；對擴展進行采樣。
Feature flags telemetry：可以看到哪些客戶端啟用了哪些擴展。

實施支票（簡短）

• 由MGC定義和記錄。
• 通過capabilities/flags宣布擴展。
• 按圖層配置SLO/QoS/隊列。
• 退化通過混沌測試進行測試。
• 方案的演變只是加法的，沒有「斷裂」。
• 度量/traces/logs按層劃分。
• 客戶關於啟用擴展的文檔。

FAQ

反金字塔是否取代分層體系結構?

沒有。這是一個正交原則：如何在熟悉的層之上傳遞和優先考慮功能。

什麼時候不適用？
在部分交付毫無意義的離線數據包中（具有原子性的密碼交換機），或者當所有字段都同樣關鍵時。

與「graceful degradation」有何不同？
反金字塔最初設計了最低限度的足夠合同及其優先事項，而不是「事後」試圖挽救已經超載的系統。

結果

反金字塔模型有助於建築和協議在任何負載下保持有用：最重要的是，首先是肯定的；其余的-如果可能的話。這增加了關鍵路徑的可用性，加快了眼鏡輸出，並簡化了演化而不會發生故障。