反金字塔模型

建筑中的"反金字塔模型"是什么

反向金字塔模型是一种系统和协议的设计方法，其中最重要，最起码所需的信息/功能首先被传递并得到保证，并且以渐进和可选的方式添加不太关键的零件。该术语借鉴了新闻学的想法（最重要的是-首先），但适应了工程任务：关键路径在任何条件下都有效，其他一切都是"丰富层"。

直观画面：上面的狭窄顶点是"最低保修合同"（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"有何不同？
反金字塔最初设计了最低限度的足够合同及其优先事项，而不是"事后"试图挽救已经超载的系统。

结果

反金字塔模型有助于建筑和协议在任何负载下保持有用：最重要的是，首先是肯定的；其余的-如果可能的话。这增加了关键路径的可用性，加快了眼镜输出，并简化了演化而不会发生故障。