四：资源注入业务重构

背景:

所在位置：资源注入这块业务在对接运营商服务流程中位置如下图，主要步骤：按照不同省份不同渠道方规则，注入资源及信息到运营商cdn.

做资源注入这块业务时，当时的线上环境是，一个省份运营商渠道一个组件，可怜得服务器，已经无法承载更多得服务，当时我们也为此做过讨论，是继续按渠道拆分还是其他方案，但在我认知中：服务的演进是由串行的服务，到nginx或者交换机负载到多个串行服务，而分布式方案的引进主要是针对在同一个串行任务中，可能某个节点的耗时影响整个服务效率，而分布式的架构可以动态扩容单个节点的数量来达到在节约资源的基础上，提高整个系统的运行效率。而DDD的设计模式基于领域模型的方式，将基础元素及整个流程各个节点作为领域对一个串行任务拆分，也完全适用于我们的业务。

1、根据业务流程进行领域模型的拆分：

元数据：视频、专辑、剧集（反射封装常用方法，用于拼装工单）

节点：构建工单，发送工单，回调结果

2、工单生成设计：

（1）实体类顶层领域模型: Series(剧集), Programs（节目单）,Moves（视频），根据渠道继承对应实体类。使用装饰模式，利用反射方式实现实体对象拼接xml，及对象关系拼接xml方法；

例如：

（2）打造各渠道对应service:实现构建订单接口根据渠道业务逻辑构建对应渠道订单并将订单信息保存入库。

（3）任务队列: 建立任务表，存放对接数据和发送报文，走定时调度任务队列，根据不同渠道，去调用不同的三方接口。

3、接入新渠道流程：

（1）开发实体类

根据渠道报文，编写对应实体类继承领域类（位于leantk-api组件），更新项目版本，打jar包到maven库。

（2）编写对应实现类

继承BuildOrder接口，实现对应的newXml方法，实现拼装报文上传ftp,报文信息入数据库功能。（位于leantk-server组件）

（3）type类型对应实现类配置 （位于leantk-server组件）

 （4）推送方案配置 （位于leantk-scheduler组件）

   webservice配置：WebFace类，新增type类型对应渠道接口地址;支持xcf,ws1.4主流

http方式配置：WebTask类., 新增type类型对应http调用方式

（5）回调方案

     Webservice类型：位于leantk-scheduler组件webFace2Service类，根据工单id匹配具体工单,更新订单状态，返回执行状态，大部分省份不需要调整。

     http类型: 位于leantk-stub组件，需要根据具体需求，实现修改数据表状态，并回调资源平台功能。

4、工单下发注入流程