由于老路由系统设计之初，只简单从“银行渠道”和“支付通道”两个维度考虑存储信息，设计的表结构比较简单，对于支付通道故障的情况只能切换整个通道。如果是“跨卡通道”的单个银行故障，老系统无法做到只把这故障银行流量切走——要么放任整个“跨卡通道”因为单个故障银行拉低成功率，要么切走整体通道的流量。在新路由系统中，针对每家银行的指定卡种，分别记录“跨卡通道本身不支持”和“跨卡通道支持但是银行系统故障”的两类数据，在执行路由逻辑筛选的时候就根据这些信息进行过滤，实现“跨卡通道”切走单个故障银行。
(2) 配合通道监控系统实现通道的回切放量，试探性逐步恢复通道
解决技术问题(1) 收敛分散的业务和存储逻辑
驱使重构路由系统的一大原因是老路由系统业务逻辑和数据存储分散、系统间的逻辑严重耦合、边界不清晰，经常在系统间模糊地段踩坑。因此，重构后需要将路由逻辑全部收敛到路由系统，这包含两个层面：
代码层面——新路由系统需要整合老路由系统逻辑（Java代码）和上游收银台中的路由逻辑（PHP），划清上下游的职责边界。
存储层面——原来收银台或者交易系统会分别从配置中心、缓存、数据库表、代码配置文件、老路由系统接口中获取不同的数据，数据无法被集中管理。重构之后，全部数据都由新路由管理集中管理，任何上游的数据需求都通过RPC接口请求路由系统。
(2) 系统容量和时效性
由于路由逻辑和基础数据都收敛到新系统，重构后的路由将成为支付路径上的关键环节，用户在美团点评的每次支付交易至少会调用一次路由系统。根据目前美团点评的体量，这对路由系统的峰值容量提出考验。另一方面，由于重构系统需要兼容之前的老逻辑，这会导致有些接口的响应时间达到几百毫秒甚至超过一秒，对内网调用来说是不可接受的。
水平扩容机器是可以解决第一个问题的，但是无法解决第二个问题。基于路由的业务场景是典型的“读多写少”、且基础数据总量有限的情况，数据完全可以缓存在业务机器上，这样能极大地减少对数据库的读取次数。采用本地缓存的方案后，系统接口响应时间由秒级降为毫秒级。由于降低了请求处理时间，一个线程的处理能力也相应提高了数十倍，系统的整体处理能力得到量级提升。
(3) 系统容灾方案
路由系统的容灾主要从两方面实现：
降低对外部组件的依赖性——“本地缓存”的引入使得路由系统处理实时业务请求时，不直接读取外部的缓存中心或者数据库，这样避免了这些基础组件可能带来的风险。
制定服务异常时的备用方案——如果路由系统异常将会直接导致用户无法支付，因而收银台系统需要对路由进行依赖降级，采用的方案是：
a. 路由系统定时从数据库中读取基础数据，并根据路由策略产生兜底数据，同步到配置中心；
b. 当路由系统异常，收银台系统将降级读取兜底数据，保证用户完成支付。
支付通道自动化管理的半自动化阶段持续时间是2016.11至今，故障处理自动切走、自动切回，一次通道故障的处理流程如下：
(1) 监控检测到通道成功率异常发送报警消息给美团点评技术人员，同时自动将通道置为不可用；
(2) 收银台实时读取通道配置，收银台不会再将流量放入该通道，从而将故障通道的流量全部切走；
(3) 监控在将通道置为不可用一段时间后，尝试对故障通道放部分量进来用以检测通道是否正常；
(4) 如果放进来的这部分量成功率正常，监控则继续放2倍的量，直到通道全量，监控将通道置为可用；
(5) 如果放进来的这部分量成功率异常，则将通道直接置为不可用，监控隔一段时间后再继续进行放量，直到通道恢复为可用；
(6) 美团点评技术在发现通道故障后，可以向银行或第三方询问故障原因，并记录，留作日后分析使用。
系统演进到这里，支付通道的管理已经基本实现了完全自动化，只有故障原因等附加信息需要人工获取。
主要解决的问题