设计 Uber

免责声明：以下所有内容均来自公共来源或纯原创。这里没有 Uber 机密信息。

需求

uber architecture

==康威定律== 表示软件系统的结构是组织结构的复制。

	单体 ==服务==	微服务
小团队和代码库时的生产力	✅ 高	❌ 低
==大团队和代码库时的生产力==	❌ 低	✅ 高 (康威定律)
==对工程质量的要求==	❌ 高 (不合格的开发人员容易导致系统崩溃)	✅ 低 (运行时被隔离)
依赖性提升	✅ 快 (集中管理)	❌ 慢
多租户支持 / 生产-预发布隔离	✅ 简单	❌ 难 (每个独立服务必须 1) 构建连接到其他服务的预发布环境 2) 在请求上下文和数据存储中支持多租户)
可调试性，假设相同模块、指标、日志	❌ 低	✅ 高 (使用分布式追踪)
延迟	✅ 低 (本地)	❌ 高 (远程)
DevOps 成本	✅ 低 (构建工具成本高)	❌ 高 (容量规划困难)

结合单体 ==代码库== 和微服务可以带来双方的好处。

==关键是采用异步设计==，因为支付系统通常在多个系统之间的 ACID 事务中具有非常长的延迟。