前言

通過前面的幾篇文章，講解了一個短信服務的架構設計與實現(xiàn)。然而初始方案并非100%完美的，我們仍可以對該架構做一些優(yōu)化與調整。

同時我也希望通過這篇文章與大家分享一下，我的架構設計理念。

源碼地址：https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize （與之前的是另外的分支）

架構是設計的還是演變的？

架構

該詞出自于建筑學。軟件架構定義是指軟件系統(tǒng)的基礎結構，是系統(tǒng)中的實體及實體（服務）之間的關系所進行的抽象描述。而架構設計的目的是為了解決軟件系統(tǒng)復雜度帶來的問題。

復雜度

系統(tǒng)復雜度主要有下面幾點：

• 高可用

• 高性能

• 可擴展

• 安全性

• 維護成本

• 用戶規(guī)模

業(yè)務規(guī)模

系統(tǒng)的復雜度導致的直接原因是業(yè)務規(guī)模。為了用戶流暢放心的使用產品，不得不提高系統(tǒng)性能與安全。當系統(tǒng)成為人們生活不可缺一部分時，避免機房停電、挖掘機挖斷電纜導致的系統(tǒng)不可用，不得不去思考同城跨機房同步、異地多活的高可用方案。

答案并非二選一

我認為架構，需要在已知可見的業(yè)務復雜度與用戶規(guī)模的基礎上進行架構設計；伴隨著技術積累與成長而對系統(tǒng)進行架構優(yōu)化；用戶的日益增長，業(yè)務的不斷擴充，迫使了系統(tǒng)的復雜度增加，為了解決系統(tǒng)帶來新的復雜度而進行架構演變。

因此，架構方案是在已有的業(yè)務復雜度、用戶規(guī)模、技術積累度、人力時間成本等幾個方面的取舍決策后的結果體現(xiàn)。

原架構

缺點分析

• 一般情況下，調度任務輪詢數(shù)據(jù)庫，90%的動作是無用功，頻繁的數(shù)據(jù)庫訪問會對數(shù)據(jù)庫增加不少壓力。

• 為了讓調度任務服務進行輪循數(shù)據(jù)，需要在API優(yōu)先進行數(shù)據(jù)持久化，這無疑是降低了API的性能。

• MongoDB的Update操作相比于Insert操作時低效的，對于日志類數(shù)據(jù)應增量添加。

因此從上述可見，調度任務服務這塊是優(yōu)化關鍵點所在。

新架構圖

• 使用了RabbitMQ的隊列定時任務代替調度任務來實現(xiàn)定時發(fā)送。

• 拋棄了調度任務，減少了調用鏈，同時也減少了應用服務數(shù)據(jù)量。

• 對SMS集合在MongoDB里進行按年月的時間劃分，對于日志類數(shù)據(jù)可以在有效的時間范圍外進行方便的歸檔、刪除。同時也避免了同集合的數(shù)據(jù)量過大導致的查詢效率緩慢。

隊列定時任務

RabbitMQ自身并沒有定時任務，然而可以通過消息的Time-To-Live（過期時間）與Dead Letter Exchange（死信交換機）的結合模擬定時發(fā)布的功能。具體原理如下：

• 生產者發(fā)布消息，并發(fā)布到已申明消息過期時間（TTL）的緩存隊列（非真正業(yè)務消費隊列）

• 消息在緩存隊列等待消息過期，然后由Dead Letter Exchange將消息重新分配到實際消費隊列

• 消費者再從實際消費隊列消費并完成業(yè)務

?

?

Dead Letter Exchange

Dead Letter Exchange與平常的Exchange無異，主要用于消息死亡后通過Dead Letter Exchange與x-dead-letter-routing-key重新分配到新的隊列進行消費處理。

消息死亡的方式有三種：

• 消息進入了一條已經(jīng)達到最大長度的隊列

• 消息因為設置了Time-To-Live的導致過期

• 消息因basic.reject或者basic.nack動作而拒絕

Time-To-Live

兩種消息過期的方式：

隊列申明x-message-ttl參數(shù)

var args = new Dictionary<string, object>(); args.Add("x-message-ttl", 60000); model.QueueDeclare("myqueue", false, false, false, args);

每條消息發(fā)布聲明Expiration參數(shù)

RabbitMQ.Client隊列定時任務Demo

Sikiro.SMS實現(xiàn)優(yōu)化

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

API消息發(fā)布

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

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

• DeadLetterExchangeAndMessageTtlScheduler

• DelayedExchangeScheduler

• ExternalScheduler

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

ExternalScheduler是通過使用MQ的插件。

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

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

下面代碼是Sikiro.SMS.Api的優(yōu)化改造：

重發(fā)機制

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

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

SMS日志集合維度

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

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

結束

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

相關文章：

• .net core實踐系列之短信服務-為什么選擇.net core（開篇）

• .net core實踐系列之短信服務-架構設計

• .net core實踐系列之短信服務-Sikiro.SMS.Api服務的實現(xiàn)

• .net core實踐系列之短信服務-Sikiro.SMS.Job服務的實現(xiàn)

• .net core實踐系列之短信服務-Api的SDK的實現(xiàn)與測試
  

原文地址:?https://www.cnblogs.com/skychen1218/p/9565198.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的.net core实践系列之短信服务-架构优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。