亚马逊刊登责任链设计

## 一. 开篇
&emsp;&emsp;&emsp;开篇之前说点题外话。Java做为一门面向对象编程的语言，是十分注重编码规范和架构设计的。但是在很多情况下，很多公司或很多项目团队是为了封装而封装，抽象而抽象反而得不偿失。因此在**合适的场景使用合适的封装才是最好的做法**！！！切记！！！

**源码地址:** http://git.mabangerp.com:2280/m-lis/mdc-product-amazon.git

## 二. 业务背景
&emsp;&emsp;&emsp;亚马逊平台作为公司主力平台之一，一直都投入了大量的精力和人员去做维护。但是每一次有新的业务需求研发都会经过从0到1的过程。而且还需要去解决各自数据中间态的问题。因此现在我们主要是针对我司两种刊登方式: 专业版Excel模板刊登, ERP平台商品刊登进行讨论。
&emsp;&emsp;&emsp;在刊登的业务链路里面，我们需要针对于亚马逊平台调用很多接口，而且接口与接口之间存在着强依赖。同时模板刊登和商品刊登两种方式也存在着**业务交叉**。因此为了更好地去管理这两种方式并且也更好的去维护编码，决定采用**责任链**设计模式来做为本次2.0新架构的托底架构设计(PS: JSON刊登不算在此列。因为还在研究中)

## 三. 旧设计

### 1. 逻辑图

![](/media/202207/微信图片_20220714142128_1657779714.png)

### 2. 弊端
&emsp;&emsp;&emsp;业务逻辑强强绑定，根本没办法拆。比如ERP商品刊登写了这些逻辑以后，后面增加了一个专业版刊登场景，两个场景调用平台接口是一致的。但是因为代码耦合度太高，导致调用平台接口这一块的逻辑没办法拆分出来，也就导致了代码不可复用。而且中间态数据也乱飞，消耗了平台接口令牌也因为后续系统原因会重复调用消耗，重复执行幂等性代码等一系列弊端

## 四. 新2.0设计

### 1. 设计思路
&emsp;&emsp;&emsp;根据上述旧架构设计的弊端,新架构就是为了解决这系列问题。**解决思路就是我们按照面向对象的思维，把上述架构图业务逻辑拆分成一个一个的动作，把每一个动作都看作成节点**。然后所有节点可以看作是一条大的链表。这样从编码角度和业务角度把耦合度拆分。同时节点与节点之间的沟通都通过一个上下文类来作为沟通的桥梁，方便下行节点拿到上行节点的中间态数据，同时如果出了异常那么就可以通过上下文把中间态数据存入DB，最后上下文还充当数据管家作用

### 2. UML类图设计

![](/media/202207/微信图片_20220714143837_1657780751.png)

### 3. 优点
1. 业务耦合度底
2. 随意增删节点，不会影响其它节点业务
3. 能较好处理中间态数据
4. 能更好的处理流程，不走重复业务

### 4. 缺点
1. 事务(如果链路很长，开启了的事务就需要等很久。这会造成锁持有时间过长。解决方式是每个节点都处理各自业务数据，并且在抽象模板层面上做好异常回滚的自有逻辑编写)
2. 请求的传递，在DEBUG的时候比较麻烦
3. 代码编写要求更高，并且要做业务与中间态数据承上启下

## 五. 未来畅想(3.0设计)
1. 有后台系统维护页面，能够在页面上增加链路配置
2. 现阶段针对于每一个步骤数据节点搜集太少,并且强依赖腾讯云日志,后续可以在ES或其它NoSQL里面做生命周期快照。主要是在系统中看数据流向，数据明细等

网上找到如图所示:

![](/media/202207/任务监控页面_1657851979.png)
![](/media/202207/任务详情弹窗_1657851994.png)

## 六. 尾声
&emsp;&emsp;&emsp;如有新想法,请及时联系方罗(Tel:13258230237 Email:fangluo@mabangerp.com)