微服务是大型架构的必经之路，也是大厂重点考察对象，下面我就重点详解4大主流微服务架构方案。
1、微服务聚合模式
微服务聚合设计模式，解决了如何从多个微服务中聚合数据，以便客户端可以获得所需的完整信息，而不需要多次请求不同的服务。
此类模式主要用于简化客户端的操作，减少与多个微服务交互的复杂性。
如下图所示：
通过构建一个聚合服务（又称聚合层或聚合微服务），将多个微服务的响应数据进行聚合，形成一个统一的结果返回给客户端。
聚合服务，通过调用多个微服务的 API，收集它们的响应并进行整合。
优点：
缺点：
- 聚合服务可能成为性能瓶颈，需特别关注聚合服务的可扩展性。
- 如果聚合的服务很多，可能需要额外的处理来确保高效聚合。
2、微服务共享模式
微服务提倡的是：每个服务拥有自己的独立数据库（比如：数据库独立性原则），以确保服务之间的高内聚性、和低耦合性。
然而，在某些情况下，由于业务需求或技术限制，多个微服务可能需要共享数据。
如下图所示：
实际上在微服务架构的初期阶段，很多企业可能会采用 共享数据库 模式，来简化系统的开发和维护，尤其是在微服务迁移的过渡阶段。
这样做虽然简化了架构，但却违反了微服务的原则，因为它导致了微服务之间的紧密耦合。
因此，“共享数据库”模式通常被视为“过渡性”或“反模式”，不是长期推荐的设计。
3、微服务代理模式
微服务代理是一种中间层，用于处理服务之间的通信。
如下图所示：
在这种模式下，代理服务充当了其他微服务的代理，接收客户端的请求并将其转发给后端服务进行处理。
在 Sidecar 代理模式 中，Sidecar 是与每个微服务实例配对部署的。
每个微服务实例旁边都有一个独立的代理进程，这些代理共同组成一个统一的服务网格。
代理负责捕获并管理服务的入站和出站流量。代理通常会与服务网格的 控制平面 交互，获取流量路由、负载均衡、访问策略等配置。
优点：
- 解耦：客户端和微服务之间的交互通过代理服务来处理。
- 统一入口：所有请求都经过代理，易于管理、监控和控制。
缺点：
- 代理服务需要额外的资源来处理请求，可能成为性能瓶颈。
4、微服务异步消息模式
异步消息设计模式，在微服务架构中非常重要，它允许微服务通过消息队列、事件流等方式进行松散耦合的通信。
如下图所示：
微服务通过发布事件来通知其他服务发生了某个状态变化。事件通常是业务变化或数据变化的通知，例如：订单创建、支付成功…等。
优点：
- 服务解耦：服务之间不需要直接调用，只有事件通知机制。
- 提高吞吐量：通过异步处理，减少了服务的同步依赖。
缺点：
- 事件的顺序和一致性需要额外考虑，容易出现“事件丢失”或“消息重复消费”的问题。
