软件中间件概念简介

背景简介

软件系统越来越庞大的今天，仅仅围绕早已过时的“数据 <——> 业务”来进行架构体系、系统框架、模块的划分已经不能满足需求了。 上世纪90年代，一个新兴名词 “中间件” 的出现，对以后随着互联网的暴发而急速膨胀的软件体系提供了新的规划方案。

企业软件巨头IBM也在第一时间将中间件实际应用到自己产品中，发布了著名的“IBM消息队列服务MQ”，解决分布式系统异步、可靠、传输的通讯服务问题，也正式将“中间件”这个词带入到实际生产中。

2008年，在国家启动的核高基重大科技专项中，对软件领域的重点支持部分有：操作系统、数据库、中间件、文字处理四大部分，其中就有这个相对陌生的“中间件”，可见其在软件系统中的重要性。

定义

中间件到底是个什么东西呢？实际对这个名词目前都没有一个很统一、具体的定义。引用维基百科的定义：

“中间件是一种计算机软件，它在操作系统上给应用软件提供有效可靠的服务。它可以被描述为‘软件胶’。中间件给软件开发者提供了更加方便的数据输入/输和其中间操作方式，通常也只注重于应用软件某一点的需求。”

个人感觉这个定义是最清晰靠谱的，结合之前工作中遇过相关场景，个人的理解就是：

“中间件就是为了补全原有的 ‘数据(操作系统) <—> 业务(应用程序)’ 简单模式，能够让这两端更好的专注于自身的领域，又能提供满足业务的数据需求，而产生的一种‘数据加工厂’”。

要点说明

如上所述中了解到，中间件只是软件体系规划上的一种抽象概念，不是一种具体的技术，但是在具体应用中怎么设计呢？下面举两个例子进行分析。

数据库驱动

从最原始概念出发：从数据库到业务应用。试想一下，两个团队，一个用JAVA，一个用PHP，使用同一个数据库，那些死板的数据库数据怎么能够被各种业务代码接收呢？

这个时候，几乎是最早出现的中间件 — 数据库驱动 就诞生了。通过它，各类语言可以亲切的获得自己想要的数据格式和类型，而不是自己从0开始读取原始字符串进行分析。这就是一个典型的中间件场景。

系统架构

在系统架构上，中间件得到了更多的体现，比较明显的就是在系统层级拆分后的上下层数据/消息交互上。

早前的系统，业务比较单一，所需的数据和其间的关联也不是很繁琐，一对一的交互就很能满足技术需求了，这算是系统演变的第一阶段。

后来，业务种类变多，基础的数据服务是一样的，单一的 service 已经不足以支持多项业务，比如有以下场景：

• 为了保证基础服务的统一和高维护性，基础数据服务提供的数据不会带有很重的业务属性。同时，上层的纯业务服务也不愿意将过多的数据适配放到自己的功能中，这样也会破坏型业务的单纯性，怎么办？
• 各业务间也会有业务交流，需要保证各业务中相关数据的同步性，而两边也是谁都不“愿意”做这一块的功能，怎么办？

这种事不就是“中间件”要干的吗？此时 “base service” 、 “data conversion”、“message” 的出现，稳定的从基础服务向各个业务输送着数据。

在如今系统拆分越多越详细，高内聚、低耦合也越来越实现的彻底时，中间件做为连接各个系统、服务的“中介者”，在大型企业级系统中，重要性已经和数据库、服务同日而语了。 不少新生的、或是老牌的框架系统，也不再像以前那样提供万斤油的功能，只给你一个最基础的平台，剩下的你需要什么自己去写（找）中间件吧。

对此类技术，国内也有做得挺不错的，阿里的“中间件和稳定性平台”研发的 druid 、Fastjson 应该无人不知了，在国外也有挺高有知名度。还有很多比如 RocketMQ 、dubbo 也是很厉害的👍🏿

(下一篇博客中，就以 KOA2 为例，说一下它的中间件集成。)

目前发展

在当前的互联网时代，各种信息间的联系可谓是空前的错综复杂，任意一个网络结点的数据不再是自己独有的。在这个时候，中间件已经作为IT基础设施，提供业务的灵活性，消除信息孤岛，提高IT的研发和运营效率。 SOA 的提出，云服务的盛行，各类网络数据模式的融合，异构系统的集成都给新一代的中间件发展提供了挑战的机遇。

参照：
[1] https://en.wikipedia.org/wiki/Middleware
[2] 浅析深究什么是中间件 (奉继承 博士)