设计优步打车服务

免责声明：以下所有内容均来自公共资源或纯粹原创。 这里不包含优步的涉密内容。

要求

• 为全球的交通运输市场提供服务
• 大规模的实时调度
• 后端设计

架构

为何要微服务？

==Conway定律== 软件的系统结构会对应企业的组织结构。

	单体 ==服务==	微服务
当团队规模和代码库很小时，生产力	✅ 高	❌ 低
==当团队规模和代码库很大时，生产力==	❌ 低	✅ 高 (Conway定律)
==对工程质量的要求==	❌ 高 (能力不够的开发人员很容易破坏整个系统)	✅ 低 (运行时是隔离的)
dependency 版本升级	✅ 快 (集中管理)	❌ 慢
多租户支持 / 生产-staging状态隔离	✅ 容易	❌ 困难 (每项服务必须 1) 要么建立一个staging环境连接到其他处于staging状态的服务 2) 要么跨请求上下文和数据存储的多租户支持)
可调试性，假设相同的模块，参数，日志	❌ 低	✅ 高 (如果有分布式tracing)
延迟	✅ 低 (本地)	❌ 高 (远程)
DevOps成本	✅ 低 (构建工具成本高)	❌ 高 (容量规划很难)

结合单体 ==代码库== 和微服务可以同时利用两者的长处.

调度服务

• 由geohash提供一致的哈希地址
• 数据在内存中是瞬态的，因此不需要复制. (CAP: AP高于CP)
• 分片中使用单线程或者锁，以防止双重调度

支付服务

==关键是要有异步设计==, 因为跨多个系统的ACID交易支付系统通常具有非常长的延迟.

• 利用事件队列
• 支付接口集成 Braintree, PayPal, Card.io, Alipay 等
• 通过详尽的 log 来记录所有 event
• 使用具有等幂性、指数退避和随机抖动的API

用户档案服务和行程记录服务

• 使用缓存降低延迟
• 随着 1) 支持更多的国家和地区 2) 用户角色（司机，骑手，餐馆老板，食客等）逐渐增加，为这些用户提供用户档案服务也面临着巨大的挑战。

通知推送服务

• 苹果通知推送服务 (不可靠)
• 谷歌云消息服务GCM （它可以检测到是否成功递送) 或者
• 短信服务通常更可靠