中台夜话20211129

1 问题：零售业务和金融业务的核心差异

• 零售行业交易通道比交易记录重要，先保证可以进行交易，交易记录可以后补。
• 金融行业交易记录比交易通道重要，如果没有交易记录，就不允许交易继续。

用一个具体的例子来解释一下这个核心差异，比如说你去便利店买一瓶水，只要你付钱商家就会把水给你，这个商家可能都不在乎这笔交易有没有记录。但是如果你去银行办理银行卡，我们都知道不是提供了申请材料就可以直接拿到卡的，这些申请材料必须要先保存好记录，然后还有人对这个记录审核确认无误后，并且这个审核都要记录后，柜员才敢把银行卡给你。

理解了零售业务的交易通道比交易记录重要，那么要保障交易通道应该怎么做呢？

2 如何保障零售业务的交易通道

首先，维持下单服务的可用性是实现零售业务交易通道连续性的核心措施，即便面对各种复杂的内外部风险，支撑核心业务的数字系统要满足两个要求：不允许出现大范围的交易故障，交易故障要可感知可修复，修复过程要可靠可预测。翻译一下就是，不要全挂，挂了能快速复活。

为了满足这两个基本要求，Z 同学制定了相应的策略：

2.1 解决“不要全挂”

满足“不要全挂”的首要策略是风险隔离，通过构建按外部风险因素正交性划分、相互独立的多个运维单元实现，也就是把整个系统拆小，一个外部风险只影响有限的运维单元。划分运维单元的方法有：

• 按区域划分，比如华南，华中，华北，或者具体到省市分别都是不同的运维单元
• 按渠道划分，比如电商渠道，直营渠道，加盟渠道，代理渠道相互是不同的运维单元
• 按业务线划分，比如日用品业务线，食品业务线，保健品业务线是不同的运维单元

这个策略说起来简单，但每个运维单元不可能具备所有系统功能。比如说 CRM 这种天然具有中心化特征的系统，不可能在每个运维单元都部署一个 CRM。所以 CRM 只能部署在主中心，但是运维单元又不能因为主中心出问题了，或者和主中心的通信出故障了就没法进行交易了。那怎么办呢，Z 同学给出的架构解决方案是把直接影响交易通道的用户登录功能从主中心的的 CRM 中分离出来，每个运维单元能够独立处理用户登录，从而保障交易通道的连续性。

2.2 解决“挂了能快速复活”

满足“挂了能快速复活”的首要策略是故障转移，在一个运维单元发生故障以后可以快速的转移到相近的运维单元，这时候需要路由分发机制和数据同步机制的支持才能实现快速故障转移。

针对这个策略的具体实现 Z 同学分析了三种场景：

• 第一种是主中心出故障了，这个时候因为对主中心的架构设计是双活机制，所以如果只一个主中心出问题是完全不会影响交易通道的。
• 第二种是区域的运维单元出故障了，这个时候依据架构设计会把故障区域的交易流量切换换到其他区域的运维单元，所以对交易通道的影响是分钟级的。
• 第三种是两个主中心所在城市都出现了网络故障，这个时候依据架构设计基础的交易通道依然可以保证，但是比如像优惠卡卷，用户注册这种中心化的服务就暂时不能使用了。

3 夜话讨论部分

A 同学：感觉主中心和区域部署单元不是按高可用来区分的，而是按业务分类来分的？那是否能解决全局高可用的问题？

Z 同学：当时考虑的一个思路是我们希望聚焦在主价值链上，我们不期望支持所有的业务场景。所以业务连续性的范围缩小到下单这一个业务流程上，保证这个业务流程的连续性。区域部署单元可以独立支撑完整的下单流程。

A 同学：业务数据是否有分区策略？

Z 同学：如果按照运维单元进行数据分区，这个架构设计会产生更复杂的数据同步和一致性问题，所以没有对业务数据进行分区。

B 同学：对于入口流量的路由机制，是如何处理的？

Z 同学：我们的方案是建议基于用户特征，确定入口流量切片机制。比如可以按区域切片，按渠道切片，按负载切片。按区域切片对数据同步要求低，实现方式灵活，采用静态路由或者自定义路由都可以实现；按区域切片对数据同步要求低，实现方式只能采用自定义路由方式；按负载切片对数据同步要求高，必须采用复杂的动态路由方式实现。

4 夜话小结

对于零售行业的业务连续性这个命题，在数字行业通常使用的一个概念是高可用。但不论叫什么名字，本质都是对企业架构提出了质量要求。这篇业务就针对大型分布式线下零售企业提出的不要全挂，挂了能快速复活这两个质量要求，制定了两个架构策略：

• 风险隔离
• 故障转移