.net core实践系列之短信服务-架构优化(一)

简介: .net core实践系列之短信服务-架构优化(一)

前言


通过前面的几篇文章,讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的,我们仍可以对该架构做一些优化与调整。


同时我也希望通过这篇文章与大家分享一下,我的架构设计理念。


源码地址:https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize (与之前的是另外的分支)


架构是设计的还是演变的?


架构


该词出自于建筑学。软件架构定义是指软件系统的基础结构,是系统中的实体及实体(服务)之间的关系所进行的抽象描述。而架构设计的目的是为了解决软件系统复杂度带来的问题。


复杂度


系统复杂度主要有下面几点:


  • 高可用
  • 高性能
  • 可扩展
  • 安全性
  • 维护成本
  • 用户规模


业务规模


系统的复杂度导致的直接原因是业务规模。为了用户流畅放心的使用产品,不得不提高系统性能与安全。当系统成为人们生活不可缺一部分时,避免机房停电、挖掘机挖断电缆导致的系统不可用,不得不去思考同城跨机房同步、异地多活的高可用方案。


答案并非二选一


我认为架构,需要在已知可见的业务复杂度与用户规模的基础上进行架构设计;伴随着技术积累与成长而对系统进行架构优化;用户的日益增长,业务的不断扩充,迫使了系统的复杂度增加,为了解决系统带来新的复杂度而进行架构演变。


因此,架构方案是在已有的业务复杂度、用户规模、技术积累度、人力时间成本等几个方面的取舍决策后的结果体现。


原架构


image.png


缺点分析


  • 一般情况下,调度任务轮询数据库,90%的动作是无用功,频繁的数据库访问会对数据库增加不少压力。
  • 为了让调度任务服务进行轮循数据,需要在API优先进行数据持久化,这无疑是降低了API的性能。
  • MongoDB的Update操作相比于Insert操作时低效的,对于日志类数据应增量添加。


因此从上述可见,调度任务服务这块是优化关键点所在。


新架构图


image.png


  • 使用了RabbitMQ的队列定时任务代替调度任务来实现定时发送。
  • 抛弃了调度任务,减少了调用链,同时也减少了应用服务数据量。
  • 对SMS集合在MongoDB里进行按年月的时间划分,对于日志类数据可以在有效的时间范围外进行方便的归档、删除。同时也避免了同集合的数据量过大导致的查询效率缓慢。


队列定时任务


RabbitMQ自身并没有定时任务,然而可以通过消息的Time-To-Live(过期时间)与Dead Letter Exchange(死信交换机)的结合模拟定时发布的功能。具体原理如下:


  • 生产者发布消息,并发布到已申明消息过期时间(TTL)的缓存队列(非真正业务消费队列)
  • 消息在缓存队列等待消息过期,然后由Dead Letter Exchange将消息重新分配到实际消费队列
  • 消费者再从实际消费队列消费并完成业务

 

image.png


Dead Letter Exchange


Dead Letter Exchange与平常的Exchange无异,主要用于消息死亡后通过Dead Letter Exchange与x-dead-letter-routing-key重新分配到新的队列进行消费处理。


消息死亡的方式有三种:


  • 消息进入了一条已经达到最大长度的队列
  • 消息因为设置了Time-To-Live的导致过期
  • 消息因basic.reject或者basic.nack动作而拒绝


Time-To-Live


两种消息过期的方式:


队列申明x-message-ttl参数
var args = new Dictionary<string, object>();
args.Add("x-message-ttl", 60000);
model.QueueDeclare("myqueue", false, false, false, args);
每条消息发布声明Expiration参数
byte[] messageBodyBytes = System.Text.Encoding.UTF8.GetBytes("Hello, world!");
IBasicProperties props = model.CreateBasicProperties();
props.ContentType = "text/plain";
props.DeliveryMode = 2;
props.Expiration = "36000000"
model.BasicPublish(exchangeName,
                   routingKey, props,
                   messageBodyBytes);


RabbitMQ.Client队列定时任务Demo


class Program
    {
        static void Main(string[] args)
        {
            var factory = new ConnectionFactory
            {
                HostName = "10.1.20.140",
                UserName = "admin",
                Password = "admin@ucsmy"
            };
            using (var connection = factory.CreateConnection())
            using (var channel = connection.CreateModel())
            {
                var queueName = "Queue.SMS.Test";
                var exchangeName = "Exchange.SMS.Test";
                var key = "Route.SMS.Test";
                DeclareDelayQueue(channel, exchangeName, queueName, key);
                DeclareReallyConsumeQueue(channel, exchangeName, queueName, key);
                var body = Encoding.UTF8.GetBytes("info: test dely publish!");
                channel.BasicPublish(exchangeName + ".Delay", key, null, body);
            }
        }
        private static void DeclareDelayQueue(IModel channel, string exchangeName, string queueName, string key)
        {
            var retryDic = new Dictionary<string, object>
            {
                {"x-dead-letter-exchange", exchangeName+".dl"},
                {"x-dead-letter-routing-key", key},
                {"x-message-ttl", 30000}
            };
            var ex = exchangeName + ".Delay";
            var qu = queueName + ".Delay";
            channel.ExchangeDeclare(ex, "topic");
            channel.QueueDeclare(qu, false, false, false, retryDic);
            channel.QueueBind(qu, ex, key);
        }
        private static void DeclareReallyConsumeQueue(IModel channel, string exchangeName, string queueName, string key)
        {
            var ex = exchangeName + ".dl";
            channel.ExchangeDeclare(ex, "topic");
            channel.QueueDeclare(queueName, false, false, false);
            channel.QueueBind(queueName, ex, key);
        }
    }


目录
相关文章
|
1月前
|
存储 开发框架 前端开发
前端框架EXT.NET Dotnet 3.5开发的实验室信息管理系统(LIMS)成品源码 B/S架构
发展历史:实验室信息管理系统(LIMS),就是指通过计算机网络技术对实验的各种信息进行管理的计算机软、硬件系统。也就是将计算机网络技术与现代的管理思想有机结合,利用数据处理技术、海量数据存储技术、宽带传输网络技术、自动化仪器分析技术,来对实验室的信息管理和质量控制等进行全方位管理的计算机软、硬件系统,以满足实验室管理上的各种目标(计划、控制、执行)。
31 1
|
3天前
|
存储 Cloud Native 物联网
数据库技术前沿探索:架构、优化与行业实践
一、引言 在信息化和数字化的浪潮中,数据库技术作为企业核心竞争力的关键要素,其重要性不言而喻
|
6天前
|
存储 缓存 前端开发
单页应用(SPA)的架构与优化:深度探索与实践
【6月更文挑战第11天】本文探讨了单页应用(SPA)的架构与优化,包括前后端分离、路由管理和状态管理基础,以及加载性能、路由和状态管理的优化策略。通过合理设计与优化,SPA能提供流畅体验,同时应对加载性能、路由导航和状态管理的挑战。文章旨在帮助读者理解并提升SPA应用的性能和用户体验。
|
15天前
|
数据库 微服务 NoSQL
探索微服务架构下的数据库选型与优化策略
在现代软件开发中,微服务架构已成为一种常见的设计范式。而数据库在微服务架构中的选型与优化策略对整个系统的性能和稳定性至关重要。本文将探讨在微服务环境下,如何选择适合的数据库类型以及优化数据库性能的策略。
|
17天前
|
消息中间件 数据库 网络架构
构建高效后端:微服务架构的优化策略
【5月更文挑战第31天】在这篇文章中,我们将深入探讨如何通过采用微服务架构来提升后端开发的效率和性能。我们将分析微服务架构的关键优势,并讨论如何克服实施过程中的挑战。通过具体的案例研究,我们将展示如何优化微服务架构以实现最佳的性能和可维护性。无论你是后端开发的新手还是经验丰富的专业人士,这篇文章都将为你提供有价值的见解和实用的技巧。
|
17天前
|
Kubernetes 负载均衡 应用服务中间件
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
|
18天前
|
运维 Cloud Native 安全
云原生架构的未来演进:迈向自我优化的基础设施
【5月更文挑战第30天】 随着企业数字化转型的深入,云原生技术正成为推动现代应用开发和运维模式变革的关键力量。本文探讨了云原生架构如何通过不断的技术迭代,实现自我优化的基础设施,以及这一进化对企业IT策略的影响。文章首先回顾了云原生的概念与核心组件,随后分析了当前云平台在自动化、微服务管理、容器化等方面的最新趋势,并预测了未来可能的发展路径,包括AI辅助的运维、无服务器架构的进一步普及以及安全自动化等。最后,文章提出了企业在采纳云原生技术时的策略建议,以促进业务敏捷性和技术创新。
|
28天前
|
监控 负载均衡 Java
【阿里云云原生专栏】微服务架构在阿里云云原生平台上的应用实例与优化策略
【5月更文挑战第20天】本文介绍了在阿里云云原生平台实现微服务架构的步骤,包括基于Spring Cloud的Docker化部署、使用ACK部署微服务,以及优化策略:服务发现与负载均衡(借助Istio)和监控日志管理。通过这种方式,企业能提升应用的可扩展性、可维护性和敏捷性。
211 5
|
1月前
|
SQL canal 运维
MySQL高可用架构探秘:主从复制剖析、切换策略、延迟优化与架构选型
MySQL高可用架构探秘:主从复制剖析、切换策略、延迟优化与架构选型
|
1月前
|
开发框架 JSON .NET
.Net4.0 Web.config 配置实践
.Net4.0 Web.config 配置实践

热门文章

最新文章