作为电商产品，交易在严选的业务中承担着重要的角色。随着业务的不断发展，交易场景的定制化和差异化开始凸显，同时第三方支付合作方的接入也越来越多，如何在保证交易服务安全稳定的同时做到良好的扩展和弹性是近一年严选在分布式交易架构中思考和实践的重点。
很荣幸，InfoQ 采访了网易严选技术经理，ArchSummit 全球架构师技术峰会讲师 马超，从核心数据模型迭代、服务架构演变等方面介绍严选商城在交易环节的分布式技术架构实践。（马超也会在 7 月深圳 ArchSummit 峰会上分享《大道至简 - 严选售后服务架构演变实践》话题）
（为便于完整展示严选技术迭代历程，文章将对话在不改变原意的基础上进行第一人称改写）
严选分布式交易架构演变简史
严选把交易环节定义为能够促成买家和卖家达成契约的动态过程，而不是简单的把交易和支付直接画上等号。在大多数电商领域，除了货到付款等特殊场景，契约一般都以支付成功的订单形式达成，因此交易架构需要能够很好的支持电商最核心的下单和支付环节。
初期刀耕火种阶段，严选商城业务量小，商品数量少且差异小，用户从购物车到下单再到支付的交易模式相对单一。 于是在结算页面生成订单的同时，数据库中冗余了一条支付相关的记录，使支付的金额和订单结算金额保持一致。然后以此为中介通过一个简单的支付服务来对接微信、支付宝、网易支付三大支付机构，引导用户在客户端完成订单支付，最终再把支付记录的状态同步到订单中去。整个架构简单直接，运转起来也非常高效。
早期刮骨疗伤阶段，随着业务发展，严选交易场景开始出现多样化和差异化。 最开始是在支付环节，比如联合登录帐号体系的建立带来了更多第三方支付机构的接入，我们发现这些第三方支付机构的接入标准和方式存在较大差异，甚至交互模式都有所不同，同时以企业购、拼团为代表的独立业务模块也迅速发展起来，这些业务的订单生命周期和规则不同，存储也比较离散，很难与原有的支付服务中的支付记录建立映射关系。原有架构多个功能模块糅杂在一起显得臃肿并且不好扩展，线上质量也无法保证。因此我们快马加鞭做了架构调整与服务拆分，将支付服务拆分为支付系统和收银台系统，支付系统的范畴缩小到主站订单支付状态管理；而外部支付机构的收银、退款等业务都交给收银台系统负责，将订单与支付信息的关联换成了严选内部唯一的交易流水号。
严选收银台架构图
通过架构升级，能够实现比较灵活的配置能力，不同帐号在不同产品模块和终端上可以看到不同的收银定制页面，极大的满足了上层业务方的诉求。同时收银台屏蔽了对接第三方的模式差异和复杂性，在设计中将支付通知服务、退款服务全部统一成异步回调模式，降低了上层业务接入的复杂性。
中期韬光养晦发展阶段，在支付环节经历架构升级的同时，商品的差异性也开始对下单交易环节产生影响，比如商品类别属性和商品运费。 这里以礼品卡为例，礼品卡是一种特殊的商品，用户购买绑定后可以作为资金在交易环节使用，电子礼品卡不需要履约配送，但是需要对接额外的制卡服务，此外在礼品卡购买过程中还需要根据金额判断是否需要实名认证。在初始的架构中我们对这种商品在交易的每个环节都做特殊处理，但是耦合比较深，随着虚拟商品 (点卡、话费) 和非标准商品 (眼镜、定制品) 的不断出现，技术团队对原有架构做了升级，抽象出了交易模板的概念，交易模板可以在结算页面提供定制能力，比如是否可以使用礼品卡、是否可以使用优惠券 / 红包、是否需要用户填写额外的附加信息。不同交易模板产生的订单还会附加上不同的交易标识，用于后续的业务模块对接和订单中心处理。
目前百花齐放阶段，我们正在着手的工作是礼品卡平台化，提供可以配置的礼品卡的消耗和逆向策略，使其和支付系统、收银台系统共同构建严选的基础交易服务矩阵。 同时还在考虑扩展交易模板的能力，以其为中心能有效的把下单结算环节和基础交易服务矩阵有效连接在一起，通过平台配置化能力支持不同业务模式下的交易场景。
未来，严选规划能在现有交易架构逐渐立体化的情况下更近一步，形成完整的严选交易中心平台，交易中心平台不仅囊括了包括购物车服务，下单服务，支付服务在内的通用交易能力，还将提供完整交易的编排能力，为上层业务提供更加可靠的支持。同时在严选模式往线下拓展的情况下，也在主动探索交易模式的线下场景化，实现线上线下数据打通，为消费者带来更好的购物体验。
交易架构实践过程中的技术积累
在严选整个分布式架构演变过程中，一方面很好的满足了系统高可用高吞吐的诉求；另一方面，像大部分互联网公司一样，也碰到分布式架构中常见的数据一致性、资源均衡性等问题。在解决这些问题的过程中，慢慢沉淀出了严选自己的一些中间件。
交易流程管理 - 分布式锁和分布式事务
首先来说分布式锁。dlock 是严选可重入、可阻塞、可超时、高可用、高性能、低成本、可弹性伸缩的分布式锁中间件（整体架构如下图所示），其设计目标主要有两个：
对分布式环境下资源的访问进行同步，适合多机器、多进程、多线程、单线程等场景；
替换高开销、高成本、扩展性差的数据库锁。
dlock 可适配多种类型的缓存基础实施，比如 Redis、Memcached、Zookeeper 等，dlock 的容量可根据需求水平伸缩。
dlock 支持 3 种不同类型的锁重入策略，分别为：线程级重入、进程级重入、分布式重入，这些重入策略可以完全满足严选业务各复杂场景对对分布式锁的诉求。
其次是分布式事务。为了解决交易过程中分布式系统之间数据的一致性，严选自研了分布式事务中间件 DTS。DTS遵循 BASE类型，是一种典型的 TCC(Try/Confirm/Cancel)类型事务，整个 DTS的架构如下图所示：
DTS针对两阶段提交做了优化，叫做最末参与者优化 (LPO):分布式事务发起者没有两阶段，只有单阶段，即在所有参与者第一阶段准备好后，它的提交结果直接决定分布式事务的成功与否。
交易资源管理 - 核心资源隔离机制与策略为了拦截刷单、***等异常流量，同时也对正常用户流量进行合理限制，严选自研流量限制 & 应急熔断中间件 eudemon。eudemon 将对 CPU、MEM、DB 等资源访问的抽象前移到方法调用、页面访问的层面，通过对方法调用、页面访问的限制间接达到对资源过载的保护。eudemon 的整体架构如下图所示：
eudemon 对流量进行了两个层面的控制：
拦截刷单和***流量：通过对流量主体的行为特征进行分析可以拦截掉 99% 以上的刷单和***流量，不让这些黑产流量来与正常流量竞争系统资源，同时减轻下游风控系统的压力。
正常流量的控制与熔断：对正常用户流量进行合理限制，削峰填谷，始终保证涌入的流量不超过系统的负载，同时在紧急情况下对业务进行熔断。
如何做资源隔离？系统越来越趋向于分布式架构，服务节点越多，级联失败导致单节点故障在分布式架构下被放大。在专注于流入流控 eudemon 之外，严选研发了一个专注于流出流控的资源隔离中间件 aegis。
分布式链路中，一个服务依赖的多个下游服务时，因为某一个下游服务不可用或者响应很慢会影响当前服务甚至引起雪崩效应。我们之前线上碰到的比较典型的就慢 SQL，一个慢 SQL 的出现导致数据库的 load 飙升，导致 DB 基本短时突发性不可用，从而导致整个服务或系统的不可用。
aegis 的资源隔离流程如上图所示，使用了动态隔离机制，可以按业务维度进行隔离。比如使用分布式数据库的场景，可以只对其中某一个出现故障的 DB Node 进行隔离，而不是对整个分布式数据库进行隔离。
总结与思考 - 严选中间件实践的核心理念
严选中间件一直以来都秉承以最低成本解决最核心技术问题的理念，秉承技术驱动业务的信仰，始终以业务为核心做好 360 度支撑。中间件的建设遵循“开源 + 自研”的双引擎模式，开源为主，自研为辅，反馈开源。 站在开源巨人的肩上，可以降低严选的研发成本，通过自研又可以很好的弥补开源的不足，通过反馈开源为开源世界的繁荣反哺严选的技术力量。
大促交易中的挑战与应对之道
电商中的大促是对架构设计和平时技术积累的最好考验。作为一种特殊的高并发场景，其峰值往往是平时的数倍甚至几个数量级的差距，一些看似稳定的系统和服务在极端的并发情况下也可能暴露出问题。
周期较短的大促活动中，交易链路显得尤为重要，从购物车到下单再到支付，任何一个环节出现故障都可能会影响到运营活动的效果。回顾严选在历次大促中的表现，交易系统面临的主要挑战有这几类：
数据库资源的合理使用
支付服务的稳定性和及时性
外部***的防御
数据库是交易系统依赖比较重的组件，对数据一致性要求非常高。以下单为例，我们一般会使用事务来保证强一致性，不过随着业务的发展，事务变得臃肿，在高并发场景下性能变差，数据库资源很容易成为瓶颈，轻则影响部分数据节点，重则影响整个下单服务甚至整个交易环节。为了保障大促，严选对事务进行了拆解，梳理出核心业务和非核心业务，非核心业务尽量采用异步化和补偿的机制来完成，核心业务的事务粒度降低到最低，采用分布式锁和分布式事务进行落地。拆解后，事务大小趋于合理，同时在 DDB(网易分布式数据库) 中，选择合适的用户分区策略，把不同用户的事务有效分布到不同的数据库节点上，避免热点问题。
支付的稳定性和及时性是另外一个比较大的挑战，大促中如果支付服务发生抖动或者回调不及时都可能在短时间内给用户造成比较大的利益损失，客诉也会增多。在增强监控的前提下，我们还会对资源进行严格的隔离和划分，保留一定的机动性，及时隔离一些服务不稳定的渠道。同时还会准备好主动查询以及重试的策略，在回调发生故障时能够及时切换到备用方式。同时还在用户端做了一个小优化，增加了一个支付处理中的等待文案给用户以安抚。
此外，交易系统也可能受到外部***的威胁，线上的刷单、刷券等恶意行为时有发生，如果直接使交易接口暴露在***下，交易资源就会发生倾斜，严重的可能拖垮整个服务系统。因此我们在交易系统外构建一个可靠的防护罩来保护核心用户的利益。和业界的普遍做法类似，严选的防御也从入口层开始，通过访问特征识别恶意请求进行第一道防御；在业务服务之上，还有了一个接口粒度的防护组件，可以通过 mvel 语法对交易环节的重点接口进行干预；核心交易业务服务逻辑中一般还会接入风控查询接口，对用户进行精准分析。 通过这三层防护，严选的核心链路得到了有效的安全保证。
最后说说严选的大促保障流程与策略，主要分为三个阶段。
首先是评估阶段，以资源评估准备和压测为主。通过分解大促测算的指标，设定系统关键交易链路的接口吞吐以及响应指标，评估现有系统容量是否满足要求并制定相应的扩容方案。同时在模块压测以及全链路压测中了解服务的现有指标，结合测试报告分析出瓶颈并制定优化方案。
然后是准备阶段，在这个阶段我们会详细制定大促交易环节的限流降级以及容灾预案，比如针对秒杀交易场景，也会准备至少两套库存管理方案，当服务出现故障时能够及时进行切换。所有的交易环节确认是否有监控缺失，从购物车到结算页到收银完成针对每一个潜在的交易失败的场景制定相关的发现、解决和补偿计划，并落实到具体负责人身上。预案全部完成后会和测试一起通过全链路压测与局部模块测试进行有效性验证。
最后是实施阶段，即便做了充分的准备，线上还是可能出现各种意外的状况，当大促中发生故障时，及时止损是第一原则，这时候准备的限流甚至熔断等预案都是可能派上用场的，同时要立马着手分析原因并做出最小代价的修复方案，即时发布到线上。
标签：服务,严选,成功实践,支付,架构,交易,分布式 来源： https://blog.51cto.com/15057858/2691722
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。