.net core实践系列之短信服务-架构设计

前言

上篇《.net core实践系列之短信服务-为什么选择.net core(开篇)》简单的介绍了(水了一篇).net core。这次针对短信服务的架构设计和技术栈的简析。

源码地址:https://github.com/SkyChenSky/Sikiro.SMS

为什么需要架构设计

有人会问短信服务也要架构设计?不就写个service封装个send方法就得了吗?干嘛还要大动干戈。

如果在单块应用的情况下,以上面的做法是无可厚非的。

然而架构设计解决的是应用复杂度,架构设计的大还是小取决于业务规模,技术的使用是要落实到应用场景。

场景假设

以我们公司作为例子:

  • 已拥有多套系统,运营后台、资金平台、账单平台、APP API等;
  • 需接入多个短信运营商,避免某个出异常后随时切换;
  • 及时发送、定时发送;

从上面场景分析出,要由多系统、多平台接入需要单独抽离出来进行服务化,而且随着接入的系统越多,性能将成为瓶颈,因此需要良好的横向拓展能力。定时发送需要调度任务系统进行解决。

因此下面为我设计的架构图

架构图

架构简析

SmsApi服务

以HTTP协议RESTful风格JSON格式提供给其他系统(服务)接入,以swagger作为服务描述提供对外查看。

接口主要功能有:

  • 发送短信
  • 查询短信列表

发送短信支持批量,接口接受到请求后将数据先持久化到MongoDB。

如果及时发送则立刻发送RabbitMQ,再由Sikiro.SMS.Bus订阅队列进行统一发送;

如果定时发送则等待Sikiro.SMS.Job进行轮循MongoDB,轮询到时的消息则发送到RabbitMQ,再由Sikiro.SMS.Bus订阅队列进行统一发送。

Sikiro.SMS.Job调度任务服务

此服务以Quartz.NET框架为基础,通过设计可以随意增加Trigger或者服务,使其多线程或多个进程同时运行,避免数据量大了后成为发送瓶颈。

此服务不直接做短信发送,只是触发器的存在,通过RabbitMQ进行解耦,避免执行过程过长如果停止服务时则中断。

Sikiro.SMS.Bus队列消费服务

无论定时、及时短信都由该服务进行发送,如果接入了新的短信运营商,只需要停止该服务进行更新即可。停止了服务消息不会丢失,将暂存在RabbitMQ,因需对RabbitMQ的消息做持久化。

可以在不同的服务器上部署服务,因为订阅同一个队列,良好的横向扩展保证了高可用、高性能

可伸缩性

可伸缩性指在不改变系统软硬件设计,仅仅通过新增服务器的情况下,就能提升系统的处理能力。

HTTP API的无状态,在调度任务里的MongoDB原子操作FindOneAndUpdate的使用,多消费者的订阅都是为了可伸缩性。同时通过部署多台服务器也可以提高高性能与高可用。

MongoDB的选择

我选择MongoDB主要原因是聚合一致性、无模式。

虽说不需要ACID但不代表没有一致性,而MongoDB体现的聚合一致性,以聚合做操作。

聚合

一组具有内聚关系的相关对象的称为集合

关系型数据库

则以下面两表通过SmsId关联读取,写入则两表作为一个事务

MongoDB

则以下面聚合方式表示,以聚合取,以聚合写

无模式

MongoDB一大特点则是无模式,意思是无需预先定义集合结构与字段类型,这体现了良好的拓展性。这是优点也是缺点,假如别的服务对该集合进行操作,在他不知情的情况下随意写入不同类型的值,则会影响已运行的服务。

因此需要将此作为应用服务数据库,也就是服务化,把对集合的操作(读与写)以服务形式提供接口给其他服务使用。

服务粒度

有些人会问为什么不把三个运营商Service也拆出来作为独立的API服务?

回顾下现在执行流程,一次短信发送最长的调用链为:请求SmsApi,Sikiro.SMS.Job轮询数据,Sikiro.SMS.Bus消费队列消息并请求短信运营商服务。

架构上的扩展性的本质的确是拆,但是拆得过细将出现三个问题:

  • 调用链过长影响性能
  • 调用链过长难以定位问题
  • 增加开发、维护成本

假如哪天短信没发送成功,首先看看API日志看看是不是调用成功了,如果没问题那可能JOB出问题了。如果JOB正常跑,难道是队列问题?假如再加多一层,那就定位更加的复杂了。

就如开始所说的如果添加一个短信运营商只需要添加一个Service利用工厂模式,就可以良好的拓展了。而添加一个服务的开发、部署、维护成本无疑是比在组件内扩展的成本高。

结尾

该篇描述我的架构设计,下篇会正式对各个服务的实现进行讲解。如果您有更好的建议可以在下方评论反馈给我。

我的博客即将搬运同步至腾讯云+社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=jjdhw6o619ra

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ASP.NETCore

在.NET Core程序中设置全局异常处理

但是在.NET Core中并没有AppDomain的相关实现,至少在.NET Core最新的发布版本里没有。

16530
来自专栏ASP.NETCore

.NET Core中使用Razor模板引擎

 在MVC以外的场景中,我们往往需要完成一些模板引擎生成代码或页面的工作;在以前我们一般常用的有Razor、NVeocity、VTemplate。虽然所有的模...

37430
来自专栏ASP.NETCore

.NET Core中ADO.NET SqlClient的使用与常见问题

  在很多要求性能的项目中,我们都要使用传统的ADO.NET的方式来完成我们日常的工作;目前有一些网友问有关于.NET Core操作SQL Server的问题在...

39810
来自专栏ASP.NETCore

.NET Core第三方开源Web框架YOYOFx

YOYOFx是一个轻量级用于构建基于 HTTP 的 Web 服务,基于 .NET 和 Mono 平台。

88240
来自专栏ASP.NETCore

.NET Core爬坑记 1.0 项目文件

  之所以要写这个系列是因为在移植项目到ASP.NET Core平台的过程中,遇到了一些“新变化”,这些变化有编译方面的、有API方面的,今天要讲的是编译方面的...

12730
来自专栏ASP.NETCore

ASP.NET Core 整合Autofac和Castle实现自动AOP拦截

除了ASP.NETCore自带的IOC容器外,我们还可以使用其他成熟的DI框架,如Autofac,StructureMap等(笔者只用过Unity,Ninjec...

18840
来自专栏ASP.NETCore

【干货】”首个“ .NET Core 验证码组件

众所周知,Dotnet Core目前没有图形API,以前的System.Drawing程序集并没有包含在Dotnet Core 1.0环境中。不过在dotne...

21840
来自专栏ASP.NETCore

.NET Core扩展IServiceCollection自动注册服务

在ASP.NET Core中使用依赖注入中使用很简单,只需在Startup类的ConfigureServices()方法中,通过IServiceCollecti...

43520
来自专栏ASP.NETCore

Debugging into .NET Core源代码的两种方式

   .NET开源时间还不长,因为一直在做YOYOFx的关系,所似我常常有更深入的了解.NET Core和ASP.NET Core内容的需求,并且.NET Co...

43230
来自专栏ASP.NETCore

解决VS Code调试.NET Core应用遇到的坑

  博客园里有好多介绍怎么使用VS Code以及调试.NET Core的文章,但是都是基于直接构建Asp.Net Core Mvc单项目的,有什么区别呢!

18240

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励