一 背景

我们的业务中，经常会遇到多渠道+多场景的的需求。多渠道我们可以理解为，多个服务商同时为我们某一个功能提供服务，多场景就是同一个服务商下面的多种服务，我们通过几个例子来具体看下：

我们有个电商平台，系统在付款时候弹出选项，让用户自主选择支付宝/微信/京东白条等支付，那么这里的支付宝、微信、京东我们都可以理解为他是我们的渠道。
同时，既然接入了支付宝/微信等，我们的系统就不再会单单使用他们的一个支付功能，还会涉及到对账、退款等等操作，那么这些操作，我们称之为场景。

类似的，有的公司需要将订单进行推送，根据订单类型，推送到淘宝、拼多多等。那么淘宝和拼多多也属于渠道，同样的，有了下单，那么还会有退单、订单对账等都属于场景。通过这样的案例分析下来，我们会发现，我们身边有很多这样的需求。如果针对这类需求，我们的代码缺少一些架构设计，那么就会带来很多问题，比如：

• 代码复用度不够，新增需要会产生大量重复的冗余代码；
• 代码耦合度过高，业务逻辑和三方交互代码夹杂在一起，每次改动牵一发而动全身，影响面不好评估。

此类问题应该存在一些通用的解决方案，可以实现以下特点：

• 面向接口编程：业务方调用三方服务的时候，不需要关心具体服务商的实现，只针对接口调用；
• 对拓展开放，对修改关闭：每次新增一个渠道，或者新增一个场景，对已有的代码应该是无冲突的，不需要改动的。

二 案例分析

2.1 下单支付案例

我们以下单支付为案例，通过时序图的流程来梳理下我们的思路：

关于和三方请求的操作，一般就分为两类：

• 请求三方系统；
• 三方系统处理完成，回调通知。

2.2 请求类

请求三方系统的具体流程如下：

不同场景下，流程相同，但是还会存在一些差异点，我们总结一下：

• 通用：数据加签/加密，重试+告警，返回结果解密，操作日志记录等；
• 差异：模型转换字段不一样，发起请求的方式和路径不一样；

2.3 回调类

不同回调场景也可能会存在一些差异，我们总结一下：

• 通用：回调日志记录，数据解密，响应三方系统；
• 差异：模型转换字段不一样，执行业务操作不一样；

2.4 渠道商的拓展

多渠道多业务通过以上分析基本上都是可以枚举的，可以通过以下表格进行拓展：

三 代码实现

代码已开源到Github：https://github.com/Shiyajian/mall-example
代码可能运行有问题，主要展示的是思路，下面是针对项目的讲解。

3.1 设计思路

通过案例分析，我们分析出来了通用和差异点，对于通用的部分，我们采用封装成标准流程，差异的地方，我们定义拓展点接口，不同渠道方各自实现，每个渠道方的代码要物理隔离。

3.2 代码结构分包

代码主要分为三部分：核心业务代码、架构代码、拓展实现代码。

• 核心业务代码：就是我们平常写的业务代码，应该和具体的三方系统交互解耦，面向接口编程，不感知三方系统模型，也不感知具体的渠道实现。
• 架构代码：根据不同的渠道和场景，找到对应的实现，并且提供部分流程编排能力
• 拓展点接口定义：抽象的能力接口和公用；
• 拓展点实现代码：不同场景不同渠道的实现。
  

3.3 spi 接口定义

主要使用策略模式，这里通过接口进行抽象定义，代码主要分为三个部分：

• call ：表示调用第三方渠道商的抽象服务接口；
• callback：表示第三方渠道商回调业务系统的接口，每个场景按包进行细分
• common：一些公用的枚举和标记性接口定义

拓展方式：

• 如果需要新增调用渠道商的接口，那么在 ChannelCaller中定义方法，在 spi-impl 中实现；
• 如果需要新增回调方法，首先在 ChannelCallbackSceneEnum 中增加类型，在 callback 中新增一个包，新建一个 request 模型和 parser 模型，request 表示渠道方传入的参数，parser 表示如何转换成我们业务系统模型；

3.4 spi 实现方式

每个渠道商为一个package，里面实现 call 和 callback 定义的接口即可，按需自己增加常量和工具类等；

3.5 spi的发现及路由

通过 Manger 管理类进行查找具体实现，并进行一定业务逻辑的编排，处理日志记录，错误处理等通用流程。

3.6 业务代码使用

需要调用渠道商接口的时候，通过以下方式进行调用：

@Override
public String pay(ChannelCodeEnum channelCode, Object args) {
    // 1、创建支付单；
    PayOrder payOrder = new PayOrder();
    // 2、支付单入库；

    // 3、根据不同支付渠道，调用三方的支付单创建
    ChannelCaller channelCaller = channelCallerManager.of(channelCode);
    channelCaller.submitPay(payOrder);

    // 4、更新三方订单号入库

    // 5、返回前端唤醒参数
    return payOrder.getPayParams();
}

渠道商接口回调时候，通过下面方式进行参数的转换，转换完成后执行自己系统逻辑：

@RequestMapping("/pay/{channelCode}/{bizNo}")
public ResponseEntity<?> paySuccessCallback(HttpServletRequest request,
                    @PathVariable(value = "channelCode") String channelCode,
                    @PathVariable(value = "bizNo") String bizNo) {

    log.info("进入[" + channelCode + "]支付成功回调：bizNo：[" + bizNo + "] ");

    ChannelCodeEnum channelCodeEnum = ChannelCodeEnum.ofCode(channelCode);
    return channelCallbackHandlerManager.run(channelCodeEnum, () -> {
        CallbackPayRequest payRequest = channelRequestParserManager.parse(channelCodeEnum, ChannelCallbackSceneEnum.PAY_CALLBACK, request, bizNo);
        return payService.paySuccess(payRequest);
    });
}

结束语

上面就是我在项目开发中，针对多渠道+多场景的一些思考及个人的代码设计。由于经验有限，此方案不一定是最优方案，欢迎大家批评指正，感谢。

求职

上份工作由于公司的资金链问题，失业了，现在找份工作，我简单介绍下自己。
优势：

• 8年工作经验，有架构、中台、微服务等经验，有虚线管理（10人以下经验），有中厂工作经验；
• 文档能力较强、代码质量和整洁度较高，有一定代码洁癖；
• 抗压能力强、沟通能力强、技术热情高、喜欢分享；

劣势：

• 简历比较花，最近2年3次被裁，都是因为公司业务问题非个人问题；
• 文科专业，跨行入门。
  如果你们公司是个小而美的公司，而且缺人，感觉我还不错，欢迎 call 我，我个人还是属于性价比比较高的。
  微信： 153 5500 0708 （如果不是推荐工作，单纯交友也可以加）
  不考虑中大厂(阿里、字节、得物等大中厂)，只考虑小厂，创业公司也可以……，不是瞧不上大厂，现在环境下，大厂要求太高，我的简历筛选基本不会过，所以不去尝试了，曾经字节也在HR面被刷了，所以已经对大厂不抱希望了。