盘古供应链ERP

一、盘古供应链介绍

盘古ERP(供应链、跨境电商)起始于2021年春,项目从商品管理、采购、库存、头程（商品发到国外仓库）、报关、销售、财务，完整支持了公司对外贸易业务。项目采用Spring Cloud Alibaba架构，前端采用vue element，前后端分离开发。数据库采用mysql，一主一从。用mybatis实现数据层，使用redis做缓存，使用nginx实现负载均衡、nacos作为注册中心，gateway实现统一后端入口，xxl-job负责定时任务。该系统通过docker部署rancher + haber + jenkins +k8s 实现了自动化部署。通过前期按照DDD领域驱动规范分析业务需求，逐步将业务拆解成独立的微服务。在编码中我们始终遵循阿里COLA规范,经常对代码进行重构,防止了业务代码腐化。

2021年工作

我于2021年年底12月进入项目组，接手商品管理的供应商功能、财务钱包功能、采购单备货清单功能,并熟悉原有购买系统(易仓) 易仓库位、供应商、库存功能和跨境电商业务流程。

2022年工作

1. 参与对购买系统（易仓）的数据迁移工作，为盘古承接海外仓头程业务做前期准备，通过对接易仓api和解析页面接口的表单数据，使用策略模式组合职责链模式将供应商信息和库存同步到易仓。

2. 开发店铺管理、物流渠道管理、承运商管理、三方仓映射关系、平台sku映射关系，使用python和kettle对公司千家店铺的三百万平台sku关系（国内商品在国外销售平台编码关系）和三方仓关系（国内商品在海外仓库编码关系）进行清洗,最终根据店铺和部门规则将公司无序的数据整理成具90万有唯一性可溯源的关联关系。

3. 负责头程(将国内货发到海外仓)业务中，对接亚马逊、谷仓、天府盛俄罗斯海外仓、橙联EF仓、美国翼飞仓OMS、美国泰仓OMS、英国51Cargo、德国美联、国内春晖边境仓、shiro海外仓,三方物流系统DHL、edis、九方通讯、大麦云。负责部分三方仓出库单、入库单的对接，所有库存同步，所有三方出入库单据的流转。

4.参与报表系统的开发，使用easyexcel针对公司业务需求对头程数据和采购数据报表开发

2023年工作

1. 对22年未对接完的三方仓平台和物流平台进行持续对接，由于团队使用的阿里COLA规范，遵循领域驱动设计，使得上层业务结构几乎不需要改动，只需要针对OPS三方系统的各自模块添加新的分支，非常轻松愉快地实现了可扩展。并针对业务提出的新需求报关（出口商品有国家补贴可以拿增值税发票抵扣税金）进行开发,同时开发合同管理、采购限额、异常单据。

2.由于飞书在23年进行商业化，销售人员流动性比较大，公司打算更换掉飞书，由于我接触过OA系统，考勤系统交给我处理，最开始打算找个开源的，PHP的orangehrm偏向HR全流程、timetrex适合工厂三班倒，定点打卡，没弹性打卡，不符合我们需求。老东家理才网报价六万每年有点贵，不能买断。自己借鉴orangehrm和timetrex，结合业务需求，设计出打卡系统，通过COLA封装好的状态机简化计算流程，实现弹性打卡、请假、假期自动发放、并对接领导实现的工作流。目前已经稳定支撑公司几百人每天上班弹性打卡和请假。为公司节省开支20万。

2024年工作

1. 对接亚马逊订单的出入库，分仓模块 ( 根据订单的客户地址选择有库存并且运费便宜的仓库 )。分仓借鉴我之前解决同步易仓库存的经验，初版使用职责链模式来按步骤处理。对接Cdiscout销售平台的OCTO仓库系统

2.开发自动审核模块，根据业务方规则在分仓后，自动将订单转为已审核。

2. 根据公司宁波仓需求，独立设计中转仓系统，拥有完整的出入库、库存流水、库存管理、和维度统计。

3. 使用flink对公司日志系统进行改造，使用aop切面对接口打标，并推送到rabbitMQ等待flink消费。flink监听kafka中canal采集的mysql binlog日志,通过流式计算将比对结果存入es中。

2025年工作

1.参与开发自有销售平台trusauto独立站，完成出入库单据和库存模块的开发。

2.对初版分仓功能进行改造，加入模板模式，提供分仓策略和复杂分仓策略功能，使业务方可以根据业务需要自己设置尺寸、目的地、仓库、比较运费等功能。

3.完成补货模块(根据海外仓库存自动更新对应销售平台的库存数量)，用户可以设置补货策略，调用亚马逊、沃尔玛、ebay、ozon、cdiscount、allegro、速卖通、temu和我们自己上半年开发的独立站的api完成补货操作。

我认为项目中的闪光点为：

1.项目为微服务架构，团队一直遵循领域驱动设计，使用阿里COLA规范，经常重构代码，业务代码基本不会离开领域层和执行层，修改逻辑非常方便。

2.使用流式计算解决了一些传统方法不好解决的问题，流式计算内存消耗小，基本对数据库没有压力。