跳到主要内容

设计优步打车服务

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

要求

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

架构

uber architecture

为何要微服务?

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

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

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

调度服务

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

支付服务

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

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

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

通知推送服务

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