开发日记—供应商系统优化方案
开发日记—供应商系统优化方案
背景
如题，最近接到的一个技术需求：优化老项目的代码，需求已经结束了，复盘一下整个过程和方案，大致的背景是：目前我所负责的项目中的商品，库存以及订单等数据需要和供应商做数据同步，商品数据和库存数据需要即时从供应商处获取，订单数据需要推送给供应商发货，并且后续持续同步物流数据。
如图所示，模式并不复杂，可以说是简单清晰，那么有什么可以优化的呢？
实际情况比图示要复杂的多，做过类似事情的朋友应该都知道，对接外部系统远远要比自己写代码复杂的多，情况也更加多变，更不可控制，所以目前主要的问题有以下几个：
- 代码复用差。由于历史原因，目前在项目中，四家供应商四套代码，四套定时任务，这样的代码冗余严重，维护也很困难，再加上下半年要接入多家供应商，所以需要统一接口，理想的结果就是所有的供应商使用同一套代码。
当然了，理想情况是这样，毕竟之所以有现在这个现状就是因为虽然数据大体是一致的，但是在接口对接的细节上各个供应商的差异很大。
所以目前对结果的最优预期是：所有供应商统一一套接口，代码实现部分酌情统一，尽可能的剥离差异点，实现核心代码的复用
- 代码性能差。虽然定时任务不需要太在意性能，但是现在的代码没有注意过任何性能问题，也不太合适，例如：查询到供应商数据之后是遍历一条一条更新数据库的，性能着实有点太差了。再例如所有代码都是同步单线程的，不能很好的利用系统的性能，最好异步多线程。
- 其他的细节问题：
1. 请求优化，应该可配置每次请求的数据数量
2. 几乎所有的数据都需要轮表，那么查询要优化，不能出现selecAll的情况，可能OOM
3. 做好关键数据的记录，涉及到库存，订单等数据的改动，要做好记录，并且不能影响主流程
等等
方案分析
通过以上的简单说明，我相信大家应该对问题有了基本了解。那么说一下第一期的优化方案吧。
关于这次项目优化，核心目的是三个，1.所有供应商接口要进行统一，2.所有的数据库操作环节要保证性能，3.复用 复用 还是复用。
数据库更新优化
首先优化的内容是供应商数据请求和数据库操作，这两个部分和具体的业务实际上没有关系。
关于数据库操作，以库存数据为例
简单分析
- 异步改造
1. 现在的代码是先调用供应商接口查询到所有数据，然后再进行数据库添加操作，且不说性能如何，大对象多了容易OOM。所以查询操作和数据库添加操作应该是互相分离的，一边查询一边添加数据库，同时进行。
2. 如图所示，查询到库存数据之后，需要进行三个数据库操作，一个主流程操作，剩下两个对主要业务影响不大，那么就需要让后两个操作不影响主流程，解耦。
- 批量更新。这一点没什么可说的，数据库修改应该是批量的，性能更好。
确定方案
- 针对第一点，最终采用了观察者模式。具体分析和实现后续文章展开来讲
- 针对第二点，Mybatis 动态sql + Spring重试机制可以解决问题。具体分析和实现后续文章展开来讲
接口统一封装
统一所有代码和定时任务，倒没有什么太细节的方案，接口抽象，一个Java程序员基本的素质，只能说面向对象 yyds。
最终实现了所有供应商使用同一套接口，而不同供应商差异部分做对应SDK的封装处理。同样具体分析和实现后续文章展开来讲
结束
本文先介绍一下相关的背景和方案，后续文章再来讲细节实现展开，同时由于各位看官老爷的技术背景不同，实现中的相关技术设计模式，重试机制，批量更新，反射封装等也会有相关教程提供，保证各位能够学有所获。
作为秋溢路某厂不知名 Java 专家，实战经验还是有一些的，所以本系列文章不同于以前的文章，将会围绕自己开发中的相关问题进行展开，希望大家可以增加项目经验和解决问题的方案角度，暂定的文章更新顺序为：
- 供应商系统优化
- IM 和 推送系统 设计开发优化
- 结算中心 设计开发优化