高端的镇江网站建设,阿克苏市建设银行网站,小程序开发费用是多少,软件发展的四个阶段微服务架构设计的概念 微服务架构#xff08;Microservices Architecture#xff09;是一种用于构建分布式系统的软件设计模式。它将大型应用程序拆分成一组小型、自治的服务#xff0c;每个服务都运行在其独立的进程中#xff0c;服务之间通过轻量级的通信机制#xff08…微服务架构设计的概念 微服务架构Microservices Architecture是一种用于构建分布式系统的软件设计模式。它将大型应用程序拆分成一组小型、自治的服务每个服务都运行在其独立的进程中服务之间通过轻量级的通信机制如HTTP REST API进行交互。这种架构模式具有高度的可伸缩性、可重用性、可维护性和可测试性特别适用于构建大规模、高并发、复杂的应用系统。
微服务架构设计的常见10种设计模式 虽然直接列出并详细阐述10种微服务设计模式并达到4000字的要求较为困难但我可以概述几种常见的微服务设计模式包括它们的描述、优缺点、实现方式、可用技术示例以及使用场景。
1. 独享数据库Database per Microservice
描述 当一家公司将大型单体系统替换成一组微服务首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益但它却是反模式的特别是在大规模系统中微服务将在数据库层严重耦合整个迁移到微服务的目标都将面临失败例如团队授权、独立开发等问题。 更好的方法是为每个微服务提供自己的数据存储这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离也就是说微服务可以共享物理数据库但应该使用分开的数据结构、集合或者表这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。 优缺点
优点服务间数据隔离清晰减少数据冲突和依赖每个服务可以独立选择最适合其业务需求的数据库技术。缺点跨服务的数据一致性管理复杂分布式事务处理困难数据冗余和同步问题。
实现方式 每个微服务在启动时配置自己的数据库连接信息并通过ORM对象关系映射框架或数据访问层DAO与数据库进行交互。
可用技术示例 MySQL、MongoDB、Cassandra等数据库系统以及Spring Data JPA、MyBatis等ORM框架。
使用场景 适用于业务复杂度高、数据模型差异大、需要高度自治的微服务系统。
2. 聚合器Aggregator
描述 聚合器模式是一种将多个微服务的响应聚合起来以形成一个统一的响应返回给客户端的设计模式。这种模式常用于构建复杂的业务场景其中客户端需要的数据分散在多个微服务中。 为了尽量减少服务之间的通信我们可以使用服务聚合模式。基本上服务聚合设计模式是接收来自客户端或 API 网关的请求然后分配给内部多个后端微服务再将结果合并并在一个响应结构中发给请求发起人。 通过实现服务聚合模式可以减少客户端和微服务之间的通信量和通信开销 服务聚合模式 微服务通信设计模式------服务聚合模式设计 优缺点
优点提高系统的灵活性和可扩展性减少客户端的调用次数和复杂度。缺点聚合器可能成为性能瓶颈增加了系统的复杂性和维护成本。
实现方式 聚合器微服务通过同步或异步方式调用其他微服务并将结果聚合后返回给客户端。
可用技术示例 Spring Cloud Gateway、Zuul等API网关以及Spring Boot、Node.js等后端技术栈。
使用场景 适用于需要跨多个微服务获取数据并展示给用户的场景如电商平台的商品详情页。
3. 链式Chain 描述 链式模式是指微服务之间按照特定的顺序进行调用形成一条服务调用链。每个服务在接收到请求后处理部分业务逻辑并将请求传递给链中的下一个服务。 优缺点
优点实现服务间的松耦合提高系统的灵活性和可维护性。缺点调用链过长可能导致性能问题服务间的依赖关系复杂。
实现方式 通过HTTP请求或消息队列等方式实现服务间的顺序调用。
可用技术示例 Spring Cloud OpenFeign、Apache Dubbo等RPC框架以及RabbitMQ、Kafka等消息队列。
使用场景 适用于业务流程具有明确顺序和依赖关系的场景如订单处理流程。
4. 命令和查询职责分离CQRS
描述 如果我们使用事件源那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。 这种情况我们可以使用 CQRS 模式。在该模式中系统的数据修改部分命令与数据读取部分查询是分离的。而 CQRS 模式有两种容易令人混淆的模式分别是简单的和高级的。 其简单形式中不同实体或 ORM 模型被用于读写操作如下所示 它有助于强化单一职责原则和分离关注点从而实现更简洁的设计。 在其高级形式中会有不同的数据存储用于读写操作。高级的 CQRS 通常结合事件源模式。根据不同情况会使用不同类型的写数据存储和读数据存储。写数据存储是“记录的系统”也就是整个系统的核心源头。 对于读频繁的应用程序或微服务架构OLTP 数据库任何提供 ACID 事务保证的关系或非关系数据库或分布式消息系统都可以被用作写存储。对于写频繁的应用程序写操作高可伸缩性和大吞吐量需要使用写可水平伸缩的数据库如全球托管的公共云数据库。标准化的数据则保存在写数据存储中。 对搜索例如 Apache Solr、Elasticsearch或读操作KV 数据库、文档数据库进行优化的非关系数据库常被用作读存储。许多情况会在需要 SQL 查询的地方使用读可伸缩的关系数据库。非标准化和特殊优化过的数据则保存在读存储中。 数据是从写存储异步复制到读存储中的所以读存储和写存储之间会有延迟但最终是一致的。 微服务架构及其最重要的10个设计模式 原文链接 https://www.infoq.cn/article/kdw69bdimlx6fsgz1bg3
优缺点 优点 在事件驱动的微服务中数据读取速度更快。 数据的高可用性。 读写系统可独立扩展。
缺点 读数据存储是弱一致性的最终一致性。 整个系统的复杂性增加了混乱的 CQRS 会显着危害整个项目。
可用技术示例
写存储 EventStoreDB Apache Kafka Confluent Cloud AWS Kinesis Azure Event Hub GCP Pub/Sub Azure Cosmos DB MongoDB Cassandra. Amazon DynamoDB
读存储Elastic Search Solr Cloud Spanner Amazon Aurora Azure Cosmos DB Neo4j
框架Lagom Akka Spring akkatecture Axon Eventuate
使用场景 在高可扩展的微服务架构中使用事件源。 在复杂领域模型中读操作需要同时查询多个数据存储。 在读写操作负载差异明显的系统中。
5. 异步消息传递Asynchronous Messaging
描述 同步调用模式在调用的过程中会阻塞线程如果服务提供方迟迟没有返回则服务消费方会一直阻塞严重的会撑满服务的线程池出现雪崩效应。因此在构建服务架构系统时通常会梳理核心系统的最小化服务集合这些核心的系统服务使用同步调用。而其他核心链路以外的服务可以使用异步消息队列进行异步化 优缺点
优点提高系统的可靠性和可扩展性减少服务间的直接依赖。缺点增加了系统的复杂性和维护成本消息的一致性和顺序性管理困难。
实现方式 使用RabbitMQ、Kafka等消息队列产品。
可用技术示例 RabbitMQ、Kafka、ActiveMQ等。
使用场景 适用于对实时性要求不高但需要高可靠性和可扩展性的场景如订单处理、日志收集等。在这些场景中服务之间的调用不必立即响应可以通过消息队列进行异步处理从而提高系统的整体性能和稳定性。
6. 事件驱动Event-Driven
描述 事件驱动模式通过事件来触发服务之间的交互。当一个微服务发生特定事件时它会发布该事件到事件总线或消息队列中其他微服务可以订阅这些事件并在事件发生时进行相应的处理。 优缺点
优点实现服务间的松耦合提高系统的可扩展性和灵活性。缺点事件处理的一致性和顺序性管理困难系统复杂度增加。
实现方式 使用事件总线如Apache Kafka、RabbitMQ等或分布式消息系统来实现事件的发布和订阅。
可用技术示例 Apache Kafka、RabbitMQ、Azure Event Grid等。
使用场景 适用于需要高度解耦、实时性要求不高的场景如订单状态变更通知、用户行为跟踪等。
7. 服务发现Service Discovery
描述 服务发现模式允许微服务在运行时自动发现其他服务的地址和端口信息从而实现服务的自动注册和发现。这有助于实现服务的动态扩展和容错。
优缺点
优点提高系统的灵活性和可扩展性减少服务间的硬编码依赖。缺点服务注册和发现的复杂性和开销。
实现方式 使用服务注册中心如Eureka、Consul、Zookeeper等来管理服务的注册和发现。
可用技术示例 Eureka、Consul、Zookeeper等。
使用场景 适用于需要动态扩展和容错能力的微服务系统特别是在云环境或容器化部署中。
8. Saga
描述 如果微服务使用独享数据库那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议因为它要么不可伸缩关系数据库要么不被支持多数非关系数据库。 但您还是可以在微服务架构中使用 Saga 模式实现分布式事务。Saga 是 1987 年开发的一种古老模式是关系数据库中关于大事务的一个替代概念。但这种模式的一种现代变种对分布式事务也非常有效。Saga 模式是一个本地事务序列其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga 中的首个事务是由外部请求事件或动作初始化的一旦本地事务完成数据已保存在数据存储且消息或事件已发布那么发布的消息或事件则会触发 Saga 中的下一个本地事务。 优缺点
优点 为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务。 为使用了不支持 2PC 的非关系数据库的微服务架构提供一致性事务
缺点 需要处理瞬时故障并且提供等幂性。 难以调试而且复杂性随着微服务数量增加而增加。
实现方式 使用熔断器库如Netflix的Hystrix、Resilience4j等来实现熔断逻辑。
可用技术示例 Axon Eventuate Narayana
使用场景 在使用了事件源的高可伸缩、松耦合的微服务中。 在使用了分布式非关系数据库的系统中。
9. 缓存Caching
描述 缓存模式通过在服务之间添加缓存层来减少对底层数据源的访问频率从而提高系统的响应速度和吞吐量。
优缺点
优点提高系统的响应速度和吞吐量减少对底层数据源的访问压力。缺点数据一致性问题缓存击穿和雪崩问题。
实现方式 使用缓存中间件如Redis、Memcached等来实现缓存逻辑。
可用技术示例 Redis、Memcached等。
使用场景 适用于读多写少、数据更新频率不高的场景如商品信息、用户信息等。
10.边车模式Sidecar Pattern
描述 边车模式Sidecar Pattern是一种在微服务架构中常见的模式它通过将辅助性质的服务通常被称为sidecar与主要的服务实例部署在一起以提供额外的功能、能力或支持。边车模式的设计思想是将控制和逻辑分离使得主要服务实例可以更专注于其核心业务逻辑而边车则负责处理如日志记录、监控、安全性、通信等辅助功能。这种设计模式允许主服务更加单一职责便于维护和升级同时也提高了系统的灵活性和可扩展性。 优点
解耦与模块化将服务治理功能从业务逻辑中分离出来实现了关注点的分离和模块化使得业务逻辑更加清晰和简洁同时治理功能也更加可重用和灵活。可扩展性允许对治理功能进行独立的扩展和升级而不需要修改业务逻辑代码提高了系统的可扩展性。多语言支持对业务逻辑的代码侵入性较小支持多种编程语言和技术栈使得在混合语言环境中进行微服务治理变得更加容易。灵活性可以灵活地添加或移除治理功能以满足不同业务场景的需求降低了维护成本。
缺点
复杂性增加引入边车模式会增加系统的复杂性需要额外管理和维护边车进程增加了开发和运维的工作量。资源消耗每个微服务实例都需要一个边车进程可能会导致资源如CPU、内存等的消耗增加在资源受限的环境中可能成为一个问题。网络延迟边车进程需要与微服务实例进行通信可能会增加网络延迟尽管可以通过优化网络配置来降低延迟。
实现方式 边车模式的实现通常涉及使用特定的技术或工具这些工具可以作为辅助性质的服务与主服务实例一起部署。常见的实现方式包括
使用容器化技术如Docker容器将边车服务作为独立的容器与主服务容器部署在同一个Pod中在Kubernetes等容器编排系统中。部署代理如Envoy、Linkerd等高性能的代理和通信总线负责处理服务之间的网络通信、负载均衡、故障恢复等任务。
可用技术示例 Istio一个开源的服务网格框架通过在应用程序的每个服务实例旁边部署一个Envoy Sidecar来实现边车模式提供了流量管理、安全性、可观察性等功能。Linkerd由Buoyant公司开源的服务网格实现通过在每个服务实例旁边部署一个Linkerd Proxy来实现边车模式提供了负载均衡、故障注入、监控和可观察性等功能。Consul ConnectHashiCorp公司的Consul服务发现和配置管理工具的一部分通过在每个服务实例旁边运行一个代理来实现边车模式提供安全的服务到服务通信功能。NGINX虽然主要作为Web服务器和反向代理服务器使用但也可以作为Sidecar部署在每个服务实例旁边通过配置NGINX作为反向代理实现负载均衡、安全性和其他网络功能。
使用场景
老系统的改造和扩展对于已有的复杂系统边车模式可以帮助逐步引入微服务治理功能而不需要对整个系统进行重构。多语言环境在由多种语言构建的微服务系统中边车模式可以提供一种统一的服务治理方式降低跨语言集成的难度。控制和逻辑分离当需要将服务治理逻辑与业务逻辑分离时边车模式是一个很好的选择有助于降低代码的耦合度提高系统的可维护性。微服务治理包括服务注册、发现、负载均衡、熔断、限流等功能边车模式可以很容易地集成这些服务治理功能而无需修改主服务的代码。监控和日志记录通过将监控和日志记录功能封装在边车中可以实现对所有服务实例的统一监控和日志记录便于快速定位问题和优化系统性能。安全性和认证授权边车可以处理所有的网络通信并应用适当的安全协议来保护服务间的通信确保数据传输的安全性和授权服务的相互通信。
上面是对微服务架构设计中常见设计模式的简要介绍每种模式都有其独特的优缺点、实现方式和使用场景。在实际应用中开发者需要根据项目的具体需求和约束条件来选择合适的设计模式并结合其他最佳实践来构建高质量的微服务系统。
