前言

通過前面的幾篇文章，講解了一個簡訊服務的架構設計與實現。然而初始方案並非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 = "[email protected]"
            };

            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 (TimeoutException 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平臺的一個簡單架構設計、架構優化與服務實現的實踐例子。希望我的分享能幫助有需要的朋友。如果有任何好的建議請到下方給我留言。