早期

在支付系统的初始阶段，这一阶段的业务需求比较简单，只需要满足一种支付场景（例如使用支付宝支付）。 为了快速上线，设计方案简单粗暴，直接将支付服务接口暴露给外界，由业务系统直接调用。

系统设计框图如下：

由于现阶段只有一个支付渠道，因此不需要路由系统。 业务系统直接调用支付服务接口发起支付。

这种设计存在很多问题：

业务系统和支付系统在同一个系统中，系统的任何变化都会影响整个系统。 可扩展性问题。 为了接入新的支付渠道，比如微信，需要暴露新的微信支付服务接口。 业务系统需要更改代码。 另一方面，业务系统承担路由系统的功能。 可重复使用性。 对于新的支付渠道，其实除了与支付渠道交互相关的代码之外，其他代码都可以复用。

针对上述问题，对系统进行了相应修改。

首先是将支付系统和业务系统分离成两个独立的系统。 支付系统向外界暴露了一组通用接口。 业务系统只对接这组接口。 如果业务系统想要指定支付通道进行支付，可以将通道标识传入接口参数。 这样，业务系统中耦合的路由功能就会转移到支付系统中。

其次，梳理通道接口文档，抽象通用接口。 如需接入新的支付渠道，只需继承接口并实现相关方法即可，简化渠道开发。

修改后的系统实现图如下：

此时路由系统知识付费系统的一个模块实现如下。

首先定义通用渠道接口，其中方法返回渠道的唯一标识，如支付宝渠道返回。

然后根据方法，获取所有实现相同接口的bean。 最后将它们放入Map缓存中，其中的键值为方法返回通道ID。

此阶段解决方案的问题是支付系统的所有模块都位于同一个项目中。 有些模块需要频繁发布，而有些模块，例如通道模块、路由模块则很少更改。 这将导致系统任何变更的发布，影响整个支付系统的可用性。

中期

针对最初和后续的问题进行了相应的修改。

第一步是将支付系统拆分为模块。 路由系统和通道系统成为独立的系统，可以独立部署和维护。

系统之间的调用采用RPC通信，使用Dubbo框架。

相关实现如下：

相关接口逻辑不变，但同一进程内的调用变成了跨系统调用。

渠道系统提供的服务：

这里改一下，将通道标识符放入Dubbo服务组字段中，并使用Dubbo分组功能标识符中唯一的通道系统。

路由系统引用通道系统的服务：

这里还需要设置组，并且需要和服务商保持一致。 然后将服务注册到路由系统的缓存中，使用通道标识符作为键，通道服务名称作为值。

最后，路由系统依赖于获取特定的服务。

这种设计的问题在于：

通道系统服务需要在路由系统中手动引用，然后注册。 这样一来，增加渠道系统就会比较麻烦。 是否可以在不修改路由系统的情况下增加通道系统，路由系统自动发现服务？

使用 Dubbo API。

后期

查看Dubbo文档，可以直接使用直接搜索服务商。

官方文档表明：

实例非常重，封装了到注册中心的连接和到提供者的连接，需要缓存。 否则，重复构建可能会导致性能问题，并可能导致内存和连接泄漏。 在API方式编程时，很容易忽视这个问题。

此处用于缓存实例。

将之前引用的服务配置文件和缓存注册码全部去掉，引入，修改如下。

总结

回顾上面的路由系统，我们可以看到，早期没有路由系统，整个系统可以继续运行。 但随着系统复杂度的增加，最初的系统架构已经不能满足系统的高效运行，因此系统逐步完善。 在改进的过程中，不断发现方案的不足，然后一步步迭代演进。 在这个过程中，我们要善于利用现有框架的功能，加速功能的开发。