中间件 - 初识

中间件 - 初识

​ 在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 来进行库存扣量
• 若是还有大量并发的请求则利用消息队列组件，当秒杀服务将订单信息写入消息队列后，便可认为下单完成，避免直接操做数据库。