免责声明。 本文完全基于 Uber 的公开沟通 — 工程博客、会议演讲、开源仓库和外部案例研究。这不是 Uber 的官方架构文档。我们建模公开知道的内容,以说明四千服务的栈如何通过 C4 模型变得可读。当细节是推断而非 Uber 声明时,我们会说明。

一次行程的解剖:用 Archyl 通过 C4 建模 Uber

下雨的曼哈顿星期五晚上 7 点 23 分,一位乘客点击 呼叫 UberX。八秒后,0.4 英里外的司机已接受这次行程,ETA 已计算并渲染,费用已锁定,支付已预授权,乘客和司机之间的低延迟实时通道已打开。当他从手机抬头时,车已经在向他驶来。

这单次点击,在 600+ 城市 中每天重复 超过 3000 万次,在司机屏幕上的第一帧落地之前,要穿越数十个 Uber 系统和三个外部网络。

2024 年,Uber 的栈运行约 4000 个微服务,向其移动客户端提供远超 每秒一百万请求 的峰值,在自己的集群管理器上调度计算,在自己的 MySQL 派生存储层上持久化状态,在自己的六边形网格上索引地球,在自己的状态机引擎上编排数百万个行程工作流,并在自己的 ML 平台上训练 ETA 模型。

如何理解一个有这么多移动部分的栈?像 Stripe 和 Netflix 一样,你不会 — 不是一次理解全部。这正是 C4 模型被发明来解决的问题。

在这篇文章中,我们追踪一个用户操作 — 从点击到司机接受的行程请求 — 并观察它穿越四个 C4 层级的 Uber 架构。我们不会涵盖每个产品;我们追踪一次行程,撰写解释沿途遇到的选择的 ADR,并以拥有每个盒子的团队的地图结束。沿途,我们将巡览 Archyl 提供的每个功能,使这种模型 — 以及围绕它的政策 — 真正可维护。

第 1 级 — 系统上下文:三个平台,一个 Marketplace

Uber C4 系统上下文:Mobility、Delivery、Freight、Marketplace

在系统上下文层,Uber 不是"一个网约车应用"。它是坐在共享 Marketplace 和横切 Foundation 系统栈之上的三个产品平台:

  1. Mobility — UberX、Uber Black、Uber Pool、Uber Reserve、Comfort、SUV、Premier、出租车合作
  2. Delivery — Uber Eats(食物)、Uber Direct(第三方 delivery-as-a-service)、Postmates、酒类、杂货
  3. Freight — 长途货运、Uber Freight Loadbuilder、经纪人工具

在它们之下,Marketplace 平台是真正的大脑 — 匹配引擎、调度优化器、动态定价系统、供需预测器。Marketplace 是把行程请求变成行程的东西。

在它们之下是 Foundation 平台:Maps(路由、ETA、距离/时间矩阵、流量)、Payments、Identity & Risk、Communications(推送、SMS、应用内消息)、Notifications、ML 平台(Michelangelo)、Workflow 引擎(Cadence/Temporal)、Storage 平台(Schemaless、Docstore、Cassandra、基于 RocksDB 的存储)、Streaming 平台(Kafka、uReplicator、Flink)、Observability 栈(M3 metrics、Jaeger tracing、ELK logs)和 Compute 平台(历史上是 Mesos + Aurora → Peloton → 今天基于 Kubernetes)。

它们周围是外部参与者:乘客、司机、eaters、快递员、商户、shippers 和 carriers、地图提供商(他们自己的+回退用第三方)、支付网络 和 收单银行、身份验证提供商、SMS 和语音的 电信运营商、云提供商(Uber 混合运行:自己的数据中心+特定工作负载用 AWS/GCP)、城市级 监管机构。

三个产品平台。一个 Marketplace。十个 Foundation 平台。其余都是细节。

这就是第 1 级的礼物:在系统上下文中,你不需要知道 Mobility 是两百个微服务。你需要知道它存在,它和 Marketplace 对话,Marketplace 和 Maps 对话,Cadence 在底下编排长行程工作流。图是对话的起点,不是清单。

Archyl 功能。 Archyl 中的 系统上下文 图是一个带自动布局、点击穿越导航到容器、允许你静音/突出子集(如"只显示 Foundation 平台")的覆盖层的单个 C4 第 1 级视图。外部参与者是带自己类型的一等 C4 元素,所以它们独特地渲染。

ADR-001 · 用于地理空间索引的 H3 六边形网格

状态 · 接受(2018,开源;2026 年仍活跃)

上下文 · Marketplace 的匹配引擎需要在毫秒内、在城市规模的并发下回答"哪些司机离这位乘客近?",同时支持像 surge 区域、ETA 和供应预测这样的分析。经典选项是矩形平铺(Z-order、geohash、Google 的 S2 单元),但矩形对这个领域有根本缺陷:每个矩形有不止一个 邻居距离 — 角比边远,这产生不均等的距离近似和不对称的"附近有什么"查询。

决定 · 改为用 六边形 平铺地球。构建一个分层六边形网格(H3),从大陆规模到 ~1 m² 有十六个分辨率。每个六边形有六个等距邻居,使最近邻和环查询对称且快速。开源该库,使合作伙伴和 Uber 工程师共享同一网格。

后果 · H3 成为 Uber 跨 Marketplace、Maps、ETA、surge 和分析的空间原语。同一个 H3Index 用在调度热路径和离线预测作业中。它也是 Uber 最成功的开源项目之一 — Foursquare、DoorDash、AT&T 和无数地理初创公司使用它。六边形不能干净平铺的少数情况(二十面体的 12 个五边形锚点)被记录并在生产代码中避免。

在 Archyl 中,这就是 ADR 赢得位置的方式:它解释边界为什么是那个形状。点击任何接触地理空间状态的容器,H3 ADR 离一次点击。

Archyl 功能。 Archyl 中的 ADR 是链接到特定 C4 元素的一等记录。它们作为相关盒子上的卡片出现,可按状态(proposed、accepted、deprecated、superseded)过滤,并以 YAML 形式发送到 git,与代码并存。当有人在 2030 年提议替换 H3 时,现有 ADR 自动作为相关上下文出现。

第 2 级 — 容器:放大 Marketplace 的调度路径

Uber C4 容器:Marketplace 调度内部

乘客的点击落在 API 边缘。让我们打开盒子。

调度路径穿越类似下面的容器:

  • Edge 网关 — 历史上是 TChannel + Thrift IDL,今天是用于移动客户端的 gRPC + HTTP/2 边缘。处理身份验证、速率限制、请求整形和路由。
  • Trip 编排器 — 作为长寿命 Cadence/Temporal 工作流 运行。行程是带确定性状态转换的 工作流实例:requested → matched → arriving → on-trip → completed。幂等重试和定时器驱动的升级是内置原语,而非定制代码。
  • 匹配引擎(DISCO) — 实际的 marketplace 优化器。给定乘客请求和几个 H3 环距离内的实时司机供应,它在每个 tick 解决一个约束分配问题。
  • 动态定价服务 — 结合实时供需信号计算每 H3 单元的 surge 乘数。在请求时输出锁定的费用报价。
  • ETA 服务 — 为路线、流量和到达预测提供 Maps + ML 模型。Uber 的 ETA 模型在 2018 年左右转移到深度学习,此后每年都被精炼。
  • Maps 平台 — Uber 的内部路由引擎、距离矩阵服务和流量摄取管道。在某些市场退回外部地图提供商。
  • Driver state 服务 — 跟踪每个司机的当前状态(离线、在线、行程中)、位置和接受行为。通过自定义地理存储读/写热路径位置数据。
  • Schemaless / Docstore — Uber 的 MySQL 后端分片存储。Schemaless 是较旧的;Docstore 是较新的、多区域、事务性后继者。行程状态、支付、用户配置文件和大多数业务数据住在这里。
  • Kafka 集群 — 每个状态转换都发出一个事件。Marketplace 订阅以进行分析;下游服务订阅以进行扇出(通知、欺诈、会计)。
  • 实时通道 — 一旦匹配,乘客和司机应用之间用于位置更新和聊天的低延迟双向通道。底下由长轮询/WebSocket 网关和 Kafka 支持。

这一级的技术栈:Go 用于大多数新的高吞吐量服务,Java 用于较旧的 marketplace 代码,Python 用于 ML 管道和运维脚本,Node.js 用于一些边缘层,gRPC 作为现代 RPC 协议(TChannel/Thrift 是前任),Cassandra 和 Redis 用于热路径延迟,MySQL 在 Schemaless/Docstore 之下,Hadoop/HDFS/Hive/Presto 用于数据仓库,Spark/Flink 用于批处理和流计算。

典型的行程请求触及 Edge 网关 → Trip 编排器(Cadence) → 匹配引擎(DISCO 对 Driver state 进行 H3 环查询) → 动态定价 → ETA → 通知扇出(推送给司机) → driver-accept 回调 → 实时通道建立。所有这些,带重试,通过 Jaeger 端到端检测,通过 M3 测量。

Archyl 功能。 容器级图 显示每个容器、其类型(api / service / database / message_queue / cache / worker / gateway / library / infrastructure)、其技术(从每组织技术目录中提取)和其带标签的关系。API 合约 可以附加到任何容器并内联渲染 — Uber 会将 trip 编排的 gRPC .proto 直接链接到 Trip 编排器容器。

ADR-002 · Cadence(Temporal) — 构建工作流引擎,不要堆叠有状态微服务

状态 · 接受(~2017,作为 Cadence 开源;作为 Temporal 拆分)

上下文 · 到 2017 年,Uber 有数百个微服务实现长期运行的有状态业务流程 — 行程、订单、注册流、司机入职、欺诈审查。每个都用定时器、重试、幂等性和恢复代码长出了自己的临时状态机。结果:每个团队都付出分布式系统税,故障经常来自重试/超时逻辑中微妙的 bug。

决定 · 不要求每个团队发明状态机。构建一个通用 工作流引擎,带确定性重放、持久定时器、自动重试、信号处理,以及工作流代码读起来像顺序业务逻辑的编程模型。作为 Cadence 开源。在几年内将行程、注册、欺诈审查和资金移动工作流迁移到它。

后果 · Cadence(及其 fork Temporal,现在 Uber 内外都使用)现在是 Uber 每个长期运行有状态流的基础。"行程是工作流"抽象将数千行定制重试代码压缩为少量良好类型化的活动。该引擎也成为业界采用最多的开源工作流项目之一。路径依赖的教训:当十个团队独立重新实现相同的原语时,构建该原语。

Archyl 功能。 像 Cadence 这样的决定波及整个模型。在 Archyl 中,ADR 可以同时链接多个 C4 元素 — 一个决定,多个受影响的盒子。在模型中搜索"workflow"会浮现每个被注释为 Cadence 消费者的容器。

第 3 级 — 组件:匹配引擎内部

Uber C4 组件:DISCO 匹配引擎

在 Uber 栈的所有组件中,匹配引擎 — 内部称为 DISCO — 在会议演讲和工程文章中文档最完善。

单个行程请求,一旦到达匹配引擎,穿越这些组件:

  1. Request normalizer — 将乘客的坐标转换为多个分辨率的 H3 索引(通常热路径用 res 9,环扩展用 res 6)。
  2. Supply scanner — 查询初始 H3 环(~500 m)内所有合格司机的实时 driver-state 索引。按车辆类型、司机接受率和最近拒绝行为过滤。
  3. Ring expander — 如果内环没有合格司机,在同心 H3 环中向外扩展,直到形成候选集或达到最大距离边界。Uber 已经发布了这种扩展策略的多次迭代,包括预测司机可能路径的 ML 驱动扩展。
  4. Candidate ranker — 对每个候选者根据接客 ETA、marketplace 效率(我们想把这个司机留在这个街区吗?)和这个乘客/司机对的历史接受概率打分。
  5. Assignment solver — 将匹配问题制定为本地供应池上的约束优化。求解器持续运行,批处理附近的请求,而不是承诺贪婪的 first-best-match。
  6. Notification dispatcher — 向匹配的候选者发送带短接受窗口的推送通知。将接受/拒绝记录回 driver-state。
  7. 回退路径 — 在求解器超时或没有合格候选者时,用放松的约束(更广的车辆类型、更长的 ETA)重试或升级到 surge。

一旦看到,模式残酷地简单:每个空间查询是一个 H3 环;每个业务决定是一个评分候选者;每个匹配是全局求解器运行的输出,而不是本地贪婪决定。这种形式消除了困扰幼稚调度系统的整个"第一个司机抢费用"反模式类。

这就是组件级 C4 的样子:不是"这是一些代码",而是"这是有业务意义的原语链,每个被拥有,每个可替换,每个可测量"。

Archyl 功能。 组件图 显示容器是如何构建的。每个组件有一个类型(controller / service / repository / handler / module / job / workflow / activity / entity)、文件路径、所有者和技术。组件组成 User Flow — Archyl 的流功能允许你将乘客的旅程作为组件调用的有序序列编写,并将其呈现为分步图。

ADR-003 · Schemaless 和 Docstore — 拥有存储层而不是购买

状态 · 接受(Schemaless:~2014;Docstore:~2020 起)

上下文 · 到 2014 年,Uber 的行程量已经超过单个 PostgreSQL 实例,而当时的现成 NoSQL 选项(Cassandra、Couchbase、MongoDB)有 Uber 不愿为行程和支付数据接受的运营怪癖。行程状态需要强一致的多区域写入、低 p99 延迟和零停机分片。2014 年业界的回应是 "选择一个 NoSQL,接受权衡"。

决定 · 把 MySQL 视为持久基石并在其上构建。Schemaless 用无触发器的仅追加日志、自动重新分片和 JSON 文档 API 包装分片 MySQL。几年后,Docstore 在同一 MySQL 基底上叠加一个强一致的多区域事务文档存储 — 并成为新产品数据的默认。

后果 · Uber 留在了击中几家类似规模公司的"我们将迁移到 NewSQL"/"我们将迁回 Postgres"的繁荣-萧条循环之外。路径是渐进的:新工作负载得到 Docstore;成熟的工作负载留在 Schemaless 直到迁移。两者都由具有深厚 MySQL 专业知识的小型平台团队运营。Uber 全力以赴 Cassandra 的传言?他们使用 Cassandra,但它从来不是行程的 system of record。

这个 ADR 是 路径依赖架构 的好例子:在 2014 年,正确答案是扩展 MySQL,而不是从中迁移。

Archyl 功能。 漂移检测 在这里最重要。当一个新服务开始写入"Schemaless"但 C4 模型仍然说"PostgreSQL"时,Archyl 计算针对代码库的漂移分数并每周标记。ADR 阻止 下一次 漂移:写入新数据存储的新团队必须提交一个提议变更的 ADR,平台团队可以批准或拒绝。

在 Archyl 中渲染的三张 Uber ADR 卡

三个决定。Archyl 中的三张卡片,每张链接到它塑造的 C4 元素 — H3 链接到每个空间容器,Cadence 链接到每个长期运行的工作流,Schemaless/Docstore 链接到数据层。图是现在时;ADR 是为什么。

所有权:把模型变成问责

Uber 所有权图:团队映射到系统

C4 模型在你将团队映射到它之前是一个静态构件。Uber 公开传达其工程结构:强大的 Foundation 团队(Storage、Compute、Networking、Observability、Security、ML Platform、Maps),与 Mobility、Delivery 和 Freight 对齐的产品组织,以及拥有跨产品经济引擎的中央 Marketplace 组织。

把这些放在 C4 模型上:

  • Marketplace 拥有 DISCO、动态定价服务、surge、ETA 平台和需求/供应预测器
  • Mobility Engineering 拥有乘客和司机应用、行程编排器、评分和小费流、安全工具包
  • Delivery Engineering 拥有 Eats 的订单编排、快递员匹配(重用 DISCO 原语)、商家工具和菜单/库存平台
  • Freight Engineering 拥有长途特定工作流:载货匹配、经纪人工具、结算
  • Maps 拥有路由、ETA 模型、流量摄取、H3 库
  • ML Platform (Michelangelo) 拥有模型训练、特征存储、在线服务和 ML 可观测性栈
  • Storage Platform 拥有 Schemaless、Docstore、Cassandra、备份/恢复工具
  • Compute Platform 拥有 Kubernetes 时代的集群管理器和 Aurora/Peloton 的后裔
  • Observability 拥有 M3(metrics)、Jaeger(tracing)、日志管道
  • Security & Identity 拥有 Risk、IAM、密钥平台和与 Marketplace 共享的滥用/欺诈信号
  • Cadence/Workflow Platform 拥有每个产品使用的持久工作流运行时

一旦系统、容器或组件有团队所有者,漂移检测就变得可问责。当一个新服务出现在提交中并且不在图上时,一个特定团队会收到询问。当违反一致性规则时 — "只有 Marketplace 服务可以写入 surge 缓存" — 一个名字在收件箱中。

在 Archyl 中,所有权图是文档工具变成治理工具的时刻。

Archyl 功能。 每个 C4 元素都支持 owners.teams 和 owners.users。所有权图 视图汇总覆盖范围,所以你可以看到(并修复)没人拥有的盒子。这种规模的任何系统中的覆盖差距都是不可接受的 — 那就是 on-call 升级到没人响应的 Slack 频道的方式。

漂移、一致性和四千服务问题

四千个微服务的模型会漂移。严重。Mobility 推出一个功能;一个新的微服务出现;Marketplace 数据合约演变;一个 2019 年弃用的服务终于退役。把这乘以每个团队、每个季度。

Archyl 每周计算 漂移分数:文档化的 C4 模型与当前代码库之间的差距。该数字在 0 到 100 之间。漂移分数 12 可能意味着六个尚未在模型中的新服务、三个图中指向已删除端点的关系,以及一些用不再匹配实际栈的技术标记的容器。

一致性规则 添加策略层。Marketplace 组织可能写的例子:

  • 只有 Marketplace 服务可以从 surge 缓存读取
  • 处理 PII 的每个容器都必须带有 pii:true 标签并引用 Identity ADR
  • 所有公共 API 必须附加 OpenAPI 或 gRPC 合约 — 该合约必须是真相之源,而不是实现
  • 每个容器都需要所有者团队
  • 行程状态变更必须经过 Cadence;直接数据库写入被禁止
  • 新数据存储需要 ADR 和 Storage Platform 签字

Archyl 持续评估这些规则。违规出现在图上、团队的每周摘要中,如果你接入 GitHub Action,作为提交时检查。

Archyl 功能。

  • 模型与代码之间差距的 漂移分数,每次推送时重新计算
  • 作为 YAML 编写、应用于所有 C4 元素的 一致性规则
  • Architecture Change Requests — 提议模型变更的拉取请求式审查,使架构遵循与代码相同的严谨性
  • Architecture Insights — 从漂移 + 一致性信号中由 AI 浮现的异常和建议

对于 Uber 规模的栈,这不是可选的。这是唯一在没有专门架构文档团队的情况下保持模型 诚实 的方式。

API 合约、事件和 marketplace 的神经系统

Uber 的 Marketplace 是一个以高速度交换事件的服务图。行程状态转换、司机位置更新、surge 重新计算、费用报价、支付授权 — 每个变更都发出一个由零到许多下游服务消费的 Kafka 事件。大多数同步服务到服务调用是 gRPC。

在 Archyl 中:

  • 每个容器可以附加一个 API 合约(HTTP/OpenAPI、gRPC、GraphQL 或 AsyncAPI)。规范内联渲染;消费者准确看到他们正在调用什么。
  • 每个异步通道可以建模为带 broker(Kafka)、topic 名称、schema 格式(Avro、Protobuf、JSON Schema)和 schema 主体的 事件通道。生产者和消费者链接到通道。
  • 破坏性变更显示为合约上的 diff — 如果你有需要版本提升的一致性规则,变更被阻止直到规则满足。

对 Uber 来说,那是三千个 topic 和数万个合约从与 C4 模型相同的位置变得可检查。不再有 "谁消费我的事件?" — 模型知道。

Marketplace 规模的 DORA

一旦你有带所有者的 C4 元素,你可以将它们连接到交付遥测。Archyl 的 DORA 模块从你的 CI/CD 和事件系统中提取 部署频率、变更前置时间、变更失败率和平均恢复时间 — 并按 C4 元素和团队 汇总它们。

对于 Mobility 的 Trip Orchestrator,你会单独看到该团队的部署节奏和稳定性,而不是 Pricing 的。对于整个 Marketplace,你会看到整个平台的 MTTR 趋势如何。当 MTTR 飙升时,深入到罪犯容器;当部署频率停滞时,你可以将其归因到特定子树。

Archyl 功能。 Archyl 中的 DORA 仪表板 用团队和元素分解和趋势线渲染四个指标,并将事件与它们影响的架构元素绑定。这就是"我们有可观测性"变成"我们有工程健康"的方式。

然后是 AI 层

4000 服务栈是 AI 编码代理 — Claude Code、Cursor、Windsurf 和其他 — 的天然栖息地。每个 Uber 工程师都有同样的问题:"服务 X 如何与服务 Y 对话,surge 乘数实际上在哪里持久化?"

在 Archyl 中,模型通过 MCP 服务器 暴露。工程师笔记本上的任何 AI 代理都可以问:

  • "列出所有依赖 H3 库的服务"
  • "给我看 dispatch.MatchService 的 API 合约"
  • "哪些 ADR 涵盖存储决定?"
  • "在拥有的服务上生成从 Cadence 到 Temporal SDK v2 的迁移计划"

代理获得与工程师相同的架构上下文。入职缩短。跨团队代码审查停止变成 "这甚至做什么?"。住在脑袋里的上下文现在住在可查询的模型中。

Archyl 功能。 AI 代理的 MCP 服务器,以 archyl YAML、Structurizr DSL、LikeC4、IcePanel JSON 和 Backstage 目录格式 导入/导出 — 使现有架构数据流入而无需重写。项目文档、用户流 和 架构洞察 完善表面。

这种规模组织的完整功能表面

如果你是评估 Archyl 的 Uber 形状的工程组织,这是表面,映射到它在你日常生活中赚取自己位置的部分:

  • 带所有四个层级的 C4 模型 — 系统上下文、容器、组件、代码 — 带自动布局、覆盖层和点击穿越导航。每个图表工具做对的事情;我们做对了 并且 继续。
  • AI 架构发现 — 把 Archyl 指向一个仓库,它自动发现 C4 元素。在一小时内从零到第一个模型,而不是一个季度。
  • Architecture-as-Code — 在 git 中签入、解析和验证的 archyl.yaml。通过 GitHub Action 准备 CI/CD。与代码相同的严谨。
  • 多格式导入 — Backstage 目录(JSON)、Structurizr DSL、LikeC4、IcePanel JSON,以及 Archyl 的原生 YAML。
  • 链接到 C4 元素的 ADR,具有完整生命周期(proposed / accepted / deprecated / superseded)。
  • 带 markdown、附件、链接到特定元素的 项目文档 — 你活的架构手册。
  • 用于 HTTP/gRPC/GraphQL/AsyncAPI 的 API 合约,内联渲染对生产容器。
  • 带 broker、topic、schema、生产者和消费者的 事件通道 — 架构的异步面。
  • 发布 & 环境 — 与架构绑定的版本化部署,显示在图上。
  • 在每个层级具有团队和用户分配的 所有权图。
  • 模型与实际代码库之间的 漂移分数,每次推送时重新计算。
  • 模型上作为策略的 一致性规则 — 编写、评估和强制执行。
  • 提议模型变更的拉取请求式审查的 Architecture Change Requests。
  • 由 AI 浮现的异常、风险和建议的 Architecture Insights。
  • 按元素和团队汇总的 DORA 指标,带趋势线和事件归属。
  • 限定到团队拥有边界的每周每团队摘要的 Architecture Team Digest。
  • MCP 集成 — 团队中的每个 AI 编码代理共享相同的架构上下文。
  • GitHub PR 审查 — Archyl 的审查机器人在影响架构的 PR 上评论,带漂移、一致性和 ADR 上下文。
  • 共享 & 嵌入 — 公共链接、仅团队链接、内部 wiki 的可嵌入 iframe。
  • 图像/PDF 导出 — 用于演示、正式文档和印刷幻灯片的 PNG、SVG 和 PDF。
  • 多语言 — 每个 Archyl 表面都有九种语言版本,包括文档和代理提示。

那是完整的工具箱。对于像 Uber 这样的栈,你大概会用所有的。对于五十服务的栈,你会用与你成熟度匹配的一半 — 并成长到其余的。

你不需要四千服务

你不是 Uber。大多数工程组织不是。

但教训会缩小。将上下文与容器分离、容器与组件分离的纪律,撰写解释路径依赖决定(我们构建了 H3、我们构建了 Cadence、我们扩展了 MySQL 而不是替换它)的 ADR 的纪律,将所有权附加到每个盒子的纪律 — 那种纪律是让五十服务栈不感觉像四千的东西。

C4 + ADR + 所有权 + 漂移 + 一致性 + API 合约 + DORA + MCP — 那是 Archyl 开箱即用提供的。Uber 例子只是 marketplace-和-物流领域中模型最大的合理压力测试。

打开你自己的架构。勾画十个产品(或三个,如果你有三个)。挑出有最令人惊讶的过去决定的那个,放大它的容器。撰写三个解释什么会让新人困惑的 ADR。把团队映射到每个容器。

你将领先于大多数工程组织一年才到达的地方。

想用 C4 建模你自己的架构?从 Archyl 开始。阅读更多关于 为什么 ADR 和 C4 一起工作得更好 或 Architecture Change Requests 如何为你的 C4 模型带来拉取请求严谨。先前的案例研究建模了 C4 中的 Stripe — 一次结算的解剖 和 C4 中的 Netflix — 一次播放的解剖。