自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

聊聊消息推送架構(gòu)設(shè)計

開發(fā)
企業(yè)級統(tǒng)一基礎(chǔ)推送服務(wù),是一個通用特性,適用于所有現(xiàn)代分布式應(yīng)用,無論采用何種編程語言和技術(shù)。

構(gòu)建企業(yè)級統(tǒng)一基礎(chǔ)推送服務(wù),支持通過多渠道推送,能夠統(tǒng)一集成的電子郵件、短信、聊天、釘釘、企業(yè)微信和其他公共社交應(yīng)用:

  • 聊天 - 微信Wechat/QQ
  • 站內(nèi)推送通知(移動設(shè)備和Web瀏覽器)
  • 站外推送通知(移動設(shè)備,APP沒有開啟)
  • 短信(如登錄密碼、營銷活動)
  • 電子郵件
  • 釘釘
  • 企業(yè)微信

企業(yè)級統(tǒng)一基礎(chǔ)推送服務(wù),是一個通用特性,適用于所有現(xiàn)代分布式應(yīng)用,無論采用何種編程語言和技術(shù)。

推送能力的演進

第一階段(模塊化):各自為政、各自封裝

企業(yè)內(nèi)部,早期業(yè)務(wù)量比較少,各系統(tǒng)基本都是有自己的推送模塊,類型也是五花八門:

  • 聊天模塊
  • 短信模塊
  • 電子郵件模塊
  • websocket 模塊

各自封裝模塊比較簡單,但是實現(xiàn)分散、各系統(tǒng)模塊的質(zhì)量也很難統(tǒng)一保證。

第二階段(框架化):集成框架

  • 為了減少重復(fù)性設(shè)計、開發(fā)成本, 設(shè)計了統(tǒng)一的推送框架
  • 同一套微服務(wù)框架,共用一個統(tǒng)一的推送框架

為了解決上述分散實現(xiàn)的問題,企業(yè)內(nèi)部統(tǒng)一實現(xiàn)了一個綜合各類推送功能的基礎(chǔ)庫,供業(yè)務(wù)方統(tǒng)一調(diào)用。

  • 聊天基礎(chǔ)starter
  • 短信基礎(chǔ)starter
  • 電子郵件基礎(chǔ)starter
  • websocket 基礎(chǔ)starter

于是,我們把 springboot-starter的邏輯封裝到了服務(wù)治理框架內(nèi),微服務(wù)服務(wù)啟動時,每一個服務(wù)對各種的starter進行運維管理、配置管理。

第三階段(服務(wù)化):推送服務(wù)

集成到框架,每一套服務(wù),都需要重復(fù)性的解決三高問題:

  • 推送服務(wù),數(shù)據(jù)量大,需要解決跨庫查詢問題
  • 推送服務(wù),性能要求高,需要解決高并發(fā)問題

大數(shù)據(jù)量、并發(fā)量高,意味著:

  • 硬件資源投入大
  • 運維成本高

這樣的基礎(chǔ)服務(wù),需要進行沉淀,剝離,集中成統(tǒng)一的、基礎(chǔ)服務(wù),由專門團隊負責(zé)維護、迭代、運維。降低重復(fù)投入、重復(fù)建設(shè)成本, 真正的降本增效。

于是, 推送框架 演進為 推送服務(wù)。

推送服務(wù)在業(yè)務(wù)系統(tǒng)中的位置

一個業(yè)務(wù)應(yīng)用, 基本上有很多原子服務(wù)編排、整合而來,最終構(gòu)建出一個完整的架構(gòu)圖。

  • 接入層,這是外部請求進入內(nèi)部系統(tǒng)的門戶,所有的請求都必須通過 API 網(wǎng)關(guān)。
  • 應(yīng)用層,也被稱為聚合層,它為相關(guān)業(yè)務(wù)提供聚合接口,并調(diào)用中臺服務(wù)進行組合。
  • 原子服務(wù),包括就是原子技術(shù)服務(wù),原子業(yè)務(wù)服務(wù),根據(jù)業(yè)務(wù)需求提供相關(guān)的接口。原子服務(wù)為整個架構(gòu)提供可復(fù)用的能力。

例如,在B站視頻網(wǎng)站平臺上,評論服務(wù)作為一項原子服務(wù),在B站的視頻、文章、社區(qū)都需要,那么為了提高復(fù)用性,評論服務(wù)就可以獨立為原子服務(wù),不能與特定需求緊密耦合。

在這種情況下,  評論服務(wù),需要供一種可以適應(yīng)不同場景的復(fù)用能力。

注意:請點擊圖像以查看清晰的架構(gòu)圖!

類似的,文件存儲、數(shù)據(jù)存儲、推送服務(wù)、身份驗證服務(wù)等功能,都會沉淀為原子服務(wù),業(yè)務(wù)開發(fā)人員,在原子服務(wù)基礎(chǔ)上,進行編排、配置、組合,可以快速構(gòu)建業(yè)務(wù)應(yīng)用。

推送服務(wù)功能要求

  • 發(fā)送通知
  • 對通知進行優(yōu)先級排序
  • 根據(jù)客戶的保存偏好發(fā)送通知
  • 支持單個/簡單的通知消息和批量通知消息
  • 各種通知的分析用例
  • 通知消息的報告

推送非功能性需求(NFR)

  • 高性能:qps > 1W
  • 高可用性(HA):99.99%
  • 低延遲:TP99 在10ms以下
  • 高擴展:可擴展/可插拔的設(shè)計,以便添加更多適配器和提供商,與所有通知模塊的API集成以及與客戶端和服務(wù)提供商/供應(yīng)商的外部集成
  • 跨平臺:支持Android/iOS移動設(shè)備和桌面/筆記本電腦的Web瀏覽器
  • 自伸縮:可在本地(VMware Tanzu)和 AWS、GCP 或 Azure 等公共云服務(wù)上擴展負載

推送系統(tǒng)設(shè)計架構(gòu)

注意:請點擊圖像以查看清晰的架構(gòu)圖!

這些解決方案設(shè)計的考慮因素和組件包括:

1. 通知客戶端

這些客戶端通過 API 調(diào)用請求單個和批量消息。它們將向簡單和批量通知服務(wù)發(fā)送通知消息。

  • 簡單通知客戶端:專門用于發(fā)送單個通知的客戶端,負責(zé)向用戶發(fā)送單一通知。這些客戶端通常用于向特定用戶發(fā)送重要通知,例如密碼找回或賬戶異常提醒。
  • 批量通知客戶端:專門用于發(fā)送批量通知的客戶端,負責(zé)向用戶批量推送通知。這些客戶端通常用于需要通知大量用戶的場景,例如企業(yè)內(nèi)部通知或營銷活動。

2. 通知服務(wù)

作為入口點的這些服務(wù),通過暴露 REST API 與客戶端互動。

它們負責(zé)構(gòu)建通知消息,通過調(diào)用"模板服務(wù)"。這些消息將使用"驗證服務(wù)"進行驗證。

  • 簡單通知服務(wù):該服務(wù)將提供 API,主要負責(zé)處理簡單通知請求,提供與后端服務(wù)集成的 API,以便將通知發(fā)送給用戶。這種服務(wù)通常用于處理較少的通知請求,例如針對特定用戶或事件的簡單通知。
  • 批量通知服務(wù):該服務(wù)將提供 API,主要負責(zé)處理批量通知請求,提供與后端服務(wù)集成的 API,以便批量發(fā)送通知。這種服務(wù)通常用于處理大量的通知請求,例如企業(yè)內(nèi)部的批量通知或營銷活動的批量推送。

此服務(wù)還將管理通知消息。它將發(fā)送的消息持久化到數(shù)據(jù)庫并維護活動日志。

可以使用這些服務(wù)的 API 重新發(fā)送同一條消息。

它將提供添加/更新/刪除和查看舊消息和新消息的 API。

它還將提供 Web 儀表板,該儀表板應(yīng)具有篩選選項,以根據(jù)不同的條件(如日期范圍、優(yōu)先級、模塊用戶、用戶組等)篩選消息。

3. 模板服務(wù)

此服務(wù)主要負責(zé)所有可用的一次性密碼(OTP)、短信、電子郵件、聊天以及其他推送通知消息的模板管理。

它還提供了 REST API,以便創(chuàng)建、更新、刪除和管理模板。

除此之外,它還將提供一個用戶界面(UI)的儀表板頁面,使用戶能從網(wǎng)絡(luò)控制臺檢查和管理各種消息模板。

4. 消息分發(fā)服務(wù)

(1) 定時分發(fā)服務(wù):

該服務(wù)將提供API來安排立即或指定時間的通知。可以是以下任何一種:

  • 分鐘
  • 每小時
  • 每天
  • 每周
  • 每月
  • 每年
  • 自定義頻率等。

還可能有其他自動觸發(fā)的服務(wù),基于預(yù)定時間進行消息觸發(fā)。

(2) 消息驗證服務(wù):

此服務(wù)全權(quán)負責(zé)根據(jù)業(yè)務(wù)規(guī)定和預(yù)期格式對通知信息進行核實。批量通知需由授權(quán)的系統(tǒng)管理員同意。

(3) 消息優(yōu)先級服務(wù):

該服務(wù)負責(zé)對通知進行優(yōu)先級排序,分為高、中、低三個等級。

  • 通知信息具有較高的優(yōu)先級和有時間限制的到期時間,它們將始終以較高優(yōu)先級發(fā)送。
  • "通用出口處理器"會接收消息并根據(jù)相同的優(yōu)先級從高、中和低三個不同的隊列中發(fā)送和處理。
  • 在非工作時間,可以以低優(yōu)先級發(fā)送批量通知。
  • 在交易過程中的應(yīng)用程序通知可以發(fā)送到中優(yōu)先級,如電子郵件等。企業(yè)可以根據(jù)通知的重要性確定優(yōu)先級。

5. 事件優(yōu)先級隊列(消息隊列)

此服務(wù)提供事件中心功能,負責(zé)接收通知服務(wù)的高、中、低三個優(yōu)先級的信息。

它會根據(jù)業(yè)務(wù)的優(yōu)先級來發(fā)送和接收通知。企業(yè)可以根據(jù)通知的重要性來設(shè)定優(yōu)先級。

服務(wù)內(nèi)部包含三個主題,用于根據(jù)業(yè)務(wù)優(yōu)先級接收和發(fā)送通知:

  • 低優(yōu)先級:主要用于在非工作時間發(fā)送批量通知。
  • 中優(yōu)先級:適用于在交易過程中發(fā)送的應(yīng)用程序通知,如電子郵件等。
  • 高優(yōu)先級:通知信息具有較高的優(yōu)先級和有時間限制的到期時間,它們將始終以較高優(yōu)先級發(fā)送。關(guān)注公工號:互聯(lián)網(wǎng)架構(gòu)師,回復(fù)關(guān)鍵詞:2T 獲取阿里內(nèi)部架構(gòu)手冊!

6. 通用出站處理程序

該服務(wù)通過輪詢事件優(yōu)先級隊列來接收事件中心中的通知信息,并根據(jù)其優(yōu)先級進行處理。

高優(yōu)先級的通知會優(yōu)先處理"高"隊列,依次類推。

最后,它通過事件中心將通知信息發(fā)送到特定的適配器。

此外,該服務(wù)還從用戶選擇服務(wù)中獲取目標用戶/應(yīng)用程序,以便進行通知的分發(fā)。

在處理過程中,通用出口處理器會根據(jù)事件的優(yōu)先級進行相應(yīng)的操作,確保重要事件得到優(yōu)先處理。

這樣,企業(yè)可以根據(jù)通知的優(yōu)先級來確定處理順序,從而提高通知的處理效率。

除此之外, 通用出站處理程序,還能進行消息的進一步按照通道類型進行分發(fā):

該服務(wù)將消息發(fā)送到各種支持的適配器。

這些適配器會根據(jù)不同的設(shè)備(如桌面/移動設(shè)備)和通知類型(如短信/OTP/電子郵件/聊天/推送通知)進行轉(zhuǎn)換。

7. 通知適配器

這些轉(zhuǎn)換器將從消息隊列(rocketmq)接收傳入信息并根據(jù)其所支持的格式傳遞給外部合作伙伴。

以下是一些轉(zhuǎn)換器,根據(jù)需求可以增加更多:

  • QQ 通知適配器服務(wù)
  • 微信Wechat 聊天通知適配器服務(wù)
  • 應(yīng)用內(nèi)通知適配器服務(wù)
  • 電子郵件適配器服務(wù)
  • 短信適配器服務(wù)
  • OTP 適配器服務(wù)

8. 通道供應(yīng)商

這些是外部的 SAAS(云上/本地)服務(wù)提供商,利用它們的基礎(chǔ)設(shè)施和技術(shù)實現(xiàn)實際的通知傳遞。

它們可能是像 AWS SNS、MailChimp 等的付費推送通道服務(wù)。

  • QQ 供應(yīng)商集成服務(wù)
  • 微信Wechat 供應(yīng)商集成服務(wù)
  • 應(yīng)用推送通知供應(yīng)商集成服務(wù)
  • 電子郵件供應(yīng)商集成服務(wù)
  • 短信供應(yīng)商集成服務(wù)

9. 用戶選擇服務(wù)

該服務(wù)提供選擇目標用戶和各種應(yīng)用程序模塊的功能。

這可能包括將批量消息發(fā)送到特定的用戶組或不同的應(yīng)用程序模塊。

可能是 AD/IAM/eDirectory/用戶數(shù)據(jù)庫/用戶組,具體取決于客戶的偏好。

在服務(wù)內(nèi)部,它將使用"用戶配置文件服務(wù)"API 來消費和檢查客戶的通知偏好。

10. 用戶配置文件服務(wù)

此服務(wù)提供各種功能,包括管理用戶配置文件及其偏好設(shè)置。

還管理內(nèi)部用戶標識,和外部通道標識之間的關(guān)聯(lián)關(guān)系:

  • 釘釘用戶標識 和 用戶標識 關(guān)聯(lián)關(guān)系
  • 企業(yè)微信 用戶標識 和 用戶標識 關(guān)聯(lián)關(guān)系
  • 用戶和郵箱的關(guān)聯(lián)關(guān)系
  • 等等

它還將提供取消訂閱通知以及通知接收頻率等功能。

"通知服務(wù)"將依賴于此服務(wù),以便根據(jù)用戶的通知偏好來發(fā)送通知。

此外,該服務(wù)還可以用于統(tǒng)計和分析用戶對通知的偏好,以幫助企業(yè)優(yōu)化通知策略。

11. 分析服務(wù)

該處理器將負責(zé)執(zhí)行所有的分析工作,識別通知使用情況、趨勢并生成報告。

它將從分析數(shù)據(jù)庫(Cassandra)和通知數(shù)據(jù)庫中提取所有最終的通知信息,用于分析和報告目的。

以下是一些用例:

  • 每天/每秒的總通知數(shù)
  • 哪個通知系統(tǒng)使用最頻繁
  • 消息的平均大小和頻率
  • 基于優(yōu)先級過濾消息等等...

12. 通知跟蹤器

此服務(wù)將持續(xù)監(jiān)視事件中心隊列并跟蹤所有發(fā)送的通知。

它捕獲通知的元數(shù)據(jù),如傳輸時間、傳送狀態(tài)、通信渠道、消息類型等。

13. 通知數(shù)據(jù)庫:Mysql數(shù)據(jù)庫集群

通知數(shù)據(jù)庫,用于存儲庫用于存儲所有通知信息,包括發(fā)送時間、狀態(tài)等。

它包括一個數(shù)據(jù)庫集群,其中領(lǐng)導(dǎo)者用于執(zhí)行所有寫操作,讀取操作則在讀取副本/跟隨者上進行。

這個數(shù)據(jù)庫群集將持久化所有通知,供分析和報告使用。

它基于“寫入更多,讀取更少”的理念。

它能提供良好的性能和低延遲,適應(yīng)大量的通知,因為它內(nèi)部處理大量的寫操作,并與其他數(shù)據(jù)庫節(jié)點同步,保持高可用性和可靠性的冗余數(shù)據(jù)/消息。

在任何節(jié)點崩潰的情況下,消息將始終可用。

責(zé)任編輯:趙寧寧 來源: 技術(shù)老男孩
相關(guān)推薦

2025-03-06 01:00:55

架構(gòu)推送服務(wù)編程語言

2024-04-17 08:03:45

架構(gòu)設(shè)計Java

2024-04-16 08:19:40

架構(gòu)高可用消息隊列

2018-11-23 09:52:24

架構(gòu)設(shè)計架構(gòu)師

2023-12-06 19:04:31

多平臺消息推送

2022-05-24 09:30:00

消息吞吐車聯(lián)網(wǎng)平臺車聯(lián)網(wǎng)

2024-02-20 13:00:00

架構(gòu)設(shè)計模塊

2022-05-18 10:07:29

EMQ車聯(lián)網(wǎng)MQTT

2013-05-27 10:58:28

Tumblr架構(gòu)設(shè)計雅虎收購

2015-06-02 04:17:44

架構(gòu)設(shè)計審架構(gòu)設(shè)計說明書

2022-09-23 08:02:42

Kafka消息緩存

2025-04-15 04:00:00

2011-05-16 11:17:35

設(shè)計推送

2023-11-27 07:57:46

2023-07-05 08:00:52

MetrAuto系統(tǒng)架構(gòu)

2015-06-02 04:34:05

架構(gòu)設(shè)計

2009-07-10 09:31:57

MyEclipse U

2021-07-21 16:30:38

iOSAPP架構(gòu)

2017-11-17 07:06:27

互聯(lián)網(wǎng)分層架構(gòu)APP

2012-09-19 13:46:37

存儲存儲設(shè)計快速表態(tài)
點贊
收藏

51CTO技術(shù)棧公眾號