序
来到京麦团队一年多，回顾这一年的工作，是时候对我们京麦交易平台做个总结了，那么京麦交易平台从无到有，从0到1都经历了什么呢？下面跟随笔者看看交易平台的系统演进及如何稳定的对外提供支付能力的。
正文
京麦交易平台是为我们内部系统附能交易能力的支付平台，它包含下单、支付、结算等核心功能，其次还是涉及了一些发票、优惠券的其他业务，我们致力于打造一个平稳、高效、开发的交易平台，接下来笔者会从0到1介绍一下我们交易平台。
一、插件市场
为了提高京麦的开放能力，打造一个从服务商入驻、服务提审、审核发布、订购履约及
服务商订单查询的交易生态闭环，设计初始我们搭建了京麦插件市场，为服务商和商家提供了交易桥梁，实现了PC版和移动版的插件市场，这个时候并没有交易平台的概念，我们将整个交易流程都放在了插件市场中，下图是整个交易生态系统的功能架构图：
接下来随着我们业务的发展，插件市场中不断有新的服务商接入，也有我们自营的商品发布，此时我们的系统显得过于臃肿，业务复杂导致我们系统之间交互也变得复杂，所以为了更好的支撑业务，并使系统更加稳定、易扩展，将支付交易能力解耦出来，我们决定打造了京麦交易平台。
二、交易平台
由于接入系统较多，业务需求非常复杂，对系统稳定性及扩展性要求非常高，所以交易
平台采用了组件化设计，将系统拆成5大核心组件分别是交易网关、结算页、订单中心、支付中心、补偿机制，满足了业务需求。
下面就交易平台的设计思想及几个关键的功能点，来看看是如何稳定、高效易扩展的。
组件化
首先通过对交易平台的组件化设计，对系统功能进行复用，自由组合实现不同的业务，如：交易平台目前支持2种接入方式，来满足不同接入系统的接入需求。
1、交易网关—>结算页—>订单中心—>支付中心
2、交易网关—>订单中心—>支付中心
引导路由
由于系统业务的复杂性，商家进入结算页展示哪些支付方式的逻辑是非常复杂的，并且随着业务的发展，未来判断的逻辑更加复杂，大量的if else语句令我们非常痛苦，新增一个条件变的异常复杂，因此我们设计了引导路由，将影响的支付方式的条件抽象出一个路由规则，每个路由规则都是可以自定义配置并且可插拔的，那么根据每个路由规则计算出的支付方式取交集，得出最终的支付方式输出到结算页。
订单状态机
对于一个交易系统来说订单状态的流转是核心中的核心，为应对订单状态的不断增多，以及状态流转的复杂性不断增大，我们设计订单状态机，采用了设计模式中的状态模式，实现对订单状态的统一管理，扩展订单状态只需要增加新的状态类和行为即可。
补偿机制
对于交易系统来说，支付成功率就代表着系统的稳定性，一笔订单能否及时完成并进行后续履约对用户来说是至关重要的。由于系统之间不可避免的会出现网络抖动、接口不稳定的情况，这就会导致订单卡单，对用户来说是不可接受的 ，那么对于这种异常情况，设计了相应的补偿机制，及时修复异常数据，并使订单状态继续向下流转；除此之外对于每一个重要的支付结算步骤都会记录日志，方便对问题订单的追踪和恢复。
在线支付：定时任务反查对账单。
货款抵扣：推送结算单失败后，立即自产自消MQ进行失败重试。
经验与总结
在整个交易平台一步步走到今天，踩过很多坑，遇到过很多问题，在解决问题的同时，也成长了不少，也有几点小收获：
1. 核心思想，系统间一定要做好解耦，不断拆分。
2. 尽量使系统组件化或者说是在系统设计时，要考虑到复用，不要重复造轮子。
3. 做好系统监控，系统出问题是正常的，如何快速定位、解决问题才是关键。
架构视频学习
分享一些架构学习的视频资料，想要的可以自己去领取。
当然还有更多，这边就不一一列举了，你如果觉得你能全部吃下，也不挡着你要到更多。