分布式系统中，为啥需要消息中间件

为什么需要消息中间件？
因为现在的分布式服务系统中，由于业务拆分，应用也需要拆分甚至数据都是分库分表的。但是往往完成一个业务处理，往往涉及多个模块之间的协调处理。模块之间、服务与服务之间，以及客户端和服务端之间的通信都变得非常复杂。这时候使用分布式异步通信的模式，引入消息中间件，就可以系统间解耦、这时候跨平台，系统异构也就变的不是问题了。同时还可以起到流量的削峰填谷。这里用一个问题举例，带大家理解一下消息中间件在分布式系统中起到的作用。

常见的软件架构

一、目前分布式架构的通信方式

1.1 SOA( 面向服务架构)使用RPC通信

什么是SOA: SOA的全称是 Service-oriented Architecture ，SOA是在企业IT系统重复构建和效率低下的情况下被提出的一个模型。所有功能定义成了独立的服务，服务通过企业服务总线ESB来联结。目前主流的SOA实现方法，包括WebService、服务注册中心、企业服务总线。目前常用的是Zookeeper作为注册中心，利用Dubbo完成服务间远程调用(RPC)。Dubbo使用了自定义的TCP协议，优化了报文体积，或者使用Http2 都提高了传输的效率。
涉及角色：服务提供者、服务消费者、注册中心
**优点：**是一种松耦合的结构，适合整合已经存在的各种异构系统。
**缺点：**需要实现各种异构系统的适配本身就会引入更多的复杂性。

1.2 微服务使用Http通信

在分布式的系统中，微服务使用Http完成服务间的通信，例如SpringBoot使用Fegin

二、分布式系统通信中遇见的问题

2.1 多个服务调用，怎么保证速度和可靠性

假设添加商品功能，涉及三个服务的操作

1. 数据服务新增商品记录
2. 搜索服务更新索引
3. 页面服务更新静态页面

2.2 方式一：直接同步调用

方案： 商品新增成功后分别调用 “搜索服务更新索引”和“页面服务更新静态页面"，都成功后再告诉用户新增结果。
优化处理： 1、多线程异步分别调用节省时间 2、增加失败重试并限制次数
问题： 1.重试造成响应慢 2.如果重试多次不成功 系统没有对应的处理机制 3.并发量上来时,可能一直阻塞

2.3 方式二：暂时缓存，异步消费

方案： 商品添加成功后，后续任务提交到公共的位置后续由相应的服务获取执行。解决了线程阻塞的问题，提高了响应速度。
优化处理： 处理时增加重试机制、错误结果再次单独保存后续补偿处理。
问题： 公共的任务池是否会崩溃、任务池是否收到消息、提交任务失败如何处理、提交任务重复如何处理、重复执行的幂等性如何保证

2.3 方式三：异步消息模式使用消息中间件

异步消息模式 ：是一种比较典型的生产着消费者模式，对跨平台、异构系统支持友好，通常借助消息中间件完成。
优点： 系统间解耦，并具有一定的可恢复性，支持异构系统，下游通常可并发执行，系统具备弹性。服务解耦、流量削峰填谷等
缺点： 消息中间件存在一些瓶颈和一致性问题，对于开发来讲不直观且不易调试，有额外成本。

三、异步消息模式需要注意的问题

1. 哪些业务需要同步处理，哪些业务可以异步处理？
2. 如何保证消息的安全？消息是否会丢失，是否会重复？
3. 请求的延迟如何能够减少？
4. 消息接收的顺序是否会影响到业务流程的正常执行？
5. 消息处理失败后是否需要重发？如果重发如何保证幂等性？