H项目心路历程记 (一)

前言

2021年年中从前一家公司离职，经过朋友介绍到了现在公司参与了Halfling项目(以下简称H项目)，并从零开始的设计开发到第一个客户交付的全部流程。

H项目是一个面向零售行业在电商时代的智能一体化中台产品。项目最早是从2021年中开始立项投入，期间经过数个版本迭代，以及2022年初的魔都封城等诸多困难。终于在2023年Q2季度完成了针对首个客户的上线。

作为从头开始全程参与项目的技术人员，经过2年多的产品研发期间有不少想吐槽和想说的。

业务设计

最初H项目是以打造一个面向零售行业业务中台为目的进行项目立项的，其中一个很重要的点就是希望除核心组件以外都可以独立售卖。所以在架构设计的使用当下最流行的微服务架构(基于Spring Boot + Kubernetes集群的解决方案), 再做业务拆分到服务的时候，进行了更细颗粒度的拆分。所以前前后后一共拆分了近20个微服务。

实际上到了2022年Q2前后，两个核心服务订单管理和库存服务实现以后发现，各个业务服务中间的耦合程度比想象中的还要精密，单个服务拆开单独售卖几乎不可能(应该说是完全不可能)。 然而由于服务拆分的过细，导致一个服务需要频繁访问其他服务获取大量数据。尤其类似订单关联数据比如商品的主档数据，会穿越好几个服务。而每个服务都会重复去获取主档数据，造成了大量的额外请求。 虽然最后在所有服务底部兜底使用同一个Redis作为缓存来减少额外的请求调用。

随着时间来到2023年产品组负责人离职后，整个H项目的方向有从行业的业务中台降级成中小企业的订单管理系统(Order Management System, OMS)。前期做的很多设计比如用户权限体系(当初需求是要精确到每个页面的每个按钮，如果下拉列表框有外调请求也需要做权限控制)等就显的很重，导致用户在使用以及配置都很不方便。而有些设计就显得稍显欠缺。 所以整个2022年Q4到2023年都是在对业务层上反复横跳，比如库存模型和商品模型的调整。这点是相当影响团队士气，同时也加剧了研发组和产品组之间的矛盾。

然后还有一个很重要的问题是多租户的态度上。早起项目是以服务中大体量客户为目的，所以设计之初并没有考虑多租户的问题。但实际项的进展过程中发现部分中大体量的客户也需要类似多租户的功能。这类客户需求与其说是需求多租户，不如说是希望有一个多租户级别的数据隔离，每个业务部门只能操作自己的业务部门的数据(数据包含商品，品牌，属性，平台店铺，订单，售后单据等)，而总部依据可以查看一些汇总信息(例如销售对账单据等)。而随着2022年疫情状况严峻，很多中大客户对于内部平台升级和替换都变的更加谨慎和保守。所以当项目方向变成中小企业OMS时，多租户SaaS化的需求就更加迫切了。所以后期如何在原有系统上在扩展一套多租户SaaS化功能也是个课题。

中间件

H项目使用的中间件中比较特别的有分布式任务管理系统xxl-job，消息队列RocketMQ，这两个中间件都是第一次使用。关于这两个中间件也有不是可以谈谈的。

分布式任务管理系统 XXL-JOB

作为一个开源的分布式任务管理系统，xxl-job足够简单且相当容易上手使用，无论是基于Spring，还是原生Java做开发都是相当简单的。

而不足之处也很明显，最近1年版本迭代速度明显变慢，有些功能和BUG都有待处理的。比如想实动态创建定时任务这类功能就必须自己动手去对xxl-job-admin(调度中心)进行修改。

对于任务执行日志这块，现在xxl-job也是文件格式在执行器所在服务器上进行输出的，当执行器容器化或是运行在Kubernetes集群中的时候，当容器或是Pod重启后，就会丢失日志。这点在后期运维以及调试上还是有点麻烦的。

消息队列 RocketMQ

阿里出品的消息队列如果基于云产品来使用的话问题不大(阿里云卖的价钱也是有点黑的)，但是在运维上还是有点问题的比如Topic,Group这些东西都只能人工去添加，阿里云并没有提供导入服务。全系统如果使用消息队列的场景多的话，维护这些Topic和Group还是很酸爽的。还有一点RocketMQ重复消息这一点是无法保证的。用阿里云的原话

绝大多数情况下，消息是不重复的。作为一款分布式消息中间件，在网络抖动、应用处理超时等异常情况下，无法保证消息不重复，但是能保证消息不丢失。

实际运用上，在大数据量并发的情况下，我们实际上是遇到了消息重复消费的问题。这点还是需要通过代码干预(例如增加一个唯一MsgId，对MsgId做分布式锁来解决)。

还有一点就是在旧版本SDK的默认配置下消费者的负载是有点小问题，总是有一个节点会比其他节点更容易消费到大量消息。据阿里云自己说明在新版本SDK的默认负载配置也已经修复这个问题了。

(未完待续)