前言
大家好，这篇文章我们介绍一下渠道路由，通常在架构设计上会将它作为渠道网关系统中的一个模块，但这里为了更清晰的表现它的职责，我们将其看做是一套位于支付核心与渠道网关之间独立的子系统。本文内容分成两部分：第一部分的内容是路由规则的配置和一些概念的阐释，第二部分是路由系统的设计。
定义
渠道路由是指从渠道列表中选出目标渠道并将支付指令转发至该渠道的过程。
种类
渠道路由按渠道选取方式的不同可以分为静态路由和自动路由，两者的差异在于目标渠道是人工指定还是根据规则自动选取。静态路由，也称之为手动路由，当渠道故障时，无法自动切换渠道，需要人工切换渠道，功能实现上也比较简单，只需一个优先级渠道列表也就能满足需求了；而自动路由，可以根据预先设置的规则动态的过滤掉不满足条件的渠道，从而实现动态切换渠道的效果。如果渠道路由按对外提供服务的形式划分可以分成推荐型和代理型两种路由，推荐路由只负责推荐可用渠道或目标渠道但不负责转发支付指令，而代理路由既要负责选取渠道又要负责为支付核心代理转发支付指令至渠道网关，因此这里将这种路由称之为代理路由。代理路由通常应用于无需交互的场景如代付，这种场景可以直接由路由系统全权负责渠道选取和指令转发；而推荐路由多应用于有交互或部分交互的场景，比如收银台需要展示具体支付渠道如微信、支付宝、招商银行的场景，这种场景就需要路由系统先推荐可用渠道，然后客户选定渠道后由支付系统将支付指令转发至渠道。除此之外，收银台还有另一种展示支付方式的形式，比如展示招商银行、工商银行，但后端其实有多个可选的机构支持招商银行卡支付，这种场景路由系统既要提供推荐路由服务也提供代理路由服务，这里将这种混合的路由形式称之为指引路由，后续我们再详细介绍这种应用层面的路由。
自动路由
上图可以看做是本文所述自动路由的规则配置界面，其中路由规则和路由组是一对多的关系，路由组是路由规则的分流单位，一个路由组可以关联多条需要路由的渠道，只有加入组里面的渠道才会被路由，没加入的不会路由，这样可以防止全局匹配渠道带来的不确定性；另外路由规则中的匹配条件所要匹配的对象是路由场景，路由场景是抽象的表述，具体可以是指交易请求或支付指令或其它，总之这个对象要包含路由场景信息，而路由场景通常由支付信息、商户、客户维度的信息来定义的，但大部分信息源自交易所以这里将这个对象称之为支付指令；最后路由组中的过滤条件所要过滤的对象是渠道，不满足过滤条件的渠道就会被淘汰掉。另外，需要注意的是路由规则需要有优先级，因为在进行规则匹配的时候，可能出现多条路由规则适用于同一个请求，那么此时程序不能因为匹配到多条规则而停止运行，而是应该选取最早创建的路由规则，这样能最大限度保证业务的稳定性，接下来我们看看路由流程，然后再详细看看规则里面的各项配置。
路由流程
在路由系统收到支付指令返回支付结果之前，核心处理步骤有四步：第一步，将支付指令中的交易属性和规则库中每一条路由规则的匹配条件进行匹配，找出与当前交易匹配的路由规则；第二步，依据路由组的分流配置，经过一定计算之后就能确定由那个路由组来承载当前流量；第三步，确定好路由组后，遍历路由组中的渠道，将渠道的属性和过滤条件进行运算，过滤掉不可用的渠道，留下可用的渠道；第四步，根据配置的选定策略，从可用渠道中选出目标渠道，作为支付指令的发送渠道。上面就是路由选取渠道的核心步骤，当然确定了目标渠道之后，还要将支付指令发送到该渠道，等待渠道返回支付结果，之后就是返回流程，如果涉及可重试的状态，还要经过重路由之后才能返回支付结果给客户端。
匹配条件
匹配条件由三个要素构成，分别是交易属性、操作符、值，其中交易属性除了常见的国家、支付方式、商户类别等，还有一些不常见的如：交易金额，终端、商户白名单、商户黑名单等等；操作符通常是大于、等于、小于、包含于等关系运算符，而没有加减乘除等算术运算符；值，就是期望的某一个维度的场景属性值。逻辑操作符默认是”且”的关系，”或”的关系不太常见，所以图中的匹配条件没有表现出逻辑操作符。
分流配置
分流功能主要应用于渠道灰度上线、AB测试、交易分流等场景，常用的分流策略是基于权重分流，其它如随机策略，hash策略应用于真实业务的概率不大，所以我们的配置中没有展示，只有权重分流策略一种，如有需要可以增加分流策略选项。如果需要灰度上线一个新渠道，那么建一个灰度组分流百分之10，运营一段时间无异常之后，就可以全量将流量调整到新渠道，这样能有效减少新渠道不稳定性带来的故障。
路由组
路由组可配置多条能相互替代的渠道，当当前渠道不可用时，通过过滤规则可以实时过滤掉不满足要求的渠道，从而保证业务的稳定性；但过滤规则对于路由组来说不是必须配置的，如果不配置那么路由组下的渠道除了不可用的渠道外其他都是可用渠道，如果存在多个可用渠道的情况无论有无过滤规则，都需要配置选定策略，系统会根据选定策略选取目标渠道。
过滤条件
过滤条件可分为固定的和动态的两种，固定的条件只有渠道状态是每个组都需要的，因此可以不用配置系统默认添加这个过滤条件，动态条件需要根据需求添加，比如常见的余额、日限额、成功率等过滤条件，过滤条件中的渠道属性值，通常是动态的的，需要实时统计或查询比如日限额、余额等；操作符在匹配条件中我们都介绍过了，这里就不再赘述；值类型有常量和变量两种，如果一条过滤规则的值类型是常量，那么该常量值是针对路由组下所有渠道的，而如果是变量，那么该变量值源自渠道配置，变量是相对于渠道来说的，该变量的值每个渠道都可能具有不同的配置，比如限额这个过滤条件，A渠道的限额数值从A渠道配置中获取，B渠道同理。
选定策略
当渠道过滤后剩下多条可用渠道时，我们需要配置目标渠道的选取策略，常见的策略有四种：优先级策略、权重策略、费率策略，综合评分策略。前两种比较简单没什么好说的，至于费率和评分策略，如果渠道费率是固定的，那么优先级就可以完全替代，而综合评分，是从多维度如成功率、延迟、交易额的视角对渠道如进行综合评分，然后选取评分最高的渠道，这种策略由于选取结果的确定性不，所以实际之中都不大会需要这种策略。因此，对于不是特别复杂的路由场景来说，提供优先级和权重两种策略就够了。
指引路由
首先我们先阐明一下支付方式这个概念，支付方式表示支付渠道的支付能力，它按特定维度对渠道进行分类，支付方式和支付渠道之间是多对多的关系，通常一种支付方式可以对应多条渠道，一条支付渠道可以有多种支付方式；那种将渠道本身作为支付方式的情况就比较特殊，这种情况下支付方式和支付渠道是一对一的关系。言归正传，我们看看上面的路由流程：当商户下单完成后，客户打开支付平台的收银台时，收银台会先请求渠道路由系统推荐可用支付方式（中间有其他系统，这里省略了），然后收银台对可用支付方式进行排序、过滤等收银台特定的业务处理后展示目标支付方式给客户，最后客户选定一种支付方式向收银台提交支付请求，收银台将支付请求转发至内部系统最终会到达渠道路由，渠道路由根据路由规则自动筛选、选定渠道并转发支付指令至渠道网关。另外，渠道路由推荐的支付方式可能并不是最终展示给客户的支付方式，因为收银台可能有特定展示支付方式的业务逻辑控制，如排序、数量、显隐控制。
ER模型
上面的ER模型图从左到右，至上而下依次是路由规则、匹配条件、分流配置、路由组、筛选条件、选定策略，ER模型的结构和规则配置界面展示的路由配置结构是一致的，只是不同视角表达同一事物的表现方式不一样，所以这里就不再复述。另外，还有一种简化版的设计，就是将蓝色部分表示的实体用关联实体的一个字段以JSON形式来存储，这样就只需要创建路由规则和路由组两张表，但它们的结构不变，这样可以减少表的数量，前提是这些简化的表的信息只做展示，不做任何查询。
路由模型
上面的路由模型依据的是文章开头那张配置界面所表现的功能而设计的，模型从程序的实现层面表现了路由系统中各个构件如何交互以及它们之间的关系。根据笔者个人的编程经验，好的程序设计结构上应该符合这样一个形式设计原则：整体部分，抽象具体，当一个对象是由多个部分构成的整体的时候如渠道路由服务类以及职责可再“分割“的选择器，那么它的职责是组织串联各个构建或者说是只负责流程编排不负责具体业务规则的实现，而当一个构建不再是整体的部分如匹配器、选定器那么它应该被设计成抽象的，这样整个模型的结构就会符合上面的设计原则，下面我们看看各个构件的详细设计。
渠道路由服务
渠道路由服务对外负责接收支付核心的支付指令并响应支付结果，可以将其看做是渠道网关的一个包装器，这个包装器在渠道网关的能力基础上新增了自动路由，如果是指定渠道，那么支付核心无需经过渠道路由，直接调用渠道网关就可以；对内它不负责具体的路由逻辑实现只负责编排各个构件实现路由功能，伪代码如下：
路由规则管理器
路由规则管理器负责规则的构建和缓存维护，其他构件依赖的数据模型都从路由规则中获取，而不在独立依赖于对应数据的仓储类。它的职责是为路由服务提供路由规则列表，因为国家和交易类型是路由规则固定的维度，所以可以按这两个维度获取路由规则列表，路由规则伪代码如下：
一套系统通常都有两部分，一部分是面向管理的称之为管理系统，一部分是面向过程的通常称之为核心系统，因为职责的差异两者所需的数据模型也有所差异。管理系统负责实体的增删改查，它所需的是单个实体的模型通常修改领域下其中一个实体无需关注另外的实体，而核心系统负责所有业务规则的实现以及流程的控制，它所需的是整个领域的实体以及它们之间的关系，因此路由核心中我们构建了上面这种层层嵌套的路由数据模型。这种嵌套的数据对象模型，可以让路由过程中的各个构件：分流器、匹配器、选择器，不单独依赖于仓储而是直接从路由数据模型中获取对应计算所需的数据。比如接下来要介绍的匹配器，如果路由规则不是以参数的形式传递进去，那么它需要耦合获取路由规则的业务逻辑，而如果是以参数的形式传递它要的数据，那么该构件就和数据的获取逻辑解耦了，职责更加的清晰和明了。
匹配器
匹配器的职责是选出与路由场景相符的路由规则，相符是指支付指令中的交易属性满足路由规则中的匹配条件，比如：只有一条匹配条件的路由规则，它的匹配条件是：交易金额大于10，如果支付指令中的交易金额是15，那么就可以说该支付指令与该路由规则相符。因为匹配条件设计上要求是动态的且要支持各种操作符，因此这里我们基于开源的表达式引擎或规则引擎来实现匹配过程。
路由引擎
这里接续上面的内容来介绍路由引擎如何实现规则的匹配，我们基于阿里的qlexpress封装出路由引擎，为路由提供基于规则的匹配和过滤服务。当匹配条件和交易属性作为参数传递给路由引擎的时候，路由引擎做了两件事情（第三步，第四步）。
条件和条件之间默认是”且”的关系，如果有”或”的关系可以从条件中获取条件之间的逻辑关系。从使用表达式引擎的角度看，实现过程很简单并不困难：把条件解析成符合表达式语法的表达式然后和变量表一并传递给引擎执行器，最后由引擎进行解释执行并返回结果。假设这么一个场景，您在印度某游戏平台进行充值3000，那么游戏平台将你的交易数据提交给三方支付平台，此时该平台有如下两条路由规则，您将命中第二条。
分流器
分流的底层实现是基于分布式的计数器来实现的，比如某条路由规则下有三个路由组，流量以一百为一个单位，三个组分别是20、30、50，那么给该规则创建三个分布式计数器，分别对应三个组，初始计算值就是他们的流量分配值，分流时先加分布式锁，然后随机取一个计数器进行递减，如果不够减取下一个计数器，都不够说明一个单位的分流结束，重置流量就可以了。需要注意的点是规则中的路由组数量发生变化的时候，需要进行流量重置，否则可能分配到一个被删除的路由组。
选择器
选择器的职责类似于渠道路由服务，它负责编排过滤器和选定器实现渠道选取，过滤器的职责有很强的业务关联性，为了便于扩展比如增加重路由过滤器过滤路由过的渠道，因此将其设计成链式结构，而选定器就比过滤器抽象一些，与业务的关联度不高，设计一个选定工厂提供策略的示列就可以了。选择器的核心实现逻辑是：先遍历过滤器列表获取可用渠道，然后使用对应策略的选定器决策出目标渠道。过滤器的实现和匹配器一样可以基于表达式引擎来实现，上面已经介绍过表达式引擎，这路就不解释了，原理是一样的；至于，选定器那就更更不用解释了，按按优先级很简单，按权重上面介绍分流时也介绍过原理都一样，所以不再细说。
重路由
重路由因为是一个比较大的一个模块，作为一个小节介绍，有些不够，所以之后以单独的主题来介绍，这里先跳过。
转发器
转发器是一个负责支付指令转发的构件，可以看做是渠道网关接口的包装类，支付指令最终是要被发送至渠道网关，由渠道网关将支付指令的报文传输到支付渠道。支付指令转发器可以为指令转发扩展延迟转发的能力，当支付渠道故障后为了不影响后续可异步的支付指令的传输成功率，可以通过延迟发送，来减少故障率。
总结
上述程序设计遵循这么一个原则：代码表达概念。如果我们将业务需求中有关的概念识别出来并挨个给与其恰当的定义和分析，然后将这些概念连结起来形成一个整体，我个人习惯将其称之为概念架构，而代码需要通过类或接口来表达概念架构中的要素。这样就能保证我们的代码符合概念的定义并与概念一致，否则很容易出现代码和概念或架构设计割裂的情况。
