【中间件】中间件的宏观探讨漫谈
中间件探讨
内容管理
-
- intro
- 中间件和框架
- why use
- 常用相关Middleware
-
- 接入层
- 服务层
本文主要是宏观上再次探讨一下中间件
cfeng之前单纯的分享过缓存、消息队列、还有就是Spring Cloud下面提供的一些中间件的使用，但是整体上就是感觉很松散的，所以cfeng现在再次重新宏观梳理一下中间件
intro
中间件 Middleware，字面上看就是起中间作用的构件。早期的概念就是再操作系统的基础上，为其他应用软件提供服务的基础软件， 就像一种软件胶水连接系统以及应用服务。 比如中间件简化应用间的通信方式【可以不用再调用复杂系统函数即可数据传输】
而现在互联网分布式架构下，中间件是泛指在分布式系统中被广泛使用的中间层软件 ----- （we 所开发的软件不管是B端还是C端都是服务用户，而中间件就是服务于我们所开发的这些软件）
中间件和框架
framework和middleware是两个不同的概念，在软件开发过程中所起的作用不同。
框架Framework： 半成品可扩展
框架是一组预先编写好的代码和规范，提供一种结构，帮助开发者更容易的构建和维护应用程序，它是一种半成品，使用框架进行开发就是在别人搭建好的舞台上进行跳舞。 （要想成为成品，我们需要填入我们自己的业务逻辑。）
通常包含一系列库、工具和相关最佳实践，目的是简化特定类型的应用开发，定义了应用程序的体系结构，提供了通用的功能。比如数据持久、用户认证、路由等。
we使用框架时，就直接在框架的基础上进行搭建，不需要重头开始构建整个应用程序，而是在框架提供的结构下进行代码编写，完成程序的功能，它就是提供了一种模板化的方式，使得开发更加高效
java最常见的Spring Framework就是一个综合性的企业级框架，以IOC和AOP为核心，提供了各种综合性功能，整个生态不断扩大，包含
1. 基础的自动配置的Spring Boot(Spring、SpringMvc)
2. 安全管理的Spirng Security，提供了用户密码认证、OAuth、JWT等诸多特性
3. 数据访问支持的Spring Data -- JPA、MongoDB等
4. 基于webSocket通信的Spring WebScoket
5. 构建分布式系统的Spring Cloud --- Netflix、Alibaba、Config等
......
【Spring特别综合，就是一个重量级的开发框架，基本上构建一个程序的方方面面Spring都可以提供支持，当然这些领域除了Spring还有其他的框架与之竞争】
eg： 安全管理Shiro， 数据访问支持Hibernate、Mybatis-plus 等等， 我们在开发时在选用框架时就需要综合考虑
框架就是实现系统的半成品工具，最终的目的都是服务产品，所以我们开发都是结果产品为导向，那么就需要考虑：我们选用的工具是否恰好
eg： 现在需要将一个螺丝放入产品完成产品封装。你可以选择一个几元的螺丝刀实现，你也可以买一个很贵的多功能工具实现。 这个时候就需要慎重的考虑了
单独的框架是不能发挥作用的，填入用户代码之后才是一个完整的产品。以java为例，常用的Spring框架都是以java实现的，而最终又是以公司自身产品为目的，所以很多时候公司都会进行自定义的工具开发，来更好的适配自己的产品
cfeng在work中，产品可能频繁的需要和客户端交互获取前置的相关数据，所以公司也是直接封装了工具，使用直接一个注解搞定
中间件 Middleware： 可扩展独立运行成品
中间件通常是一种独立的系统软件或服务程序，可以连接多个独立的应用程序。不需要再填充用户代码，只需要作为一个用户来使用将中间件放入产品系统即可。
明显看出，中间件就是服务于我们的系统的，整体处于中间层，那为什么要使用中间件？必须使用吗？
我们需要持续的思考：如果没有某种XXX，我们应该如何做。
eg： 如果不允许使用Spring进行开发，我们应该怎么进行web开发？
没有Spring其实就是自己需要开发Spring提供的一些功能。从更基础开始搭建系统罢了
eg： 如果不允许使用Redis，怎么进行分布式缓存和其他相关协作
why use
为什么要使用中间件进行系统的通信和数据交互？主要在于 封装性
- 封装了底层操作的复杂性。 中间件可以根据公司具体情况进行经验配置，使用边界条件降级策略进行透明封装，用户不再需要考虑内部复杂性 【这个就是常常提到的原理， 比如Nacos怎么做服务注册的？ – 在使用的时候可能不需要深入考虑该问题】
- 封装了公共业务模型的具体实现。 也就是降低了学习使用成本，比如redis的使用，就是调用API，降低了调用方的业务逻辑表达能力。
- 封装性带来的良好的模块性。 中间件可以理解为公共逻辑的封装， 比如消息中间件处理消息交互的公共逻辑。使用定义清晰的中间件接口，简化业务逻辑架构，同时将缺陷封装在中间件中，可维护性提升。
常用相关Middleware
庞大的业务规模，通常伴随着海量的计算、数据交互、数据处理。同时也就伴随着中间件的使用。 计算机任何问题都可以通过分成解决，如果不行，那就再增加一层。中间件的引入其实也就是分层的思想，解决可用稳定性。
中间件的种类繁多，但是从整个架构层面也就是接入层和服务层来进行考虑
接入层
接入层就是首先面对internet中的大流量的冲击，所以常用的相关中间件就是流量相关的负载均衡中间件
- LVS： linux Virtual Server， 当然现在已经集成到Linux的内核模块中，主要作用就是负载均衡
- Nginx： 开源的高性能的HTTP和反向代理web服务器。 内存占用少，启动极快。【正向代理的是客户端，比如VPN； 反向代理的是服务器，用户无感知】
服务化: 微服务， 将功能以服务的形式提供，和服务导向架构Service-Oriented Architecture， SOA关联。各个组件以服务形式存在，通过网络进行通信。 后台的程序服务化，接入层也需要进行正确的路由
-
Dubbo： 提供高性能、透明化的远程方法调用(RPC)服务，支持服务治理和负载均衡，RPC是分布式系统间进行数据交互的基本形式
-
Sentinel： 开源的流量控制和防护库，保护分布式系统的服务免受不良请求的影响。 包括流量控制、熔断降级、实时监控、规则配置、异步处理等…
-
Spring Cloud生态：Spring Cloud构建分布式系统的开发工具集合，简化分布式开发，提供了注册发现、负载均衡、分布式配置、断路器、消息总线等功能
-
Eureka： 服务注册发现组件，需要单独创建一个Eureka Server节点
-
Ribbon： 基于HTTP和TCP的客户端负载均衡器， 后续还有Load Balancer等
-
Feign： 基于HTTP的声明式模板化的服务调用
-
Hystrix： 处理服务熔断降级，实现断路器模式，避免单点故障
-
Zuul： API网关服务，提供路由、顾虑和监控等功能
-
Config： 分布式配置中心，支持配置信息集中管理，动态刷新配置
-
Bus： 消息总线，用于微服务架构中传播状态变化或者事件消息
-
Zipkin： 分布式追踪系统，协调处理跨越多个服务的请求
-
Sleuth： 分布式跟踪系统， 收集、追踪微服务架构中的请求链路
-
Consul： 分布式注册中心和配置中心，可替代Eureka和Config
-
Spring Cloud Task： 任务和批处理程序…
…
-
其余的还有Nacos、Artemis、Apllo等各种和服务化相关中间件后续再详细展开
服务层
后台系统开发本身也需要使用相关的中间件来完成系统功能，不管是消息队列、定时调度、存储还是链路日志等都可以使用表现良好的中间件来完成功能。
消息中间件：
系统依赖关系解耦利器，常用于消息通信、服务解耦和流量削峰。发布/订阅数据交互模式可以将生产者和消费者的业务逻辑耦合程度降到最低。
- RabbitMQ
- RocketMQ
- Kafka
- Hermes
- QMQ …
定时调度：
定时task的调度是现在很多产品都面临的场景，成熟的task调度能够极大降低系统的开发难度
- Xxl- job
- Elastic- job …
存储
存储的中间件包含分布式缓存的解决方案、分布式系统下数据库的解决方案和全文搜索解决方案
- Redis、 Codis …
- MyCat、 Sharding-JDBC …
- ElasticSearch …
数据同步
大数据场景下对于数据同步要求也可以通过中间件来解决：
- Canal
- otter
- Flink-CDC …
链路跟踪
链路追踪也是分布式系统下常见的场景
- CAT
- SkyWalking …
日志采集
分布式环境下产品可能需要采集相关日志进行后台分析或者产品展示
- ELK …
除了上面部分领域的部分中间件，现在市场上的各种细分领域的中间件是层出不穷，中间件作为系统架构使用的成品，我们在使用时也需要谨慎思考。同时我们更需要掌握中间件的原理，从而开发更适合自己产品的中间件