亿级交易平台：从 0 到 1 设计思路( 三 ) _业务

文章插图
3.3.4.2 流程异步化
非核心业务处理如果混杂在核心链路中，影响核心流程的性能和稳定性。非核心处理剥离出来，异步化处理，提高整体的性能和稳定性。以订单取消流程为例：
图片3.3.5 一致性方案 3.3.5.1 最终一致性事务框架miss-tfc
通常在核心业务流程中存在发送MQ，发起RPC调用第三方、刷新ES等场景，如：在生单流程中，需要在保存数据库后发送一条MQ消息。而以上这些场景是需要保证一定要执行的。当机器遇到宕机这类故障后，这些任务则有几率不会被执行。为了解决以上问题，通常的做法是每个业务写一个任务表定期执行；但是这样做带来的问题是巨多的任务表，维护和操作也不方便，重复的操作逻辑也会散落在各个业务处理中。我们团队miss-tfc框架则是为了解决以上问题而生的，它会把需要执行的任务持久化到数据库中，然后不断的重试补偿动作，直到任务处理成功。架构原理：通过拦截器配置指定类的指定方法保存起来镜像存储到任务表，并且与当前业务的写库事务绑定在一个事务中。等事务提交后，可以选择性的配置实时当前同步线程做、实时异步线程做、异步调度做等。
3.3.6 灰度方案 3.3.6.1 增量数据双向同步
交易平台收敛原来的各业务团队的烟囱式老交易系统，涉及读写流量的平滑切换处理，我们采用【灰度写流量->写全量->灰度读流量->读全量->老系统下线】的方案。在这个过程中，考虑到用户列表等业务场景需要全量订单数据的情况，新老数据库都需要持有全量订单数据，我们用【增量数据双向同步】机制来保障。增量数据双向同步：交易平台的增量数据同步到老订单数据库，老订单系统的增量数据同步到交易平台数据库，使新老订单库同时保有全量订单数据。
图片四、踩过的坑 4.1 过度设计 4.1.1 过早的服务器隔离
在各业务形态流量规模还没有到影响稳定性的情况下，过早的以业务线维度部署服务器达到所谓的服务器隔离的级别，导致了测试机器、生产机器的成本浪费，同时也增加了测试的复杂度和成本。
4.2 依赖组件 4.2.1 核心链路依赖开源组件
订单状态的流转，我们采用了消息驱动的方案；为了与业务代码解耦，消息是用阿里开源的数据库同步系统otter监听数据库订单表的来发出的。支付成功后的履约分发等核心链路也依赖这种消息驱动；某次网络问题导致otter消息阻塞，造成近30分钟的订单不能履约的故障。开源组件本身的设计不足、或者对开源组件没有完全掌握，遇到问题不能快速定位、快速解决，都是稳定性不可控的因素。
五、未来展望
经过了2年多的持续建设，目前交易平台能够高效、稳定地支撑公司业务的快速发展，但还是存在一些功能需要持续完善。
5.1 业务参数动态配置化
目前业务参数配置较为混乱，在系统配置文件(yml文件)、分布式配置中心()都有，静态、动态的区分混乱，导致管理成本高。后续规划建设交易平台配置中心，统一、动态管理业务配置。
5.2 流程编排可视化
搭建业务流程管理中心，能力地图、流程编排可视化展示，流程编排可动态生效。
5.3 订单全链路监控
建立基于订单生命周期全链路的数据流，实时跟踪订单各个环节的处理状态，并将作业数据可视化；有效防止订单流转失败、漏单、超卖等其他系统异常和业务异常情况；掌握各系统作业效率，帮助内部效率提升。
六、总结
在每日优鲜交易平台建设过程中，我们借鉴行业最佳实践，也踩过大大小小的坑，探索并形成了自己的平台化架构建设的方法论，希望对大家有一些启发；同时也欢迎大家来件一起探讨。