美团外卖订单系统演进学习总结

作者: followtry | 2021-01-26 | 阅读
「编辑」 「本文源码」

博客原文

https://tech.meituan.com/2016/09/09/mt-waimai-order-evolution.html

笔记总结

第一阶段

外卖业务架构简单,灵活。用户端、商家端和客服端系统使用的抽取的公共的jar包。

存在的问题

  1. 随着订单提量增加,系统间相互影响大。

解决方案

将订单系统独立,通过RPC接口和MQ方式与其他系统交互。订单系统拆分为实时订单系统模块

第二阶段

订单量提高的日百万单,对订单系统的性能、稳定性和可用性提出了更高的要求

解决方案

  1. 异步化: 将不紧急的流程异步化。MQ异步,线程池异步。对于线程池异步执行,需要通过JVM的优雅关闭来保障安全关闭。
  2. 并行化: 对于相互不依赖的RPC请求,并行执行,通过线程池方式,降低接口串行请求的RT
  3. 预计算:对于已消耗的减免配送费金额等提前计算,并通过MQ更新(增加或减少)
  4. 一致性优化:流程支持重试和幂等,对于失败的流程可以通过重试使其尽可能多的成功。
  5. 预占:下单预占库存(2pc第一阶段),下单成功则使用资源(2pc的提交),下单失败则释放资源(2pc的回滚)
  6. 高可用: DB、ES高可用,中间件高可用。
  7. 降级、熔断、限流:保护服务自身,避免下游把自己拖垮,也避免上游流量太大把自己压垮。

第三结算

随着业务单量增加,存储问题比较突出,扩展性差。数据库写性能近极限。

解决方案

  1. 将数据库拆分,分库分表,zebra中间件屏蔽分库分表差异。解决数据的写问题
  2. 通过将数据同步到ES,解决数据搜索的问题
  3. 主库后挂多个从库,解决数据的实时读的问题

总结

随着业务系统发展,系统设计也在逐渐演进,从单体到分布式,从同步到异步等

主要演进方案总结为:

  1. 业务系统拆分,核心系统和非核心系统不同的处理优先级。独享资源和共享资源
  2. 数据存储拆分,通过增加分片等方式扩展数据读写能力。
  3. 业务流程拆分,将核心流程和辅助流程拆分、异步化。提高核心流程的服务能力。
  4. 稳定性提升,业务支持重试,幂等。支持限流,熔断,降级等自我保护操作。
  5. 并行化,将互不相关依赖并行化,提高整体的响应时间。
  6. 辅助系统支持,通过增加ES来提升搜索能力,增加redis存储来提升流程处理能力。

以上是截止到发文的2016年的演进过程。而我在美团工作时也了解到,外卖系统也在做单元化,异地多活的工作,在系统可用性和灾备隔离上做的更好了。


版权声明:本文由 followtry 在 2021年01月26日发表。本文采用CC BY-NC-SA 4.0许可协议,非商业转载请注明出处,不得用于商业目的。
文章题目及链接:《美团外卖订单系统演进学习总结》




  相关文章:

「游客及非Github用户留言」:

「Github登录用户留言」:

TOP