中間件 - 初識

中間件 - 初識

​ 在Java項目實際開發中，咱們所使用的ActiveMQ、RibbitMQ、Kafka、Tomcat、WebLogic，這些均可以統稱爲中間件。

​ 咱們初次去了解，什麼是中間件?

1、中間件簡介

​ 什麼是中間件？

​ 因爲業務、機構和技術是不斷變化的，所以爲其服務的軟件系統必須適應這樣的變化。在合併、添加服務或擴展可用服務以後，公司可能無力負擔從新建立信息系統所需的成本。正是在這個關鍵時刻，才須要集成新組件或者儘量高效地擴展示有組件。要集成異類組件，最方便的方法不是將它們從新建立爲同類元素，而是提供一個容許它們進行通訊（不考慮它們之間的差別）的層。該層被稱做中間件。

​

​ 維基百科中的介紹：

​ 中間件（英語：Middleware），又譯中間件、中介層，是提供系統軟件和應用軟件之間鏈接的軟件，以便於軟件各部件之間的溝通。在現代信息技術應用框架如 Web 服務、面向服務的體系結構等項目中應用比較普遍。如數據庫、Apache 的 Tomcat ，IBM 公司的 WebSphere ,BEA 公司的 WebLogic 應用服務器，東方通公司的 Tong 系列中間件，以及 Kingdee 公司的等都屬於中間件。

​

​ 中間件，顧名思義，就是鏈接在兩個軟件之間的東西，是軟件之間的一個粘合劑，一個膠水同樣的東西。它位於操做系統和咱們的應用程序之間，可讓開發者方便地處理通訊、輸入和輸出，使開發者可以專一於本身的業務邏輯開發。

​ 這麼一說，好像 Tomcat 確實還有點像中間件！位於咱們的操做系統和應用程序之間！

2、中間件分類

​ 中間件有不少，早在 1998 年 IDC 公司就將中間件分紅了 6 大類，國內 2005 年以前出版的中間件相關的書上，不少都是按照這 6 大類來分的，分別是：

1. 終端仿真/屏幕轉換
2. 數據訪問中間件（UDA）
3. 遠程過程調用中間件（Remote Procedure Call, RPC）
4. 消息中間件（MOM）
5. 交易中間件（TPM）
6. 對象中間件（Object Request Broker, ORB）

​ 這裏邊除了消息中間件和交易中間件你們可能據說過以外，其餘的中間件估計都不多據說，這是由於時代在變化，有的中間件慢慢被淘汰了（例如 終端仿真/屏幕轉換 中間件），有的則慢慢合併到其餘框架中去了（例如 遠程過程調用中間件）。

3、面向消息的中間件 (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 消息傳送的對象在編程域中基本保持不變：鏈接工廠、鏈接、會話、生成方、使用方、消息和目的地。

5、MQ (Message Queue)

MQ全稱爲Message Queue,消息隊列(MQ)是正確而又完整的 JMS 實現,消息隊列（MQ）是一種應用程序對應用程序的通訊方法。應用程序經過寫和檢索出入列隊的針對應用程序的數據（消息）來通訊，而無需專用鏈接來連接它們。消息傳遞指的是程序之間經過在消息中發送數據進行通訊，而不是經過直接調用彼此來通訊，直接調用一般是用於諸如遠程過程調用的技術。

5.1 應用場景

1. 異步處理

場景說明:新用戶註冊發放100積分,180元新手大禮包,激活會員卡，傳統的作法有兩種:串行方式,並行方式。

• 串行方式

---

• 使用消息隊列

以上兩種方式，很容易發現同步處理的狀況下都會涉及到非主業務的其餘操做，其實註冊的的主流程不該該受其餘事件影響,經過消息隊列的方式,能夠把後續的處理流程進行異步處理能夠大大提升響應速度。

2. 應用解耦

場景說明:企業中常常出現企業合做如:本公司的驢粉卡與電信合做，新開卡的用戶從電信端推送到我方,除了相對應的福利外，首先判斷是否註冊本公司帳戶，
沒有給予註冊，可是新用戶的相對應權益須要對等的發放。

• 傳統方式

缺點:

1.與其餘系統過分耦合
2.短信發放或優惠券發放失敗，影響主業務

---

• 使用消息隊列

優勢:

1.註冊完成而後將消息寫入隊列返回成功。
2.發放權益業務不影響主業務，實現解耦。

---

3. 秒殺方案

場景說明:秒殺活動對稀缺或者特價的商品進行定時定量售賣，吸引成大量的消費者進行搶購，但又只有少部分消費者能夠下單成功。
所以，秒殺活動將在較短期內產生比平時大數十倍，上百倍的頁面訪問流量和下單請求流量。

• 秒殺前：用戶不斷刷新商品詳情頁，頁面請求達到瞬時峯值。
• 秒殺開始：用戶點擊秒殺按鈕，下單請求達到瞬時峯值。
• 秒殺後：一部分紅功下單的用戶不斷刷新訂單或者產生退單操做，大部分用戶繼續刷新商品詳情頁等待退單機會。

• 秒殺前，用戶不斷刷新商品詳情頁，形成大量的頁面請求。因此，咱們須要把秒殺商品詳情頁與普通的商品詳情頁分開。對於秒殺商品詳情頁儘可能將能靜態化的元素靜態化處理，除了秒殺按鈕須要服務端進行動態判斷，其餘的靜態數據能夠緩存在瀏覽器和CDN 上。這樣，秒殺前刷新頁面致使的流量進入服務端的流量只有很小的一部分。
• 利用讀寫分離 Redis 緩存攔截流量(活動未開始時攔截大部分動態數據請求)
• 成功參與下單後，進入下層服務，開始進行訂單信息校驗，庫存扣量。爲了不直接訪問數據庫，咱們使用主從版 Redis 來進行庫存扣量
• 若是還有大量併發的請求則利用消息隊列組件，當秒殺服務將訂單信息寫入消息隊列後，便可認爲下單完成，避免直接操做數據庫。