菜单设计制作网站,哈尔滨的网络优化能做么,彩票网站建设基本流程,安徽龙山建设有限公司网站前言通过前面的几篇文章#xff0c;讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的#xff0c;我们仍可以对该架构做一些优化与调整。同时我也希望通过这篇文章与大家分享一下#xff0c;我的架构设计理念。源码地址#xff1a;https://github.com/SkyCh… 前言通过前面的几篇文章讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的我们仍可以对该架构做一些优化与调整。同时我也希望通过这篇文章与大家分享一下我的架构设计理念。源码地址https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize 与之前的是另外的分支架构是设计的还是演变的架构该词出自于建筑学。软件架构定义是指软件系统的基础结构是系统中的实体及实体服务之间的关系所进行的抽象描述。而架构设计的目的是为了解决软件系统复杂度带来的问题。复杂度系统复杂度主要有下面几点高可用高性能可扩展安全性维护成本用户规模业务规模系统的复杂度导致的直接原因是业务规模。为了用户流畅放心的使用产品不得不提高系统性能与安全。当系统成为人们生活不可缺一部分时避免机房停电、挖掘机挖断电缆导致的系统不可用不得不去思考同城跨机房同步、异地多活的高可用方案。答案并非二选一我认为架构需要在已知可见的业务复杂度与用户规模的基础上进行架构设计伴随着技术积累与成长而对系统进行架构优化用户的日益增长业务的不断扩充迫使了系统的复杂度增加为了解决系统带来新的复杂度而进行架构演变。因此架构方案是在已有的业务复杂度、用户规模、技术积累度、人力时间成本等几个方面的取舍决策后的结果体现。原架构缺点分析一般情况下调度任务轮询数据库90%的动作是无用功频繁的数据库访问会对数据库增加不少压力。为了让调度任务服务进行轮循数据需要在API优先进行数据持久化这无疑是降低了API的性能。MongoDB的Update操作相比于Insert操作时低效的对于日志类数据应增量添加。因此从上述可见调度任务服务这块是优化关键点所在。新架构图使用了RabbitMQ的队列定时任务代替调度任务来实现定时发送。抛弃了调度任务减少了调用链同时也减少了应用服务数据量。对SMS集合在MongoDB里进行按年月的时间划分对于日志类数据可以在有效的时间范围外进行方便的归档、删除。同时也避免了同集合的数据量过大导致的查询效率缓慢。队列定时任务RabbitMQ自身并没有定时任务然而可以通过消息的Time-To-Live过期时间与Dead Letter Exchange死信交换机的结合模拟定时发布的功能。具体原理如下生产者发布消息并发布到已申明消息过期时间TTL的缓存队列非真正业务消费队列消息在缓存队列等待消息过期然后由Dead Letter Exchange将消息重新分配到实际消费队列消费者再从实际消费队列消费并完成业务  Dead Letter ExchangeDead 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 Dictionarystring, object(); args.Add(x-message-ttl, 60000); model.QueueDeclare(myqueue, false, false, false, args);每条消息发布声明Expiration参数RabbitMQ.Client队列定时任务DemoSikiro.SMS实现优化上面介绍了队列定时任务基本原理然而我们需要自己的项目进行修改优化。API消息发布EasyNetQ是一款非常良好使用性的RabbitMQ.Client封装。对队列定时任务他也已经提供了相应的方法FuturePublish给我们使用。然而他的FuturePublish由有三种调度方式DeadLetterExchangeAndMessageTtlSchedulerDelayedExchangeSchedulerExternalSchedulerDelayedExchangeScheduler是需要EasyNetQ项目提供的调度程序本质上也是轮询ExternalScheduler是通过使用MQ的插件。DeadLetterExchangeAndMessageTtlScheduler才是我们之前通过DEMO实现的方式在EasyNetQ组件上通过下面代码进行启用。services.RegisterEasyNetQ(_infrastructureConfig.Infrastructure.RabbitMQ, a {a.EnableDeadLetterExchangeAndMessageTtlScheduler();});下面代码是Sikiro.SMS.Api的优化改造重发机制重发一般是请求服务超时的情况下使用。而导致这种原因的主要几点是网络波动、服务压力过大。因为前面任意一种原因都无法在短时间恢复因此对于简单的重试 类似whilei3ReSend() 是没有什么意义的。因此我们需要借助队列定时任务发送次数*延迟时间来完成有效的非频繁的重发。SMS日志集合维度SMS日志作为非必要业务的运维型监控数据在需要的时候随时可以对此进行删除或者归档处理。因此以时间年月作为集合维度可以很好的对日志数据进行管理。mongoProxy.Add(MongoKey.SmsDataBase, MongoKey.SmsCollection _ DateTime.Now.ToString(yyyyMM), model);结束经过本系列6篇的文章介绍了以短信服务为业务场景基于.net core平台的一个简单架构设计、架构优化与服务实现的实践例子。希望我的分享能帮助有需要的朋友。如果有任何好的建议请到下方给我留言。相关文章.net core实践系列之短信服务-为什么选择.net core开篇.net core实践系列之短信服务-架构设计.net core实践系列之短信服务-Sikiro.SMS.Api服务的实现.net core实践系列之短信服务-Sikiro.SMS.Job服务的实现.net core实践系列之短信服务-Api的SDK的实现与测试原文地址: https://www.cnblogs.com/skychen1218/p/9565198.html.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com