设计 Uber
· 阅读需 2 分钟
免责声明：以下所有内容均来自公共来源或纯原创。这里没有 Uber 机密信息。
需求
- 针对全球交通市场的打车服务
- 大规模实时调度
- 后端设计
架构
为什么选择微服务？
==康威定律== 表示软件系统的结构是组织结构的复制。
| 单体 ==服务== | 微服务 | |
|---|---|---|
| 小团队和代码库时的生产力 | ✅ 高 | ❌ 低 |
| ==大团队和代码库时的生产力== | ❌ 低 | ✅ 高 (康威定律) |
| ==对工程质量的要求== | ❌ 高 (不合格的开发人员容易导致系统崩溃) | ✅ 低 (运行时被隔离) |
| 依赖性提升 | ✅ 快 (集中管理) | ❌ 慢 |
| 多租户支持 / 生产-预发布隔离 | ✅ 简单 | ❌ 难 (每个独立服务必须 1) 构建连接到其他服务的预发布环境 2) 在请求上下文和数据存储中支持多租户) |
| 可调试性，假设相同模块、指标、日志 | ❌ 低 | ✅ 高 (使用分布式追踪) |
| 延迟 | ✅ 低 (本地) | ❌ 高 (远程) |
| DevOps 成本 | ✅ 低 (构建工具成本高) | ❌ 高 (容量规划困难) |
结合单体 ==代码库== 和微服务可以带来双方的好处。
调度服务
- 一致性哈希按地理哈希分片
- 数据是瞬态的，存在内存中，因此无需复制。(CAP: AP 优于 CP)
- 在分片中使用单线程或锁定匹配以防止双重调度
支付服务
==关键是采用异步设计==，因为支付系统通常在多个系统之间的 ACID 事务中具有非常长的延迟。
- 利用事件队列
- 支付网关与 Braintree、PayPal、Card.io、支付宝等集成
- 密集记录以跟踪所有内容
- 具有幂等性、指数退避和随机抖动的 API
用户资料服务和行程服务
- 低延迟与缓存
- 用户资料服务面临为越来越多类型的用户（司机、乘客、餐厅老板、吃货等）和不同地区和国家的用户架构提供服务的挑战。
推送通知服务
- 苹果推送通知服务（可靠性不高）
- 谷歌云消息服务 GCM （可以检测可送达性）或
- 短信服务通常更可靠
