打死都要记住！微服务架构的常用设计模式！

最新推荐文章于 2025-08-30 19:28:38 发布
转载 最新推荐文章于 2025-08-30 19:28:38 发布 · 210 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：http://www.iocoder.cn/zhishixingqiu/?vip\x26amp;amp;mp
文章标签：

#中间件 #设计模式 #数据库 #java #分布式

本文深入探讨了六种关键的微服务设计模式，包括聚合器、代理、链式、分支、数据共享及异步消息传递模式，每种模式都有其独特的应用场景和优势，帮助读者理解如何设计高效、灵活的微服务架构。

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 8:55 更新文章，每天掉亿点点头发...

源码精品专栏

 

来源：cnblogs.com/duanxz/p/3514895.html

  • 1、聚合器微服务设计模式

  • 2、代理微服务设计模式

  • 3、链式微服务设计模式

  • 4、分支微服务设计模式

  • 5、数据共享微服务设计模式

  • 6、异步消息传递微服务设计模式

1.微服务架构模式方案

用Scale Cube方法设计应用架构，将应用服务按功能拆分成一组相互协作的服务。每个服务负责一组特定、相关的功能。每个服务可以有自己独立的数据库，从而保证与其他服务解耦。

1、聚合器微服务设计模式

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、代理微服务设计模式

这是聚合器模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。

3、链式微服务设计模式

这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。

4、分支微服务设计模式

这种模式是聚合器模式的扩展，允许同时调用两个微服务链

5、数据共享微服务设计模式

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式

6、异步消息传递微服务设计模式

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 20 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

兄弟，艿一口，点个赞！????

微服务架构设计：Java 和 Spring Boot 的实战指南！
**My Coding Family**
05-26 1288
🏆本文收录于《滚雪球学Spring Boot》，专门攻坚指数提升，2025 年国内最系统+最强（更新中）。    本专栏致力打造最硬核 Spring Boot 从零基础到进阶系列学习内容，🚀均为全网独家首发，打造精品专栏，专栏持续更新中…欢迎大家订阅持续学习。 如果想快速定位学习，可以看这篇【SpringBoot教程导航帖】,你想学习的都被收集在内，快速投入学习！！两不误。
提示工程架构师进阶手册：微服务治理的12个设计模式（案例详解）
AI 原生应用开发的博客
08-22 637
服务发现的核心是两个组件注册中心（Registry）：服务的“电话本”，存储所有服务的实例信息（IP、端口、状态）；服务提供者（Provider）：启动时向注册中心“报名”（注册）；服务消费者（Consumer）：从注册中心“查号”（发现），获取可用的服务实例。客户端负载均衡的核心是消费者内置负载均衡算法，直接调用服务实例，无需经过网关。轮询（Round Robin）：按顺序选实例；随机（Random）：随机选实例；加权轮询（Weighted Round Robin）：给高性能实例分配更高权重；
架构师必须掌握的重要微服务架构设计模式！
Larry的博客
03-06 3618
参考该文章 https://www.infoq.cn/article/kdw69bdimlx6fsgz1bg3 这边文章主要介绍一下微服务架构及其重要的设计模式，并介绍每种模式的优点，缺点，适用场景和不适用的场景，及其可用实现的技术有哪些。 微服务架构设计模式列表： 独享数据库（Database per Microservice） 事件源（Event Sourcing） 命令和查询职责分离（CQRS） Saga 面向前端的后端 （BFF） API 网关 Strangler 断路器.
微服务设计模式（下）
HULK一线技术杂谈
11-20 491
女主宣言本文旨在让大家了解微服务体系结构的设计模式以克服微服务所带来的挑战。文章会分为上下两篇，上篇包含1、分解模式2、集成模式，下篇包含3、数据库模式4、可观测性模式5...
微服务最重要的10个设计模式
m0_71777195的博客
07-12 423
从软件开发早期（1960 年代）开始，应对大型软件系统中的复杂性一直是一项令人生畏的任务。多年来为了应对软件系统的复杂性，软件工程师和架构师们做了许多尝试：David Parnas 的模块化和封装 （1972）， Edsger W. Dijkstra （1974）的关注点分离以及 SOA（1988）他们都是使用分而治之这项成熟的传统技术来应对大型系统的复杂性。自 2010 年开始，这些技术被证实无法继续应对 Web 级应用或者现代大型企业级应用的复杂性。
微服务设计模式
专注-享学课堂
09-20 1196
 链式微服务设计模式 这种模式在接收到请求后会产生一个经过合并的响应，如下图所示： 在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。 分支微服务设计模式 这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：
微服务设计模式（上）
HULK一线技术杂谈
11-06 456
女主宣言本文旨在让大家了解微服务体系结构的设计模式以克服微服务所带来的挑战。文章会分为上下两篇，上篇包含1、分解模式2、集成模式，下篇包含3、数据库模式4、可观测性模式5...
十、软件设计&架构-微服务-服务网关
princemilo的博客
11-26 1368
网关作为分布式架构中的重要中间件，不仅承担着路由分发（重点关注Path规则配置），同时可根据自身负载均衡策略，对多个注册服务实例进行均衡调用。
Spring Cloud与微服务学习总结（7）——Spring Cloud微服务架构实践与经验总结
科技D人生
07-13 5710
前言 突然看到这个一个问题《Spring Cloud在国内中小型公司能用起来吗？》。好问题。好问题必须配认真的回答，仔细的看了题主的问题，发现这个问题非常具有代表性，可能是广大网友想使用Spring Cloud却又对Spring Cloud不太了解的共同想法，题主对Spring Cloud使用的方方面面都进行过了思考，包括市场，学习、前后端、测试、配置、部署、开发以及运维。 想要明白这个问题，首...
AI应用架构师实战：用微服务+大模型打造高可用AI驱动服务
最新发布
AI 算法实战派
08-30 1221
稳：不能因为某个组件故障导致整个系统崩溃；快：用户提问后要在2秒内拿到响应；省：大模型调用成本不能无限制增长。微服务的解耦、独立部署、弹性伸缩正好解决“稳”和“快”的问题；而大模型的通用智能能力是AI服务的核心，但需要通过微服务的封装、缓存、负载均衡来解决“省”和“可靠”的问题。微服务是“骨架”，支撑系统的高可用；大模型是“大脑”，提供智能能力——两者结合才能让AI应用从“玩具”变成“工具”。大模型封装层：永远不要让业务服务直接调用大模型API，要封装成独立的服务，处理限流、缓存、fallback。
微服务架构的常用设计模式
beeworkshop的博客
02-25 542
1 聚合器微服务设计模式 这是一种最常用也最简单的设计模式，如下图所示： 聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z...
微服务设计模式概述
qq_42828391的博客
10-11 938
Design Patterns for Microservices 微服务在企业中可以带来积极的影响。 因此，如何处理微服务体系架构（MSA）和一些微服务设计模式以及微服务体系架构的一般目标或原则是很有必要的。 以下是微服务架构实现中要考虑的四个目标
目前最流行微服务，说说微服务架构的6种模式(内有文档)
kxkxyzyz的博客
02-01 3273
前言 就目前而言，对于微服务业界并没有一个统一的、标准的定义(While there is no precise definition of this architectural style ) 。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。 微服务 1....
微服务的设计模式
ServiceMesher
08-19 735
作者：Madhuka Udantha译者：崔秀龙原文：https://dzone.com/articles/design-patterns-for-microservic...
微服务网格中，什么是sidecar，什么是sidecar模式？
08-20
### **微服务网格中的 Sidecar 与 Sidecar 模式详解** --- #### **1. Sidecar 是什么？** **Sidecar** 是一个与主应用容器（如微服务）**并行运行**的辅助容器，**共享同一个 Pod 的生命周期**（同生同死），但承担与业务逻辑无关的**基础设施功能**，例如： - **网络通信**：服务发现、负载均衡、熔断、重试。 - **安全**：TLS 加密、身份认证、授权。 - **可观测性**：指标收集（Prometheus）、日志聚合（Fluentd）、分布式追踪（Jaeger）。 - **流量管理**：A/B 测试、灰度发布、请求路由。 **关键特性**： - **透明性**：主容器无需感知 Sidecar 的存在，业务代码零修改。 - **隔离性**：Sidecar 故障不会直接影响主容器（但可能影响通信能力）。 --- #### **2. Sidecar 模式（Sidecar Pattern）** **Sidecar 模式**是一种设计模式，通过将基础设施功能**剥离到独立的 Sidecar 容器**中，实现以下目标： - **解耦**：业务代码与运维能力分离，开发者只需关注业务逻辑。 - **复用**：同一 Sidecar 可被多个微服务复用（如 Envoy、Linkerd-proxy）。 - **统一治理**：在服务网格（如 Istio）中，所有流量由 Sidecar 代理，实现全局策略控制。 **典型架构**： ```mermaid graph LR A[微服务容器] -->|HTTP/gRPC| B(Sidecar 代理) B -->|加密/路由| C[其他服务] B -->|指标/日志| D[监控系统] ``` --- #### **3. Sidecar 如何工作？（以 Istio 为例）** ##### **步骤1：注入 Sidecar** - **手动注入**：通过 `istioctl kube-inject` 修改 Deployment，在 Pod 中增加 Envoy 容器。 - **自动注入**：为 Namespace 打标签 `istio-injection=enabled`，K8s 准入控制器自动注入。 ##### **步骤2：流量劫持** - Sidecar 通过 **iptables 规则**拦截进出 Pod 的流量（默认捕获 15001 端口的入站流量和 15006 端口的出站流量）。 - 业务容器原本访问 `service-B:80` 的请求，被透明转发到 Sidecar。 ##### **步骤3：策略执行** - Sidecar 根据服务网格下发的配置（如 VirtualService、DestinationRule），执行： - 负载均衡（轮询/一致性哈希）。 - 熔断（错误率超阈值时拒绝请求）。 - TLS 双向认证（自动管理证书）。 ##### **步骤4：数据上报** - Sidecar 将指标（如 QPS、延迟）推送到 Prometheus，日志发送到 Fluentd。 --- #### **4. Sidecar vs. 传统模式** | **对比维度** | **传统微服务** | **Sidecar 模式** | |--------------------|----------------------------------------|--------------------------------------| | **代码耦合度** | 需在业务代码中集成 SDK（如 Hystrix） | 业务代码零修改，功能由 Sidecar 实现 | | **升级维护** | 需重新部署所有服务 | 单独升级 Sidecar 容器 | | **多语言支持** | 需为每种语言实现 SDK | 语言无关（Sidecar 统一处理协议） | | **资源开销** | 低（无额外容器） | 较高（每个 Pod 需运行 Sidecar） | --- #### **5. 常见 Sidecar 工具** - **服务网格**：Istio（Envoy）、Linkerd（Linkerd-proxy）、Consul Connect。 - **可观测性**：Fluent Bit（日志）、OpenTelemetry Collector（追踪）。 - **安全**：Vault Agent（密钥管理）、SPIRE（身份认证）。 --- #### **6. Sidecar 的优缺点** **优点**： - **业务无关性**：开发者无需关心非功能需求（如重试策略）。 - **动态配置**：通过服务网格 API 实时更新策略（无需重启 Pod）。 **缺点**： - **资源占用**：每个 Pod 增加一个容器，可能消耗额外 CPU/内存。 - **调试复杂度**：流量路径变长，问题排查需分析 Sidecar 日志。 --- #### **7. 示例：Kubernetes 中的 Sidecar 定义** ```yaml apiVersion: v1 kind: Pod metadata: name: product-service spec: containers: - name: main-app # 主业务容器 image: my-product-service:1.0 ports: - containerPort: 8080 - name: envoy-sidecar # Sidecar 容器 image: envoyproxy/envoy:v1.25 volumeMounts: - name: envoy-config mountPath: /etc/envoy volumes: - name: envoy-config configMap: name: envoy-config # 预定义的 Envoy 配置 ``` ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值