中間件 - 初識
? 在Java項目實際開發中,我們所使用的ActiveMQ、RibbitMQ、Kafka、Tomcat、WebLogic,這些都可以統稱為中間件。
? 我們初次去了解,什么是中間件?
一、中間件簡介
? 什么是中間件?
? 由于業務、機構和技術是不斷變化的,因此為其服務的軟件系統必須適應這樣的變化。在合并、添加服務或擴展可用服務之后,公司可能無力負擔重新創建信息系統所需的成本。正是在這個關鍵時刻,才需要集成新組件或者盡可能高效地擴展現有組件。要集成異類組件,最方便的方法不是將它們重新創建為同類元素,而是提供一個允許它們進行通信(不考慮它們之間的差異)的層。該層被稱作中間件。
?
? 維基百科中的介紹:
? 中間件(英語:Middleware),又譯中間件、中介層,是提供系統軟件和應用軟件之間連接的軟件,以便于軟件各部件之間的溝通。在現代信息技術應用框架如 Web 服務、面向服務的體系結構等項目中應用比較廣泛。如數據庫、Apache 的 Tomcat ,IBM 公司的 WebSphere ,BEA 公司的 WebLogic 應用服務器,東方通公司的 Tong 系列中間件,以及 Kingdee 公司的等都屬于中間件。
?
? 中間件,顧名思義,就是連接在兩個軟件之間的東西,是軟件之間的一個粘合劑,一個膠水一樣的東西。它位于操作系統和我們的應用程序之間,可以讓開發者方便地處理通信、輸入和輸出,使開發者能夠專注于自己的業務邏輯開發。
? 這么一說,好像 Tomcat 確實還有點像中間件!位于我們的操作系統和應用程序之間!
二、中間件分類
? 中間件有很多,早在 1998 年 IDC 公司就將中間件分成了 6 大類,國內 2005 年之前出版的中間件相關的書上,很多都是按照這 6 大類來分的,分別是:
- 終端仿真/屏幕轉換
- 數據訪問中間件(UDA)
- 遠程過程調用中間件(Remote Procedure Call, RPC)
- 消息中間件(MOM)
- 交易中間件(TPM)
- 對象中間件(Object Request Broker, ORB)
? 這里邊除了消息中間件和交易中間件大家可能聽說過之外,其他的中間件估計都很少聽說,這是因為時代在變化,有的中間件慢慢被淘汰了(例如 終端仿真/屏幕轉換 中間件),有的則慢慢合并到其他框架中去了(例如 遠程過程調用中間件)。
三、面向消息的中間件 (Message-Oriented Middleware, MOM)
3.1 消息中間件介紹
? 消息隊列中間件是分布式系統中重要的組件,主要解決應用耦合、異步消息、流量削鋒等問題。實現高性能、高可用、可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
3.2 消息中間件的結構
四.JMS(Java Message Service)
4.1 什么是jms?
JMS即Java消息服務(Java Message Service)應用程序接口,是一個Java平臺中關于面向消息中間件(MOM)的API,用于在兩個應用程序之間,或分布式系統中發送消息,進行異步通信。Java消息服務是一個與具體平臺無關的API,絕大多數MOM提供商都對JMS提供支持。
4.2 JMS 消息傳送模式
- 客戶端 A、C 和 D之間的消息傳送說明了點對點模式(P2P)。客戶端使用此模式向隊列目的地發送一條消息,只有一個接收者能夠從該目的地獲得該消息。訪問該目的地的其他任何接收者都不能獲得該消息。
- 客戶端 B、E 和 F之間的消息傳送說明了發布/訂閱模式(publish-subscribe)。客戶端使用此廣播模式向主題目的地發送一條消息,任意數量的使用方訂戶都可以從該目的地檢索此消息。每個訂戶都獲得此消息的一個副本。
4.3 JMS 消息傳送對象
JMS 消息傳送的對象在編程域中基本保持不變:連接工廠、連接、會話、生成方、使用方、消息和目的地。
五、MQ (Message Queue)
MQ全稱為Message Queue,消息隊列(MQ)是正確而又完整的 JMS 實現,消息隊列(MQ)是一種應用程序對應用程序的通信方法。應用程序通過寫和檢索出入列隊的針對應用程序的數據(消息)來通信,而無需專用連接來鏈接它們。消息傳遞指的是程序之間通過在消息中發送數據進行通信,而不是通過直接調用彼此來通信,直接調用通常是用于諸如遠程過程調用的技術。
5.1 應用場景
1. 異步處理
場景說明:新用戶注冊發放100積分,180元新手大禮包,激活會員卡,傳統的做法有兩種:串行方式,并行方式。
- 串行方式
- 使用消息隊列
以上兩種方式,很容易發現同步處理的情況下都會涉及到非主業務的其他操作,其實注冊的的主流程不應該受其他事件影響,通過消息隊列的方式,可以把后續的處理流程進行異步處理可以大大提高響應速度。
2. 應用解耦
場景說明:企業中經常出現企業合作如:本公司的驢粉卡與電信合作,新開卡的用戶從電信端推送到我方,除了相對應的福利外,首先判斷是否注冊本公司賬戶,
沒有給予注冊,但是新用戶的相對應權益需要對等的發放。
- 傳統方式
缺點:
1.與其他系統過度耦合
2.短信發放或優惠券發放失敗,影響主業務
- 使用消息隊列
優點:
1.注冊完成然后將消息寫入隊列返回成功。
2.發放權益業務不影響主業務,實現解耦。
3. 秒殺方案
場景說明:秒殺活動對稀缺或者特價的商品進行定時定量售賣,吸引成大量的消費者進行搶購,但又只有少部分消費者可以下單成功。
因此,秒殺活動將在較短時間內產生比平時大數十倍,上百倍的頁面訪問流量和下單請求流量。
- 秒殺前:用戶不斷刷新商品詳情頁,頁面請求達到瞬時峰值。
- 秒殺開始:用戶點擊秒殺按鈕,下單請求達到瞬時峰值。
- 秒殺后:一部分成功下單的用戶不斷刷新訂單或者產生退單操作,大部分用戶繼續刷新商品詳情頁等待退單機會。
- 秒殺前,用戶不斷刷新商品詳情頁,造成大量的頁面請求。所以,我們需要把秒殺商品詳情頁與普通的商品詳情頁分開。對于秒殺商品詳情頁盡量將能靜態化的元素靜態化處理,除了秒殺按鈕需要服務端進行動態判斷,其他的靜態數據可以緩存在瀏覽器和CDN 上。這樣,秒殺前刷新頁面導致的流量進入服務端的流量只有很小的一部分。
- 利用讀寫分離 Redis 緩存攔截流量(活動未開始時攔截大部分動態數據請求)
- 成功參與下單后,進入下層服務,開始進行訂單信息校驗,庫存扣量。為了避免直接訪問數據庫,我們使用主從版 Redis 來進行庫存扣量
- 如果還有大量并發的請求則利用消息隊列組件,當秒殺服務將訂單信息寫入消息隊列后,即可認為下單完成,避免直接操作數據庫。