交易系统应用架构演进课件

1、饿了么交易系统应用架构演进IAS2017互联网架构峰会石佳宁自我介绍2014年加入饿了么，早期负责BD工具、客服等系统设计研发，最近2年主要从事订单交易、支付结算等系统的架构设计和团队管理。目前聚焦AI在业务场景上的实际应用和落地。大纲当前的形态当时的问题未来的发展当前的形态交易领域交易链路交易系统参与交易的系统新零售订单Blink售后异常Blink集中异常Loki订单主流程EOS订单补充Blink虚拟订单同城送订单准时达保险管理理赔中心用户端商户端物流金融（交易&支付）客服售后H5Echo&Snow运营后台Hesita保险后台风控店铺状态&库存会员卡服务用户端PUSH短信营销红包代金券服务包

2、商户信用分霸王餐服务用户余额time-line交易规则信息触达搜索赔付中心催单&关店正向链路支付失败无效接单完成确认中待接单待支付下单支付成功系统处理取消支付&超时未支付成功接单取消风控拦截确认送达逆向链路无效接单取消中完成未申请仲裁中已申请失败已拒绝成功促使促使直接无效取消订单成功取消失败申请取消确认送达取消订单失败申请取消订单商户拒绝取消失败取消申请申请仲裁仲裁失败同意取消仲裁成功同意取消服务架构业务层核心服务层通用服务层用户端商户端客服金融交易系统平台逆向(售中&售后)运营后台保险后台其他业务系统业务系统开放平台逆向H59(售中&售后)订单主流程新零售单虚拟订单同城订单订单主流程集中异常

3、售后逆向交易支撑准时达理赔中心保险time-line交易规则信息触达搜索赔付中心公共服务交易保障系统架构Web API公有消息广播运营后台垂直领域赔付中心信息触达订单搜索取消流程金额计算物流对接准时达追偿保险GoProxyDALCorvus中间插件订单(正向交易流程)退单(逆向交易流程)基础交易流程主数据记录数据集中异常数据逆向交易数据RedisRedis异步任务MQ(Celery)BansheeSentryGrafanaElogEtrace基础业务服务面向用户产品OPSMQRedis-ClusttorDB当时的问题 = 经验教训 SomeOne“架构层面的一切努力都是为了满足业务的扩展性需要

4、”4. 系统稳定性要求高，不管是新业务上线、老业务迭代、技术改造等，都不允许宕机哪怕一秒。2. 业务越来越复杂，接口和字段越加越多。3. 新业务对老业务会造成冲击，兼容永远是考验功力的。1. 原系统职责庞大，维护和迭代成本很高，需要拆分。但是不知道怎么拆，也很难对这么拆达成一致。案例：订单与物流交互服务订单服务订单运单交互服务运单服务处理和经验：将交互服务的职责还回订单服务和运单服务。如果一个领域和系统的职责是清晰并独立的，那么就应该让它直接被其他各个系统使用。另外对于系统的拆分和领域的识别要有共识，这个共识不仅仅是交互的双方。处理和经验：新增字段一定做评审，如果数据可以有多个承载方，那么看哪

5、一个ROI最高，权衡便捷、风险以及未来维护的成本。同时时刻维护一个清晰的字段说明文档，杜绝语义混乱。案例：某业务功能需要订单加字段处理和经验：新增虚拟订单服务。由业务形态以及当前逻辑的可复用程度决定，尽量服用，拆分（解耦）永远比合并（内聚）容易。案例：新业务形态支持（虚拟订单）整体建议：一直有一张完整全面的架构图，以系统的维度标注出核心主链路，确保其始终清晰。花时间去了解业务和它的发展，为未来做准备而不是直接做未来。架构债务比代码债务更难还，评审checklist以及债务总结必不可少。未来演进思考点：效率 & 效能交易查询管理交易数据运营正向流程逆向流程能力交付用户资产管理交易合同管理交易中台服务跨域服务（聚合分析统计类）流程类服务能力类服务满足契约的其他组件服务店铺商品营销账户物