.NET-记一次架构优化实战与方案-底层服务优化

简介: .NET-记一次架构优化实战与方案-底层服务优化

前言

  

经过上一篇《.NET-记一次架构优化实战与方案-前端优化》与大家分享了对页面加载优化的心得和经历。虽然优化前端的性能效率,但是由于底层服务的触发方式,根本性问题仍然存在的。


问题分析

  

在本系列第一篇文章我们提到,底层服务是一系列的JOB,那么问题主要存在以下两点:

  • 代码冗余
  • 时效低


代码冗余


例如:

  • 领奖方法不统一,一次性的写一套,可循环的又写一套。



image.png


  • 每个类型任务都需要独自的实现该任务的完成任务 JOB 与发放奖励 JOB

  

image.png


  

以上问题直接导致了后续开发、日常维护成本过高。

 

因为早期开发时缺少沟通,没有封装成公共的方法,而JOB每个开发人员都单独实现了一套,当然他们未必那么蠢,可能是某个先完成了,后续的先前COPY后修改一下。

  

试想一下,没新增一个任务类型就要重写一份完成任务的JOB和自动发奖的JOB,这是一个N*2的工作量。如果后续有个规则改了,那是不是每个JOB都跑去改一次?


时效低


  

由于任务完成是由定时服务根据业务数据源定时批量执行:

  1. 定时任务频率低,则导致数据集中过多处理


  1. 定时任务频率高,则导致 Job 对数据库的压力剧增或者 99%的无用查询,无结果并不代表不会造成消耗,因为查询都是要经过下面步骤,建立连接、词法分析、语法分析、选取执行方式、到存储引擎读取数据、返回客户端。


  1. 随着数据源数据量增加,查询耗时也逐渐增加


  以上问题直接导致了,用户完成任务后无法及时查看完成任务并领奖,如需及时查看状态需要在展示页面逻辑额外添加查询后更新的操作


优化实施


流程图


image.png


方案一(抽离公共点)


目的:减少代码冗余,提高可维护性,提高后续新任务的开发效率


具体实施:从业务流程图可以直观的观察出,整个底层业务流程基本一致,只有数据源上的差异,因此可以从以下方面入手优化:


  1. 抽离出唯一的自动发奖 Job,发奖JOB基于【任务完成结果】进行发奖,逐步去除原个性任务自动发奖 Job。


  1. 自动发奖与手动领奖的具体执行流程一致的,可将其封装成公共方法。分别由H5领奖按钮与领奖JOB进行调用。


  1. 任务完成 Job 使用模板模式,由基类统一业务执行流程,每个任务类型只需继承任务父类,再由子类重写查询数据源。当然也可以简单粗暴点不使用设计模式,把查询数据源后的完成任务的方法封装成一个公共方法供不同任务类型的JOB去调用。


从我角度来看,这种方案处理没有任何坏处的。如果真要计较,那就是所涉及的JOB都得改,但是从上述分析出,如果真要重构,工作量也是在写父类模板和封装公共方法,查询数据源代码是可以复用的。但是带来的收益就是良好的扩展性和可维护性。


方案二(业务埋点)


该方案主要对任务参与的触发方式变更,不同的任务类型由对应的业务最终流程的完成点进行发送队列消息,由任务服务(消费端)订阅相关消息执行任务完成流程。


通俗讲叫业务埋点,当然也可以称其为事件驱动。


架构图


image.png


事件驱动架构

  

服务之间是高内聚的,它们的耦合度应该很低,当服务需要相互协作时,假设服务“A”需要触发服务“B”中的某段逻辑,平常的方式是让服务A直接串行调用服务B中的某个方法。但前提是A必须知道B的存在,如果B出异常了就会影响到A的正常执行。

这样它们之间就是强耦合的,A必须依赖于B了。这样使得系统更难以维护与扩展,因此引入事件驱动来降低服务间的耦合度

  

当服务A需要触发服务B的逻辑时,不要直接调用它,我们可以将消息发送到消息队列,由服务B订阅相应的队列,并在事件发生时异步执行操作。这意味着服务A、B都依赖于中间件消息队列,但他们之间将不需要知道彼此的存在,因此它们之间于此解耦。

如果将此方案引入我们的活动业务中,收益主要分为短期与长期。


短期收入


  1. 减少无用重复的查询:无需重复查询数据源,只需由业务端推送可靠的消息,减少对数据库的多余压力


  1. 用户体验良好:时效性高,原集中时间点批量处理,现分散到不同的时间点执行


  1. 伸缩性优秀:RabbitMQ 自带负载均衡功能,在消费能力不足情况下,可以做到业务无损的动态横向扩展。虽然JOB也可以做到,但是需要对物理表做特殊处理,增加中间状态


长期收益

  

事件驱动架构长期收益比短期要大,以RabbitMQ与投资业务举个例子。初期完成核心业务投资理财,投资后我们需要APP通知用户,在此投资无论成功与否都往RabbitMQ发送消息,投资成功RouteKey=TZ.SUCCESS,投资失败RouteKey=TZ.FAILE。APP通知服务订阅队列NoticeQueue绑定RouteKey=TZ.#,其中包括成功和失败的消息,服务根据消息状态发送APP通知。哪天业务拓展需要增加投资成功积分,只需要添加积分服务订阅队列IntegrationQueue并绑定RouteKey=TZ.SUCCESS消息即可。接着又多了任务活动、信用消费等,如此类推。


由此可见,如同广播一样,我不知道你们谁要,如果你们需要的就好好监听着,不需要就当耳旁风。


复杂点


分布式事务

  

既然我们使用了RabbitMQ中间件,那么分布式事务会选择基于可靠消息的方案:

  1. 消息可靠性:保证业务端的本地事务执行成功的同时也保证队列消息正常发布


  1. 消息补偿:保证消息消费端的正常消费,如果消费失败后需重新投递,如果重新投递失败可由补偿服务补偿发送。


  1. 幂等处理:因存在自动重试机制,避免重复执行业务导致的意外问题。


模型图

  image.png


  

这种基于可靠消息的方案,也叫本地消息事务表的方案,可根据自己情况自研解决,


也可使用类似开源分布式事务框架 CAP 解决。https://github.com/dotnetcore/CAP

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
29天前
|
存储 SQL 关系型数据库
Mysql高可用架构方案
本文阐述了Mysql高可用架构方案,介绍了 主从模式,MHA模式,MMM模式,MGR模式 方案的实现方式,没有哪个方案是完美的,开发人员在选择何种方案应用到项目中也没有标准答案,合适的才是最好的。
114 3
Mysql高可用架构方案
|
19天前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
47 8
|
25天前
|
监控
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
通过引入稀疏化和角色多样性,SMoA为大语言模型多代理系统的发展开辟了新的方向。
33 6
SMoA: 基于稀疏混合架构的大语言模型协同优化框架
|
1月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
11天前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
23天前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
1月前
|
运维 Serverless 数据处理
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
81 1
|
2月前
|
监控 API 开发者
后端开发中的微服务架构实践与优化
【10月更文挑战第17天】 本文深入探讨了微服务架构在后端开发中的应用及其优化策略。通过分析微服务的核心理念、设计原则及实际案例,揭示了如何构建高效、可扩展的微服务系统。文章强调了微服务架构对于提升系统灵活性、降低耦合度的重要性,并提供了实用的优化建议,帮助开发者更好地应对复杂业务场景下的挑战。
22 7
|
2月前
|
安全 Java 网络安全
Android远程连接和登录FTPS服务代码(commons.net库)
Android远程连接和登录FTPS服务代码(commons.net库)
28 1
|
2月前
|
存储 缓存 NoSQL
分布式架构下 Session 共享的方案
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求、系统架构和性能要求等因素,选择合适的 Session 共享方案。同时,还需要不断地进行优化和调整,以确保系统的稳定性和可靠性。