在业务系统中会出现对接外部服务的场景，可能需要对接不同公司的接口，而且功能相似。比如：
- 支付网关调用支付渠道商的支付类接口
- 登录服务需要调用其他公司的登录授权相关接口
- 广告投放服务需要把用户的注册、完件、授信信息回传给广告商
在这类渠道接入服务中需要对接的外部服务功能、协议、参数是相似的，如何最大化的复用代码，快速接入是这类服务的设计难点。
一般的流程：
在代码实现上一般放在一个map里，然后根据请求去执行相对应的 handler 逻辑。
// 初始化 Map<String, ChannelHandler> callBackHandlerMap = new HashMap(); // 具体执行
callBackHandlerMap.get("channelA").callback();
本文主要讨论 ChannelHandler 逻辑部分的实现，路由不在本文的讨论之类。
实现大致可分为三种模式：
暴力模式
这种模式简单粗暴，直接根据外部服务提供的接口文档实现对用的 ChannelHandler 即可。
// 实现
class ChannelAHandler extends ChannelHandler {
@Override
public void callback() {
// 逻辑实现
return;
}
}
// 注册
callBackHandlerMap.put("ChannelA", ChannelAHandler);
// 调用
callBackHandlerMap.get("ChannelA").callback();
但是缺点也很明显，如果出现变化，比如：
- 渠道商测试环境和线上环境不一致
- 渠道接口升级
- 新增渠道
这些都需要重新修改代码，然后发布，效率相对较低。
外挂模式
外挂模式就是在服务中嵌入脚本执行器如lua，处理函数调用解释器执行配置的脚本，解释器返回固定格式的数据，处理完成后返回数据给调用方。
流程如下：
外挂模式解决了暴力模式的上述三个缺点，随时可以更新脚本，新增渠道只需重新配置一个即可。缺点是通用的脚本解释器过重，大部分的功能是用不到的，针对这个问题可用下面一种方式解决。
DSL 模式
外挂模式内置的一般使用的 GPL(General Purpose Language) 通用编程语言，而 DSL 相对的就是，而是 DSL (Domain Specific Language) 领域特定语言：通过在表达能力上做的妥协换取在某一领域内的高效执行，如正则/html等。显然 DSL 完美的符合我们的需求。
其流程图和外挂模式是一样的，唯一的区别在内置的解释器替换成我们自己开发的 DSL 解释器。
总结
在实际的业务场景中我们可以根据需求来选择一种合适的模式。
如果项目刚开始，业务场景不明朗，那么暴力合适是合适的，可以快速的实现需求，实现业务试错。
如果对接的渠道逐渐增多，而且场景复杂，需要负责的流程控制和计算，那么外挂模式合适的。
如果对接的渠道多，但是回传不复杂，那么自己实现一个 DSL 解释器是合适的。
没有绝对的优劣，只要合适的。