一、 ERP的订单日志并发优化
背景：
订单日志并发量大，日志数据增量很大，影响系统性能用kafka发送消息，创建一个分区即可，发送消息和处理消费分开处理
1、通过发KAFKA异步解耦（原先写sqlserver这里调整为发kafka消息）
2、由于顺序要求，当前TOPIC仅设置一个partition（分区）
3、如果ERP不支持kafka的SDK，则提供一个JAVA接口做为中转（java接口仅在open服务中直接发kafka消息则可，无其他业务）
4、（选择1：推荐）可直接通过seatunnel CDC 直接把kafka消息写入ES或sqlserver（写频率不要过快，如1000条一批，10秒一次等）；（选择2）或在java的zhcxkj-bus-common服务中监听kafka消息，如：10分钟一次写一个csv文件，再发一个rabbitmq文件导入消息，把csv文件导入ES或sqlserver中（rabbitmq是为了保证文件一定导入成功，失败则重新进入队列）
1、手工录入追踪号
2、限重服务
3、erp称重
4、Java计算运费和税费
二、称重是否启用体积重以及相关逻辑改动的优化
问题：
ERP称重从java获取运费规则数据判断是否使用体积重的逻辑有缺陷，目前只要是计费重取值类型是“按条件取值”或运费类型是海运体积就默认是启用体积重，但是按条件取值也有可能是用自定义公式取值
1、直发：按条件取值，取值类型：体积重
2、备货：区间价格+按条件取值
3、备货：海运体积
以上三种类型就是使用体积重的方案，备货+海运体积直接设置为使用体积重的原因是，物流java系统针对海运体积默认就是使用体积重，erp如果配置的是海运体积的话都开启了使用体积重
ERP称重（PC端，包裹列表界面，包裹称重界面）
三、客户订单预报报错重复下单的场景优化
背景：
近期比较多订单提示重复下单，导致获取追踪号失败。
JAVA物流子系统调用物流商平台的预报接口成功后，但是系统数据库超时导致保存追踪号失败了，再次预报就会提示重复下单。
- 如果接口提示重复下单，则自动重新生成一个新的自定义单号，重新调用一次物流商的预报接口。
- 每个物流商接口预报重复下单的场景，接口给出的错误提示都不一样，有的提示自定义单号重复，有的提示已存在，有的还会提示一个因为单词。所以加个配置表，针对每个物流，配置类似重复下单失败的关键词，一个物流支持配置多个关键词。
- 匹配配置表的关键词成功后，自动生成新的自定义单号重新预报一次。