IAS 饿了么交易系统应用架构演进.pptx

饿了么交易系统应用架构演进自我介绍2014年加入饿了么，早期负责BD工具、客服等系统设计研发，最近2年主要从事订单交易、支付结算等系统的架构设计和团队管理。目前聚焦AI在业务场景上的实际应用和落地。大纲当前的形态当时的问题未来的发展当前的形态交易领域交易链路交易系统参与交易的系统物流售后H5EchoSnow商户端金融（交易支付）用户端客服运营后台Hesita保险后台理赔中心订单主流程EOS虚拟订单新零售订单Blink准时达集中异常Loki订单补充Blink保险管理售后异常Blink同城送订单催单关店time-line搜索交易规则赔付中心信息触达用户余额风控霸王餐服务商户信用分店铺状态库存营销红包／代金券服务包短信会员卡服务用户端PUSH接单接单确认送达下单支付成功系统处理待支付确认中待接单完成取消支付超时未支付成功取消风控拦截支付失败无效正向链路取消申请接单已拒绝失败促使仲裁失败商户拒绝申请仲裁确认送达申请取消取消失败取消失败申请取消订单直接无效同意取消完成未申请已申请仲裁中取消订单失败取消中仲裁成功同意取消取消订单成功无效成功促使逆向链路业务系统业务层其他业务系统平台逆向(售中售后)开放平台逆向H59(售中售后)运营后台保险后台用户端商户端客服金融交易系统交易支撑交易保障核心服务层虚拟订单同城订单准时达保险理赔中心新零售单订单主流程订单主流程集中异常售后逆向通用服务层公共服务time-line交易规则信息触达搜索赔付中心服务架构Web API公有消息广播垂直领域面向用户产品物流对接金额计算保险追偿基础业务服务OPS订单搜索信息触达取消流程……准时达……Etrace运营后台……Elog订单(正向交易流程)退单(逆向交易流程)赔付中心基础交易流程Grafana中间插件GoProxySentryDALCorvusDBRedis-ClusttorMQBanshee主数据记录数据集中异常数据逆向交易数据……RedisRedis异步任务MQ(Celery)系统架构当时的问题 = 经验教训“架构层面的一切努力都是为了满足业务的扩展性需要”– SomeOne1. 原系统职责庞大，维护和迭代成本很高，需要拆分。但是不知道怎么拆，也很难对这么拆达成一致。2. 业务越来越复杂，接口和字段越加越多。3. 新业务对老业务会造成冲击，兼容永远是考验功力的。4. 系统稳定性要求高，不管是新业务上线、老业务迭代、技术改造等，都不允许宕机哪怕一秒。订单运单交互服务订单服务运单服务案例：订单与物流交互服务处理和经验：将交互服务的职责还回订单服务和运单服务。如果一个领域和系统的职责是清晰并独立的，那么就应该让它直接被其他各个系统使用。另外对于系统的拆分和领域的识别要有共识，这个共识不仅仅是交互的双方。案例：某业务功能需要订单加字段处理和经验：新增字段一定做评审，如果数据可以有多个承载方，那么看哪一个ROI最高，权衡便捷、风险以及未来维护的成本。同时时刻维护一个清晰的字段说明文档，杜绝语义混乱。案例：新业务形态支持（虚拟订单）处理和经验：新增虚拟订单服务。由业务形态以及当前逻辑的可复用程度决定，尽量服用，拆分（解耦）永远比合并（内聚）容易。整体建议：一直有一张完整全面的架构图，以系统的维度标注出核心主链路，确保其始终清晰。花时间去了解业务和它的发展，为未来做准备而不是直接做未来。架构债务比代码债务更难还，评审checklist以及债务总结必不可少。未来演进思考点：效率 效能导购类前台服务品牌促销会展开放平台流量接入：手淘／京东...517会场……小程序接入：微信小程序...交易查询管理交易查询管理交易查询管理交易查询管理交易中台服务跨域服务（聚合分析统计类）交易查询管理交易数据运营……能力类服务流程类服务交易合同管理逆向流程能力交付满足契约的其他组件服务正向流程…………用户资产管理后台基础支撑服务商品账户物流店铺营销……谢谢大家今天对于架构演进的主讲内容聚焦在业务架构以及实践经验上。业务系统的演进和架构主要取决于业务场景的定义和发展，多数公司业务发展到一定体量后，纯技术层面的架构是大同小异的，因为要考虑的点主要是大流量和高并发带来的性能、数据可靠和稳定问题。而业务架构带来的不同更多的体现在对业务发展的影响上，有正向也有负向。这里对架构形态的介绍在当前饿了么的体量下，系统是如何划分和组成的。几个典型的纠结、为难和犯过错误的案例，以及对他们的总结。架构的演进总是有阶段性的，合理的架构不是无休止的自我演变，是契合业务的变化。这部分是为了介绍一下当前系统的大致形态以及我们的基本业务流程。饿了么内部的业务系统是严格按照领域进行认知和划分的，所以对于开发人员需要清晰领域、链路、系统几个概念的定义。这会帮助我们更加清晰的明确业务和系统之间的关联，以及系统的职责边界。交易领域是