支付处理器动态故障转移路由电视电影小迷妹 TVco.cn

设计概述和实施细节

此写作的目标：

当前在涉及第三方依赖性的支付平台业务功能中构建弹性和容错能力的重要性。
动态故障转移路由—设计概述和实施细节

使用Netflix OSS的Hystrix
设计方案
监控和真实示例

3.提升机会

在Pays平台业务功能中建立弹性和容错能力的重要性：

在Netflix， 弹性和容错能力是生态系统中任何微服务的隐含要求。通过Netflix平台运行时和服务库构建并提供了实现此目标所需的许多基础结构。

同时，还必须为许多业务关键功能建立弹性和容错能力。

在Netflix， 付款平台的角色可以分为以下两个主要类别 ：

客户在注册和重新加入时提出的验证付款方式（MOP）。
续订客户的每月订阅

显而易见，优先级列表上的Zero’th项是在注册和重新加入时出现零故障 。这是通常由Growth Engineering驱动的许多跨职能团队的共同目标。已经采用了不同的合同，机制和监控来密切跟踪此指标。

支付处理器/网关的服务中断（ 在本文中某些地方还使用 术语“ 服务提供商 ” ）并不罕见。中断可以是计划内的 （维护）或计划外的 。提前计划并通知计划的停机时间（例如，通过将流量硬路由到冗余服务提供商）。可以通过更改路由配置以路由到其他服务提供商来应对持续数分钟的计划外服务中断。

但是， 由于各种原因 ， 第三方服务提供商中断仅持续几分钟的情况并不少见 。对于Netflix规模的付款应用程序平台而言， 即使是短暂的中断或不稳定也将意味着相当数量的受影响交易 。

并且显然地，为了实现零故障的目标，期望的功能将是建立考虑服务提供商的可用性/健康状况的动态路由逻辑。

设计概述—动态故障转移路由和实施细节

作为前提条件 ，在深入探讨将动态故障转移路由到其他服务提供商之前，这里是对支付平台的简要概述。

Payments平台应用程序可以分为3个高级逻辑阶段 ：

第1阶段-预处理：

在此阶段中，发生了很多逻辑操作，以丰富“ 正在处理的事务” （在本文后续内容中始终称为“ TUP” ）。 付款处理者选择就是这样一种关键操作 。通过服务提供商选择，根据规则集和配置（决策表）发送TUP的几个属性（例如：国家/地区，货币等），以获取适合 TUP的最适合的服务提供商 。

第2阶段-处理：

此阶段包含特定于服务提供商的处理器服务实现。

TUP 实际上将使用已实现的协议和合同约定的有效负载 发送给服务提供商 。

如上图“ 1”所示。可以看到针对虚构的服务提供商A和B的两种处理器服务实现（即：’ ProcessorService-A ‘和’ ProcessorService-B ‘）。

阶段3-后处理：

顾名思义，在此阶段，发生了一些后处理活动，包括但不限于- 确定TUP的命运，数据存储的持久性，消息转换，上游通信等，

典型的付款处理器服务实施表示

以下是代表虚拟支付处理器“ A”的处理器服务实现的代码段：

如上图“ 2”所示，在每个ProcessorService实现中（即：“ ProcessorService — A ”和“ ProcessorService — B ”），都引入了Hystrix断路器，用于所有对服务提供商的呼出。

以下是使用Hystrix进行向外付款处理器服务调用的简单代码段表示：

注意：

封装在 “ HystrixCommand” 实现中 的 对服务提供者的服务调用
命令密钥-“ PAYMENT_PROCESSOR_A_CMDKEY ”，对付款处理程序’A’的服务调用是唯一的

请参考上面的插图“ 3”：

让我们看一看交易：

预处理阶段：

执行处理选择逻辑，同时读取TUP的“ 主要”付款处理器和“ 故障转移”付款处理器。
在此示例中- 主处理器为“ A”，而其对应的故障转移处理器为“ Z”。
检查付款处理器“ A”是否可用（下面的代码段）
如果支付处理器“ A”可用，则分配“ A”，然后将交易前进到处理阶段。
如果支付处理器“ A”不可用/运行不正常，请分配故障转移处理器“ Z”，然后将交易转移到处理阶段。

典型的处理器可用性工厂表示形式：

增强机会

使用付款处理器可以提供的轻量级ping服务，用付款处理器可用性检查代替内部运行状况衡量指标。
根据以往的经验，仅响应不是一个好的响应，Remi提出了一个有趣的想法，将付款处理器性能数据（批准率以先前的“ n”个时间单位表示）包括在路由决策中。利用hystrix功能实现此目标并不是理想的选择，但可以使用Spectator使用自定义聚合指标来实现。

感谢您停下来阅读。 Saluti！