经过上一篇《.NET-记一次架构优化实战与方案-前端优化》与大家分享了对页面加载优化的心得和经历。虽然优化前端的性能效率,但是由于底层服务的触发方式,根本性问题仍然存在的。
在本系列第一篇文章我们提到,底层服务是一系列的JOB,那么问题主要存在以下两点:
例如:
以上问题直接导致了后续开发、日常维护成本过高。
因为早期开发时缺少沟通,没有封装成公共的方法,而JOB每个开发人员都单独实现了一套,当然他们未必那么蠢,可能是某个先完成了,后续的先前COPY后修改一下。
试想一下,没新增一个任务类型就要重写一份完成任务的JOB和自动发奖的JOB,这是一个N*2的工作量。如果后续有个规则改了,那是不是每个JOB都跑去改一次?
由于任务完成是由定时服务根据业务数据源定时批量执行:
以上问题直接导致了,用户完成任务后无法及时查看完成任务并领奖,如需及时查看状态需要在展示页面逻辑额外添加查询后更新的操作
目的:减少代码冗余,提高可维护性,提高后续新任务的开发效率
具体实施:从业务流程图可以直观的观察出,整个底层业务流程基本一致,只有数据源上的差异,因此可以从以下方面入手优化:
从我角度来看,这种方案处理没有任何坏处的。如果真要计较,那就是所涉及的JOB都得改,但是从上述分析出,如果真要重构,工作量也是在写父类模板和封装公共方法,查询数据源代码是可以复用的。但是带来的收益就是良好的扩展性和可维护性。
该方案主要对任务参与的触发方式变更,不同的任务类型由对应的业务最终流程的完成点进行发送队列消息,由任务服务(消费端)订阅相关消息执行任务完成流程。
通俗讲叫业务埋点,当然也可以称其为事件驱动。
服务之间是高内聚的,它们的耦合度应该很低,当服务需要相互协作时,假设服务“A”需要触发服务“B”中的某段逻辑,平常的方式是让服务A直接串行调用服务B中的某个方法。但前提是A必须知道B的存在,如果B出异常了就会影响到A的正常执行。
这样它们之间就是强耦合的,A必须依赖于B了。这样使得系统更难以维护与扩展,因此引入事件驱动来降低服务间的耦合度。
当服务A需要触发服务B的逻辑时,不要直接调用它,我们可以将消息发送到消息队列,由服务B订阅相应的队列,并在事件发生时异步执行操作。这意味着服务A、B都依赖于中间件消息队列,但他们之间将不需要知道彼此的存在,因此它们之间于此解耦。
如果将此方案引入我们的活动业务中,收益主要分为短期与长期。
事件驱动架构长期收益比短期要大,以RabbitMQ与投资业务举个例子。初期完成核心业务投资理财,投资后我们需要APP通知用户,在此投资无论成功与否都往RabbitMQ发送消息,投资成功RouteKey=TZ.SUCCESS,投资失败RouteKey=TZ.FAILE。APP通知服务订阅队列NoticeQueue绑定RouteKey=TZ.#,其中包括成功和失败的消息,服务根据消息状态发送APP通知。哪天业务拓展需要增加投资成功积分,只需要添加积分服务订阅队列IntegrationQueue并绑定RouteKey=TZ.SUCCESS消息即可。接着又多了任务活动、信用消费等,如此类推。
由此可见,如同广播一样,我不知道你们谁要,如果你们需要的就好好监听着,不需要就当耳旁风。
既然我们使用了RabbitMQ中间件,那么分布式事务会选择基于可靠消息的方案:
这种基于可靠消息的方案,也叫本地消息事务表的方案,可根据自己情况自研解决,也可使用类似开源分布式事务框架 CAP 解决。https://github.com/dotnetcore/CAP
本系列到此基本上分享完了,如果大家有更加好的意见,可在下方评论反馈给我。