文章目录前言微服务部署微服务多实例部署微服务容器化部署微服务Serverless部署微服务容器编排部署微服务架构模式微服务聚合模式微服务共享模式微服务代理模式微服务异步消息模式前言微服务部署微服务部署是微服务非常重要的环节下面详解4种常见的微服务部署案例微服务多实例部署微服务多实例部署是微服务架构中最基础、最常见的部署模式通过为每个微服务部署多个运行实例。如下图所示比如在一台服务器上部署了用户服务 (User Service) 的两个实例。实例1server:port:8081spring:application:name:user-service实例2server:port:8082spring:application:name:user-service每个微服务实例必须监听不同的网络端口以避免端口冲突。然而需要注意单台服务器的资源限制、和潜在的单点故障风险。比如单台服务器的 CPU、内存和网络资源是有限的运行过多的实例可能会导致资源竞争反而降低性能。对于生产环境中的关键微服务建议考虑跨多台服务器的分布式部署。微服务容器化部署微服务容器化部署是一种将每个微服务、及其所有依赖项打包到独立容器中的部署方法。如下图所示可以使用Docker(最流行的容器化平台)用于构建、打包、分发和运行容器。Docker 将微服务及其运行环境JDK、依赖库等打包成镜像。dockerbuild-tuser-service:1.0.无论部署在哪台服务器上都能保持行为一致。dockerrun-d-p8080:8080--name user-service user-service:1.0大大减少了“开发能跑、测试能跑、线上跑不了”的问题。真正做到一次构建到处运行Build once, run anywhere。微服务Serverless部署微服务 Serverless 部署是一种将服务部署、和运行责任交给云平台的现代架构方式。微服务 Serverless 部署带来了与传统容器化部署不同的价值它进一步抽象了基础设施管理让开发者更专注于业务逻辑。Serverless 平台比如 AWS Lambda…等等负责底层的基础设施管理。开发者无需关心这些运维细节可以将更多精力投入到业务代码的编写。Serverless 部署通常根据实际的请求量自动弹性伸缩无需预先配置或管理实例。只为实际执行的计算资源付费闲置时不产生费用可以显著降低成本尤其对于流量波动较大的服务。微服务容器编排部署除此之外还可以结合容器化、与自动化编排比如K8S等来部署。如下图所示1. 用户请求2. │3. ┌─▼──────┐4. │Ingress│⇽⇽Nginx入口控制器5. └─┬──────┘6. │7. ┌─▼────────────┐8. │Service(ClusterIP)│⇽⇽微服务的内部服务发现9. └─┬────────────┘10. │11. ┌─▼────────────┐12. │Pod多个副本│⇽⇽每个Pod运行1个微服务实例13. └──────────────┘Kubernetes 可以自动化微服务的部署、更新和回滚过程大大简化了发布流程。Kubernetes 可以在各种环境中部署包括公有云、私有云和混合云。Kubernetes 解决了大规模微服务部署、和管理中的诸多挑战。微服务架构模式微服务是大型架构的基石下面详解4大主流微服务架构方案微服务聚合模式微服务聚合设计模式解决了如何从多个微服务中聚合数据以便客户端可以获得所需的完整信息而不需要多次请求不同的服务。此类模式主要用于简化客户端的操作减少与多个微服务交互的复杂性。如下图所示通过构建一个聚合服务又称聚合层或聚合微服务将多个微服务的响应数据进行聚合形成一个统一的结果返回给客户端。聚合服务通过调用多个微服务的 API收集它们的响应并进行整合。优点简化客户端请求客户端只需调用聚合服务不需要直接与多个微服务交互。减少服务间依赖聚合服务可以减轻微服务之间的耦合度服务间可以独立变化。缺点聚合服务可能成为性能瓶颈需特别关注聚合服务的可扩展性。如果聚合的服务很多可能需要额外的处理来确保高效聚合。微服务共享模式微服务提倡的是每个服务拥有自己的独立数据库比如数据库独立性原则以确保服务之间的高内聚性、和低耦合性。然而在某些情况下由于业务需求或技术限制多个微服务可能需要共享数据。如下图所示实际上在微服务架构的初期阶段很多企业可能会采用 共享数据库 模式来简化系统的开发和维护尤其是在微服务迁移的过渡阶段。这样做虽然简化了架构但却违反了微服务的原则因为它导致了微服务之间的紧密耦合。因此“共享数据库”模式通常被视为“过渡性”或“反模式”不是长期推荐的设计。微服务代理模式微服务代理是一种中间层用于处理服务之间的通信。如下图所示在这种模式下代理服务充当了其他微服务的代理接收客户端的请求并将其转发给后端服务进行处理。在 Sidecar 代理模式 中Sidecar 是与每个微服务实例配对部署的。每个微服务实例旁边都有一个独立的代理进程这些代理共同组成一个统一的服务网格。代理负责捕获并管理服务的入站和出站流量。代理通常会与服务网格的 控制平面 交互获取流量路由、负载均衡、访问策略等配置。优点解耦客户端和微服务之间的交互通过代理服务来处理。统一入口所有请求都经过代理易于管理、监控和控制。缺点代理服务需要额外的资源来处理请求可能成为性能瓶颈。微服务异步消息模式异步消息设计模式在微服务架构中非常重要它允许微服务通过消息队列、事件流等方式进行松散耦合的通信。如下图所示微服务通过发布事件来通知其他服务发生了某个状态变化。事件通常是业务变化或数据变化的通知例如订单创建、支付成功…等。优点服务解耦服务之间不需要直接调用只有事件通知机制。提高吞吐量通过异步处理减少了服务的同步依赖。缺点事件的顺序和一致性需要额外考虑容易出现“事件丢失”或“消息重复消费”的问题。本文的引用仅限自我学习如有侵权请联系作者删除。参考知识微服务部署案例详解(4大部署案例)微服务架构方案详解(4大架构模式) 
长河君 · 2026/11/4 7:16:47 · 阅读 1.2k 10. 软件设计架构-微服务-部署和架构模式
文章目录前言微服务部署微服务多实例部署微服务容器化部署微服务Serverless部署微服务容器编排部署微服务架构模式微服务聚合模式微服务共享模式微服务代理模式微服务异步消息模式前言微服务部署微服务部署是微服务非常重要的环节下面详解4种常见的微服务部署案例微服务多实例部署微服务多实例部署是微服务架构中最基础、最常见的部署模式通过为每个微服务部署多个运行实例。如下图所示比如在一台服务器上部署了用户服务 (User Service) 的两个实例。实例1server:port:8081spring:application:name:user-service实例2server:port:8082spring:application:name:user-service每个微服务实例必须监听不同的网络端口以避免端口冲突。然而需要注意单台服务器的资源限制、和潜在的单点故障风险。比如单台服务器的 CPU、内存和网络资源是有限的运行过多的实例可能会导致资源竞争反而降低性能。对于生产环境中的关键微服务建议考虑跨多台服务器的分布式部署。微服务容器化部署微服务容器化部署是一种将每个微服务、及其所有依赖项打包到独立容器中的部署方法。如下图所示可以使用Docker(最流行的容器化平台)用于构建、打包、分发和运行容器。Docker 将微服务及其运行环境JDK、依赖库等打包成镜像。dockerbuild-tuser-service:1.0.无论部署在哪台服务器上都能保持行为一致。dockerrun-d-p8080:8080--name user-service user-service:1.0大大减少了“开发能跑、测试能跑、线上跑不了”的问题。真正做到一次构建到处运行Build once, run anywhere。微服务Serverless部署微服务 Serverless 部署是一种将服务部署、和运行责任交给云平台的现代架构方式。微服务 Serverless 部署带来了与传统容器化部署不同的价值它进一步抽象了基础设施管理让开发者更专注于业务逻辑。Serverless 平台比如 AWS Lambda…等等负责底层的基础设施管理。开发者无需关心这些运维细节可以将更多精力投入到业务代码的编写。Serverless 部署通常根据实际的请求量自动弹性伸缩无需预先配置或管理实例。只为实际执行的计算资源付费闲置时不产生费用可以显著降低成本尤其对于流量波动较大的服务。微服务容器编排部署除此之外还可以结合容器化、与自动化编排比如K8S等来部署。如下图所示1. 用户请求2. │3. ┌─▼──────┐4. │Ingress│⇽⇽Nginx入口控制器5. └─┬──────┘6. │7. ┌─▼────────────┐8. │Service(ClusterIP)│⇽⇽微服务的内部服务发现9. └─┬────────────┘10. │11. ┌─▼────────────┐12. │Pod多个副本│⇽⇽每个Pod运行1个微服务实例13. └──────────────┘Kubernetes 可以自动化微服务的部署、更新和回滚过程大大简化了发布流程。Kubernetes 可以在各种环境中部署包括公有云、私有云和混合云。Kubernetes 解决了大规模微服务部署、和管理中的诸多挑战。微服务架构模式微服务是大型架构的基石下面详解4大主流微服务架构方案微服务聚合模式微服务聚合设计模式解决了如何从多个微服务中聚合数据以便客户端可以获得所需的完整信息而不需要多次请求不同的服务。此类模式主要用于简化客户端的操作减少与多个微服务交互的复杂性。如下图所示通过构建一个聚合服务又称聚合层或聚合微服务将多个微服务的响应数据进行聚合形成一个统一的结果返回给客户端。聚合服务通过调用多个微服务的 API收集它们的响应并进行整合。优点简化客户端请求客户端只需调用聚合服务不需要直接与多个微服务交互。减少服务间依赖聚合服务可以减轻微服务之间的耦合度服务间可以独立变化。缺点聚合服务可能成为性能瓶颈需特别关注聚合服务的可扩展性。如果聚合的服务很多可能需要额外的处理来确保高效聚合。微服务共享模式微服务提倡的是每个服务拥有自己的独立数据库比如数据库独立性原则以确保服务之间的高内聚性、和低耦合性。然而在某些情况下由于业务需求或技术限制多个微服务可能需要共享数据。如下图所示实际上在微服务架构的初期阶段很多企业可能会采用 共享数据库 模式来简化系统的开发和维护尤其是在微服务迁移的过渡阶段。这样做虽然简化了架构但却违反了微服务的原则因为它导致了微服务之间的紧密耦合。因此“共享数据库”模式通常被视为“过渡性”或“反模式”不是长期推荐的设计。微服务代理模式微服务代理是一种中间层用于处理服务之间的通信。如下图所示在这种模式下代理服务充当了其他微服务的代理接收客户端的请求并将其转发给后端服务进行处理。在 Sidecar 代理模式 中Sidecar 是与每个微服务实例配对部署的。每个微服务实例旁边都有一个独立的代理进程这些代理共同组成一个统一的服务网格。代理负责捕获并管理服务的入站和出站流量。代理通常会与服务网格的 控制平面 交互获取流量路由、负载均衡、访问策略等配置。优点解耦客户端和微服务之间的交互通过代理服务来处理。统一入口所有请求都经过代理易于管理、监控和控制。缺点代理服务需要额外的资源来处理请求可能成为性能瓶颈。微服务异步消息模式异步消息设计模式在微服务架构中非常重要它允许微服务通过消息队列、事件流等方式进行松散耦合的通信。如下图所示微服务通过发布事件来通知其他服务发生了某个状态变化。事件通常是业务变化或数据变化的通知例如订单创建、支付成功…等。优点服务解耦服务之间不需要直接调用只有事件通知机制。提高吞吐量通过异步处理减少了服务的同步依赖。缺点事件的顺序和一致性需要额外考虑容易出现“事件丢失”或“消息重复消费”的问题。本文的引用仅限自我学习如有侵权请联系作者删除。参考知识微服务部署案例详解(4大部署案例)微服务架构方案详解(4大架构模式)