.net core實踐系列之短信服務-架構優化

前言

通過前面的幾篇文章，講解了一個短信服務的架構設計與實現。然而初始方案並非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 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);
        }
    }

Sikiro.SMS實現優化

上面介紹了隊列定時任務基本原理，然而我們需要自己的項目進行修改優化。

API消息發布

EasyNetQ是一款非常良好使用性的RabbitMQ.Client封裝。對隊列定時任務他也已經提供了相應的方法FuturePublish給我們使用。

然而他的FuturePublish由有三種調度方式：

• DeadLetterExchangeAndMessageTtlScheduler
• DelayedExchangeScheduler
• ExternalScheduler

DelayedExchangeScheduler是需要EasyNetQ項目提供的調度程序，本質上也是輪詢

ExternalScheduler是通過使用MQ的插件。

DeadLetterExchangeAndMessageTtlScheduler才是我們之前通過DEMO實現的方式，在EasyNetQ組件上通過下面代碼進行啟用。

services.RegisterEasyNetQ(_infrastructureConfig.Infrastructure.RabbitMQ, a =>
            {
                a.EnableDeadLetterExchangeAndMessageTtlScheduler();
            });

下面代碼是Sikiro.SMS.Api的優化改造：

/// <summary>
        /// 添加短信記錄
        /// </summary>
        /// <param name="model"></param>
        /// <returns></returns>
        [HttpPost]
        public ActionResult Post([FromBody] List<PostModel> model)
        {
            _smsService.Page(model.MapTo<List<PostModel>, List<AddSmsModel>>());

            ImmediatelyPublish();

            TimingPublish();

            return Ok();
        }

        /// <summary>
        /// 及時發送
        /// </summary>
        private void ImmediatelyPublish()
        {
            _smsService.SmsList.Where(a => a.TimeSendDateTime == null).ToList().MapTo<List<SmsModel>, List<SmsQueueModel>>()
                .ForEach(
                    item =>
                    {
                        _bus.Publish(item, SmsQueueModelKey.Topic);
                    });
        }

        /// <summary>
        /// 定時發送
        /// </summary>
        private void TimingPublish()
        {
            _smsService.SmsList.Where(a => a.TimeSendDateTime != null).ToList()
                .ForEach(
                    item =>
                    {
                        _bus.FuturePublish(item.TimeSendDateTime.Value.ToUniversalTime(), item.MapTo<SmsModel, SmsQueueModel>(),
                            SmsQueueModelKey.Topic);
                    });
        }

重發機制

重發一般是請求服務超時的情況下使用。而導致這種原因的主要幾點是網絡波動、服務壓力過大。因為前面任意一種原因都無法在短時間恢復，因此對於簡單的重試 類似while（i<3）ReSend() 是沒有什么意義的。

因此我們需要借助隊列定時任務+發送次數*延遲時間來完成有效的非頻繁的重發。

 public void Start()
        {
            Console.WriteLine("I started");

            _bus.Subscribe<SmsQueueModel>("", msg =>
            {
                try
                {
                    _smsService.Send(msg.MapTo<SmsQueueModel, SmsModel>());
                }
                catch (WebException e)
                {
                    e.WriteToFile();

                    ReSend();
                }
                catch (Exception e)
                {
                    e.WriteToFile();
                }
            }, a =>
            {
                a.WithTopic(SmsQueueModelKey.Topic);
            });
        }

        private void ReSend()
        {
            var model = _smsService.Sms.MapTo<SmsModel, SmsQueueModel>();
            model.SendCount++;

            _bus.FuturePublish(TimeSpan.FromSeconds(30 * model.SendCount), model, SmsQueueModelKey.Topic);
        }

SMS日志集合維度

SMS日志作為非必要業務的運維型監控數據，在需要的時候隨時可以對此進行刪除或者歸檔處理。因此以時間（年月）作為集合維度，可以很好的對日志數據進行管理。

mongoProxy.Add(MongoKey.SmsDataBase, MongoKey.SmsCollection + "_" + DateTime.Now.ToString("yyyyMM"), model);

結束

經過本系列6篇的文章，介紹了以短信服務為業務場景，基於.net core平台的一個簡單架構設計、架構優化與服務實現的實踐例子。希望我的分享能幫助有需要的朋友。如果有任何好的建議請到下方給我留言。