5月iOS設備好評榜：iPhone 14僅排第43？
來到新的一月，安兔兔的各個榜單又重新匯總了數據，像安卓陣營的榜單都有著比較大的變動，不過iOS由于設備的更新換代并沒有那么快，所以相對來說變化并不大，特別是iOS好評榜，老款設
大家好，我是冰河~~
分布式IM即時通訊系統本質上就是對線上聊天和用戶的管理，針對聊天本身來說，最核心的需求就是：發送文字、圖片、文件、語音、視頻、消息緩存、消息存儲、消息未讀、已讀、撤回，離線消息、歷史消息、單聊、群聊，多端同步，以及其他一些需求。
對用戶管理來說，存在的需求包含：添加好友、查看好友列表、刪除好友、查看好友信息、創建群聊、加入群聊、查看群成員信息、退出群聊、修改群昵稱、拉人進群、踢人出群、解散群聊、填寫群公告、修改群備注以及其他用戶相關的需求等。
注：拿小本子記錄下，后續可以寫到簡歷上的整合了OpenAI大模型的分布式IM即時通訊系統，從此，簡歷上又多了一個可以拿的出手的高并發、高性能、高可用、可監控、可預警、可伸縮，支持無限擴展的真實業務場景項目。
為了能夠讓小伙伴們更好的理解分布式IM即時通訊系統的設計，我們站在架構師的角度，在充分了解系統需求，業務流程和技術流程后，從全局視角為系統設定方案目標，對技術方案進行選型，對系統進行總體架構設計和分層架構設計，并梳理清楚發送消息的交互鏈路、單聊和群聊的交互鏈路。以方便各位小伙伴將分布式IM即時通訊系統寫到自己的簡歷中，增強自己的競爭力。
在進行技術選型與總體架構設計之前，需要明確一個事項，就是系統無論采用哪種方案，采用哪種架構設計都需要明確這種方案的業務目標、技術目標和架構目標，并在研發過程中不斷評估系統的總體性能表現，發現系統瓶頸并不斷進行優化。
總體上，我們搭建和開發的分布式IM即時通訊系統，需要滿足如下方案目標。
在技術選型上，除了采用SpringBoot等基礎框架外，也會采用容器化方案。同時，考慮到為了盡量降低技術門檻，在整個分布式IM即時通訊系統的技術選型中，主要采用市面上比較流行的技術框架和方案，具體選型如下所示。
對于IM即時通訊系統來說，涵蓋了即時通訊后端服務、大后端平臺、SDK接入服務、OpenAI接入服務、大前端UI，我相信不少小伙伴多多少少能夠畫出IM即時通訊系統的架構圖，大致如圖1-1所示。
其實，這種這種架構設計也比較常見，在這種架構設計中，Kong/Openresty/Nginx只做負載均衡和反向代理，研發人員更多的是關注業務層和基礎層的開發，流量比較小時，這種架構設計一般不會有什么問題。但是一旦流量比較大，用戶調用后端平臺的接口發送消息時，即時通訊SDK同步調用即時通訊服務的接口就會出現性能問題。
因為每個終端同時只能與一個IM即時通訊服務實例建立連接，如果大量的用戶終端恰好都與一個IM即時通訊服務建立連接，那即時通訊SDK頻繁同步調用同一個IM即時通訊服務的接口就會出現性能瓶頸。此時，出現性能瓶頸時，不僅僅會影響到IM即時通訊服務，也會對后端平臺接收請求的業務造成一定的影響。
既然圖1-1所示的架構設計存在性能瓶頸，那我們如何進行優化呢？為此我們在如1-1的基礎上進行了優化，優化后的架構如圖1-2所示。
對比圖1-1和圖1-2可以看出，在屏蔽掉技術實現細節的前提下，我們將對業務的校驗和流量管控進行前置化，放大Kong/OpenResty/Nginx的職責，使得這些軟件不僅具備反向代理和負載均衡的功能，還能實現限流、黑白名單、流量管控、業務校驗等功能。
也就是說，在這種架構模式下，我們充分發揮了整個分布式IM即時通訊系統的入口職責，充分利用Kong/OpenResty/Nginx的高并發、高吞吐量的能力，盡量將大部分無效請求擋在整個系統之外。例如，用戶在沒登錄系統的前提下，就嘗試調用發送消息、添加好友、添加群組等等接口。這樣會大大減輕后臺平臺的業務壓力。
除了在Kong/OpenResty/Nginx中實現限流、黑白名單、流量管控、業務校驗等功能外，我們還引入了業務網關集群，實現限流、降級、熔斷、流控、校驗、鑒權等功能，進一步保證下游系統的穩定性和安全。
為了解決大量用戶終端恰好連接到同一個IM即時通訊服務實例，IM即時通訊SDK頻繁調用同一個IM即時通訊服務實例的接口造成的性能問題。我們在IM即時通訊服務SDK與IM即時通訊服務之間引入了RocketMQ集群。
IM即時通訊服務集群中的每一個IM即時通訊服務實例在集群中都有一個唯一的ID，并且每個IM即時通訊服務實例在啟動后，只會監聽RocketMQ中與自身ID相關的Topic。這樣每個IM即時通訊服務只會收到與自身ID相關的Topic中的消息，不會接收所有的消息。
當用戶登錄系統后，就會與IM即時通訊服務建立長連接，并且會以用戶ID和終端為Key，以IM即時通訊服務的ID為value，將其存儲到分布式緩存中。同時，會以用戶ID和終端為Key，以用戶終端與IM即時通訊服務建立的長連接為value，將其存儲到IM即時通訊服務本地內存中。
當用戶調用后端平臺的接口發消息時，會帶上目標用戶的ID，并且在IM即時通訊SDK中會指定用戶登錄的終端設備，最終會通過IM即時通訊SDK向RocketMQ發送消息。
此時IM即時通訊SDK會根據目標用戶ID和終端從分布式緩存中獲取目標用戶連接的IM即時通訊服務的ID，并向此ID相關的Topic發送消息。此時與目標用戶建立長連接的IM即時通訊服務就會接收到RocketMQ中的消息，隨后根據用戶ID和終端從本地緩存中獲取到與用戶終端建立的長連接，并基于此長連接向用戶推送消息。
另外，在實際實現中，為了避免大量用戶同時只連接IM即時通訊服務集群中的某一個服務實例，會對用戶連接的IP、瀏覽器指紋、手機設備等做Hash和取模運算，使其盡量均勻分布到集群中的每一個服務實例上。
那么問題來了：這種架構設計還有進一步優化的空間嗎？
為進一步增強分布式IM即時通訊系統的性能、可用性和彈性伸縮能力，我們可以對分布式IM即時通訊系統進行容器化架構設計，如圖1-3所示。
可以看到，我們對分布式IM即時通訊系統的架構設計進行了進一步優化，采用了容器化架構設計。在原有架構的基礎上，我們進行了如下改進和優化。
基礎支撐服務會由各種基礎中間件、數據存儲服務、以及監控服務實現，包含：MySQL數據庫、TiDB數據庫、HBase、Redis緩存、RocketMQ消息隊列、Prometheus監控和Portainer容器管理等基礎中間件實現，基礎支撐服務會對整個分布式IM即時通訊系統提供最基礎的數據、傳輸、監控和容器管理等服務。
在容器化層面，會通過Docker、Swarm和Portainer實現，其中，會基于Swarm和Portainer對容器化進行管理。
除了上述分層架構外，對于建設分布式IM即時通訊系統來說，還要考慮異常監控、服務注冊與發現、可視化、服務降級與兜底數據、服務限流、服務容災、容量規劃與擴縮容和全鏈路壓測等。
在分布式IM即時通訊系統中，不管是大后端平臺，還是IM即時通訊服務，我們都會對業務層的代碼采用分層業務架構，這里，可以借鑒DDD的分層架構思想，將代碼總體上分成展示層、應用層、領域層和基礎設施層四個層次，但是，考慮到分布式IM即時通訊系統的特殊性，又不會嚴格按照DDD的原則來設計代碼分層，具體按照如圖1-4所示。
可以看到，分布式IM即時通訊系統會借鑒DDD的設計思想，但是不會完全按照DDD的方式進行設計。
展示層，也叫做用戶UI層，是DDD設計的最上層，對外提供API接口，接收客戶端請求，解析參數，返回結果數據，并對異常進行處理。
應用層，也叫做Application層，應用層主要處理容易變化的業務場景，可對相關的事件、調度和其他聚合操作進行相關的處理。
領域層，也叫做Domain層，領域層可以說是DDD設計的精髓所在，它是將業務系統中相對不變的部分抽象出來封裝成領域模型。
在分布式IM即時通訊系統的設計中，領域層基本不會依賴其他層，也不會依賴基礎設施層，這里是與DDD設計存在區別的地方。
基礎設施層，也叫做Infrastructure層，基礎設施層會對其他各層提供通用的基礎能力，在分布式IM即時通訊系統中，就包括了緩存、通用工具類、消息、系統的持久化機制等。
在分布式IM即時通訊系統中，我們忽略掉其他一些細節信息，重點關注下發送消息的交互鏈路邏輯。不管是單聊還是群聊，最終都需要通過IM即時通訊服務將消息推送給用戶的終端。此時發送消息的流程如圖1-5所示。
可以看到，用戶在分布式IM即時通訊系統發送消息時，不管是單聊還是群聊，最終的消息都會推送到用戶登錄的終端設備上。假設此時用戶A給用戶B發送消息，或者用戶A和用戶B在同一個群組，用戶A向群組發送消息，用戶B接收消息的主要流程如下。
要實現如上發送消息的流程，前提是要滿足如下條件。
單聊就是在分布式IM即時通訊系統中，一個用戶直接與另外一個用戶聊天，也就是一對一的聊天。在這種場景下，很有可能單聊的兩個用戶中，出現用戶不在線的情況。
例如，用戶A給用戶B發送消息時，用戶B可能不在線。此時，我們就需要將用戶A向用戶B發送的消息存儲起來。其實，在我們實現的分布式IM即時通訊系統中，無論把用戶B是否在線，都會存儲消息記錄。當用戶B登錄系統后，將消息同步給用戶B，如圖1-6所示。
可以看到，用戶A向用戶B發送消息時，如果用戶B在線，就可以按照發送消息的交互鏈路向用戶B發送消息了。如果用戶B不在線，此時就無法向用戶B正常推送消息。當用戶B登錄分布式IM即時通訊系統后，就會調用后端平臺的接口拉取所有未讀消息，并通過用戶B在線流程向用戶B推送消息。
群聊就是在分布式IM即時通訊系統中，多個用戶在同一個群組中進行聊天，此時在發送消息時，我們可以通過群組ID找出群內所有在線的用戶，將消息即時發送給在線的用戶。那些未在線的用戶就按照單聊未在線的用戶進行處理，如圖1-7所示。
可以看到，群聊的交互鏈路流程如下所示。
好了，看到這里，你明白如何設計一個高度可擴展的分布式IM即時通訊系統了嗎？趕緊拿本子記錄下你學到的知識，將其整理到簡歷上吧！
這些真實場景的項目設計與落地實現，在冰河的知識星球除了分布式IM即時通訊系統外，還有其他5個項目，這些項目的需求、方案、架構、落地等均來自互聯網真實業務場景，讓你真正學到互聯網大廠的業務與技術落地方案，并將其有效轉化為自己的知識儲備。
本文鏈接：http://www.www897cc.com/showinfo-26-39507-0.html這套分布式IM即時通訊系統如何寫到簡歷上？我給你整理好了！
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 一款小而美的開源滑動驗證碼組件
下一篇： 設計之魅：高質量面向對象設計的秘密
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號