前言
上篇《.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