Largrange项目架构与设计回顾 (二)

在Largrange项目架构与设计回顾 (一) 里面我讲了一下项目开始架构和技术选型的一些内容。这一章来聊聊业务设计上的这点事。

总体来说项目设计的时候,我们对业务模块的划分和拆解总体上来说都是遵循着高内聚,低耦合的原则来进行划分的。大部分和业务相关的服务,都还是能很好的进行功能划分的。但是有一些和具体业务关联性并不是很高的服务在界定与实现时出现了一些问题。

任务调度服务

由于平台方面会有一些控制命令下发给Android设备,而且下发的命令并不一定都是实时的,大部分都是指定一个时间来下发,所以在设计的时候就考虑到需要一个任务调度服务(以下略称cron),来处理这些下发指令以及未来可能会有的定时批处理任务的业务需求。技术选型的时候考虑到整个服务是构建在Kubernetes上的一个分布式的微服务架构,所以就没有选择Spring Scheduler,而是使用了Quarter来支撑整个cron。

从技术选型上来说cron没有什么问题,但是在设计如何使用cron上还是有点问题的, 我们先来看看已推送服务为例,整个平台中cron的处理流程是怎样的。

1. Platform 调用 cron的创建定时任务Job的接口(接口的参数为推送时使用的相关参数)
2. cron 创建Quartz的Job和Trigger,并将Job和Trigger的Name(Quartz中Job和Trigger的唯一标识符)返回个Platform
3. cron 在指定时间触发推送的Job,即调用Push服务的推送接口
4. Push的推送接口调用第三方服务商的推送服务,并将第三方推送服务的调用结果返回给cron
5. cron通过调用Platform预留的推送服务回调地址将第三方推送服务调用接口返还给Platform
6. Platform 将第三方推送服务的调用结果留档保存,并继续业务处理

设计之初考虑到不想在cron中牵扯到具体的业务, 所以设计了一个Platform的回调接口来处理推送后的具体业务处理。虽然保证了cron尽量减少了和业务逻辑接触与数据库的访问。但是前前后后要访问集群内部的其他微服务2次,额外增加了网络开销,以及因为网络通信造成额外的通信失败风险。而且针对每种不同的定时任务,都需要额外开发一个QuartzJobBean,很难形成统一的QuartzJobBean来进行处理。今后如果还有相似项目还是需要重新考量一下如何设计一个更加完善的定时任务。

总结

暂时就想到了这些东西,今后想到啥还会继续在这里补存。