.net core實踐系列之簡訊服務-架構優化

摘要： 前言 通過前面的幾篇文章，講解了一個簡訊服務的架構設計與實現。然而初始方案並非100%完美的，我們仍可以對該架構做一些優化與調整。 同時我也希望通過這篇文章與大家分享一下，我的架構設計理念。 原始碼地址：https://github.com/SkyChenSky/Sikiro.SM...

前言

通過前面的幾篇文章，講解了一個簡訊服務的架構設計與實現。然而初始方案並非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 (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平臺的一個簡單架構設計、架構優化與服務實現的實踐例子。希望我的分享能幫助有需要的朋友。如果有任何好的建議請到下方給我留言。