设计优步打车服务

要求

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

架构

为什么要微服务？

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 （它能够检测到是否成功递送) 或者
• 短信服务一般更可靠

本文首发于硅谷io