微服务是大型架构的核心，下面我重点详解微服务架构模式@mikechen
微服务聚合方案
通过聚合层（聚合器）调用多个微服务，整合它们结果后对外提供统一服务。
优点：
简化客户端交互：客户端只需与聚合服务通信，降低客户端复杂性。
统一接口：聚合服务提供统一API入口，便于前端或外部系统调用。
缺点：
单点故障风险：聚合服务若宕机，可能影响整个请求链。
性能瓶颈：聚合服务需等待所有依赖服务的响应，延迟可能累积。
复杂性增加：聚合服务需处理跨服务的数据一致性和错误处理。
应用场景：
多个微服务数据需要组合展示的场景，如前端聚合接口。
微服务共享方案
多个微服务，共享访问同一数据库、或者缓存资源。
优点：
数据访问简单：服务直接查询共享数据库，无需额外API调用。
实现快速：适合从单体架构迁移到微服务，保留原有数据库结构。
事务一致性：共享数据库支持强一致性事务（如ACID），适合事务性需求。
缺点：
破坏微服务自治原则，服务间强耦合，不利于服务独立部署和演进。
应用场景：
传统单体系统向微服务转型的过渡期。
不推荐在新建微服务时采用。
微服务代理模式
通过一个代理层（如API网关），处理客户端请求，代理层负责路由、认证、限流等功能。
并将请求转发到后端微服务，API网关是微服务的统一入口。
优点：
灵活处理客户端调用逻辑，减少客户端复杂性。
代理层可以做协议转换、请求合并、路由控制等。
缺点：
代理增加额外网络跳转，带来延迟。
代理过于复杂时，难以维护。
微服务异步消息模式
微服务间通过消息队列等异步方式通信，避免同步调用带来的阻塞。
比如：微服务通过消息队列（如Kafka、RabbitMQ）异步通信。
一个服务发布消息到队列，其他服务订阅并处理消息，实现解耦和异步处理。
优点：
提高系统解耦，增强容错和异步处理能力。
减少请求等待时间，提高吞吐量。
缺点：
调试和跟踪复杂，异步逻辑难维护。
需要额外消息基础设施，增加系统复杂度。
不适合实时或强一致性场景。
应用场景：
事件驱动、异步处理场合，如订单处理、日志收集。