中間件 - 初識

? 在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 來進行庫存扣量
• 如果還有大量并發的請求則利用消息隊列組件，當秒殺服務將訂單信息寫入消息隊列后，即可認為下單完成，避免直接操作數據庫。

轉載于:https://www.cnblogs.com/shi-tian/p/11488729.html

總結

以上是生活随笔為你收集整理的中间件 - 初识的全部內容，希望文章能夠幫你解決所遇到的問題。

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