精华内容
下载资源
问答
  • 常见的微服务设计模式
    2017-12-01 14:03:07

    在微服务的设计方面,同样有许多的设计模式。单一架构是微服务架构的另一种选择。其他模式则处理相对应的问题。

    l  分解模式

      1)通过业务能力分解,

     2)通过子域来分解,

    l  数据库模式,每个服务拥有自己的数据库,以确保松散耦合。

    l  API网关模式,定义了客户端如何在微服务体系结构中访问服务。

    l  发现模式,客户端发现和服务器端发现,用于将客户端请求路由到微服务体系结构中的可用服务实例。

    l  通信模式,消息传递和远程过程调用模式是服务可以通信的两种不同的方式。

    l  部署模式,是每个主机部署单个服务,还是每个主机部署多个服务,是两种不同的部署策略。

    l  测试模式: 分为服务组件测试和服务集成契约测试

    l  UI模式: 分为服务器端页面组合模式与客户端UI组合模式

     

    还有很多,这些是感兴趣的,有时间研究一下。

    更多相关内容
  • 微服务架构模式.pdf

    2022-05-06 15:52:12
    微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构模式.pdf 微服务架构...
  • 因此,了解如何处理微服务架构(MSA)以及一些微服务设计模式,一个微服务架构的一些通用目标或者设计原则是很有价值的。下面是在微服务架构方案中值得考虑的四个目标。 缩减成本:MSA将会降低设计、实现和维护IT...
  • 微服务设计模式

    2022-03-14 18:20:12
    了解微服务架构的设计模式以克服其挑战。 微服务架构已成为现代应用程序开发的事实上的选择。虽然它解决了某些问题,但它不是灵丹妙药。它有几个缺点,在使用这种架构时,必须解决许多问题。这就需要学习这些问题...

    点击“终码一生”,关注,置顶公众号

    每日技术干货,第一时间送达!

    了解微服务架构的设计模式以克服其挑战。

    微服务架构已成为现代应用程序开发的事实上的选择。虽然它解决了某些问题,但它不是灵丹妙药。它有几个缺点,在使用这种架构时,必须解决许多问题。这就需要学习这些问题中的常见模式并用可重用的解决方案来解决它们。因此,需要讨论微服务的设计模式。在深入研究设计模式之前,我们需要了解微服务架构的构建原则:

    • 可扩展性

    • 可用性

    • 弹性

    • 独立、自主

    • 去中心化治理

    • 故障隔离

    • 自动配置

    应用所有这些原则会带来一些挑战和问题。让我们讨论这些问题及其解决方案。

    1、分解模式

    • 按业务能力分解

    问题

    微服务就是让服务松耦合,应用单一职责原则。然而,将应用程序分解成更小的部分必须在逻辑上完成。我们如何将应用程序分解为小服务?

    解决方案

    一种策略是按业务能力分解。业务能力是企业为了产生价值而做的事情。给定业务的功能集取决于业务类型。例如,保险公司的能力通常包括销售、营销、承保、索赔处理、计费、合规等。每个业务能力都可以被认为是一种服务,除了它是面向业务的而不是技术的。

    • 按子域分解

    问题

    使用业务能力分解一个应用程序可能是一个好的开始,但是你会遇到所谓的“上帝类”,它不容易分解。这些类将在多个服务中通用。比如Order类会用到Order Management、Order Takes、Order Delivery等,我们如何分解它们呢?

    解决方案

    对于“God Classes”问题,DDD(领域驱动设计)来拯救。它使用子域和有界上下文概念来解决这个问题。DDD 将为企业创建的整个域模型分解为子域。每个子域都有一个模型,该模型的范围称为有界上下文。每个微服务都将围绕有界上下文开发。

    注意:识别子域并非易事。这需要对业务的了解。与业务能力一样,通过分析业务及其组织结构并识别不同的专业领域来识别子域。

    • 扼杀者模式

    问题

    到目前为止,我们讨论的设计模式是为新建应用程序分解,但我们所做的工作中有 80% 是针对新建应用程序,它们是大型的单体应用程序。将上述所有设计模式应用于它们将是困难的,因为在实时使用的同时将它们分解成更小的部分是一项艰巨的任务。

    解决方案

    扼杀者模式来救援。Strangler 模式类似于藤蔓缠绕缠绕的树。此解决方案适用于来回调用的 Web 应用程序,并且对于每个 URI 调用,可以将服务分解为不同的域并作为单独的服务托管。这个想法是一次做一个域。这会创建两个独立的应用程序,它们并排存在于同一个 URI 空间中。最终,新重构的应用程序会“扼杀”或替换原始应用程序,直到您最终可以关闭单体应用程序。

    2、集成模式

    • API 网关模式

    问题

    当应用程序分解为更小的微服务时,需要解决一些问题:

    • 如何调用多个微服务抽象生产者信息。

    • 在不同的渠道(如桌面、移动和平板电脑)上,应用程序需要不同的数据来响应相同的后端服务,因为 UI 可能不同。

    • 不同的消费者可能需要来自可重用微服务的不同格式的响应。谁来做数据转换或字段操作?

    • 如何处理生产者微服务可能不支持的不同类型的协议。

    解决方案

    API 网关有助于解决微服务实现引起的许多问题,不仅限于上述问题。

    1. API 网关是任何微服务调用的单一入口点。

    2. 它可以作为代理服务将请求路由到相关的微服务,抽象生产者的详细信息。

    3. 它可以将请求扇出到多个服务并聚合结果以发送回消费者。

    4. 一刀切的 API 无法解决所有消费者的需求;这个解决方案可以为每种特定类型的客户端创建一个细粒度的 API。

    5. 它还可以将协议请求(例如 AMQP)转换为另一个协议(例如 HTTP),反之亦然,以便生产者和消费者可以处理它。

    6. 它还可以卸载微服务的身份验证/授权责任。

    • 聚合器模式

    问题

    我们已经讨论过解决 API 网关模式中的聚合数据问题。但是,我们将在这里整体地讨论它。将业务功能分解为几个较小的逻辑代码段时,有必要考虑如何协作每个服务返回的数据。这个责任不能留给消费者,因为它可能需要了解生产者应用程序的内部实现。

    解决方案

    聚合器模式有助于解决这个问题。它讨论了我们如何聚合来自不同服务的数据,然后将最终响应发送给消费者。这可以通过两种方式完成:

    1.复合微服务将调用所有需要的微服务,整合数据,并在发回之前转换数据。

    2. API Gateway还可以将请求划分为多个微服务,并在发送给消费者之前聚合数据。

    如果要应用任何业务逻辑,建议选择复合微服务。否则,API 网关是既定的解决方案。

    • 客户端 UI 组合模式

    问题

    当通过分解业务能力/子域来开发服务时,负责用户体验的服务必须从多个微服务中拉取数据。在单体世界中,曾经只有一次从 UI 调用后端服务来检索所有数据并刷新/提交 UI 页面。但是,现在情况将不一样了。我们需要了解如何去做。

    解决方案

    对于微服务,UI 必须设计为具有屏幕/页面的多个部分/区域的骨架。每个部分都会调用一个单独的后端微服务来提取数据。这称为组合特定于服务的 UI 组件。AngularJS 和 ReactJS 之类的框架有助于轻松做到这一点。这些屏幕称为单页应用程序 (SPA)。这使应用程序能够刷新屏幕的特定区域而不是整个页面。

    3、数据库模式

    • 每个服务的数据库

    问题

    存在如何为微服务定义数据库架构的问题。以下是需要解决的问题:

    1. 服务必须是松耦合的。它们可以独立开发、部署和扩展。

    2. 业务交易可以强制执行跨越多个服务的不变量。

    3. 一些业务事务需要查询多个服务拥有的数据。

    4. 数据库有时必须复制和分片才能扩展。

    5. 不同的服务有不同的数据存储要求。

    解决方案

    为了解决上述问题,必须为每个微服务设计一个数据库;它必须仅对该服务私有。它只能由微服务 API 访问。它不能被其他服务直接访问。例如,对于关系数据库,我们可以使用 private-tables-per-service、schema-per-service 或 database-server-per-service。每个微服务都应该有一个单独的数据库 ID,以便可以提供单独的访问权限来设置障碍并防止它使用其他服务表。

    • 每个服务共享数据库

    问题

    我们已经讨论过每个服务一个数据库是微服务的理想选择,但是当应用程序是未开发并使用 DDD 开发时,这是可能的。但是如果应用程序是一个单体应用程序并试图闯入微服务,那么非规范化就不是那么容易了。在这种情况下,合适的架构是什么?

    解决方案

    每个服务共享数据库并不理想,但这是上述场景的有效解决方案。大多数人认为这是微服务的反模式,但对于棕地应用程序,这是将应用程序分解为更小的逻辑部分的良好开端。这不适用于新建应用程序。在这种模式下,一个数据库可以与多个微服务对齐,但它必须限制在最多 2-3 个,否则扩展、自治和独立性将难以执行。

    • 命令查询职责分离 (CQRS)

    问题

    一旦我们实现了每个服务的数据库,就需要查询,这需要来自多个服务的联合数据——这是不可能的。那么,我们如何在微服务架构中实现查询呢?

    解决方案

    CQRS 建议将应用程序分成两部分——命令端和查询端。命令端处理创建、更新和删除请求。查询端使用物化视图处理查询部分。事件溯源模式通常与它一起用于为任何数据更改创建事件。通过订阅事件流来保持物化视图的更新。

    • Saga 模式

    问题

    当每个服务都有自己的数据库,一个业务事务跨越多个服务时,我们如何保证跨服务的数据一致性?例如,对于客户有信用额度的电子商务应用程序,该应用程序必须确保新订单不会超过客户的信用额度。由于订单和客户位于不同的数据库中,因此应用程序不能简单地使用本地 ACID 事务。

    解决方案

    一个 Saga 代表一个由多个子请求组成的高级业务流程,每个子请求都更新单个服务中的数据。每个请求都有一个在请求失败时执行的补偿请求。它可以通过两种方式实现:

    • 编排——当没有中央协调时,每个服务都会产生并监听另一个服务的事件,并决定是否应该采取行动。

    • 编排——编排器(对象)负责 saga 的决策制定和业务逻辑排序。

    4、可观察性模式

    • 日志聚合

    问题

    考虑一个应用程序由在多台机器上运行的多个服务实例组成的用例。请求通常跨越多个服务实例。每个服务实例都会生成一个标准化格式的日志文件。我们如何通过日志了解特定请求的应用程序行为?

    解决方案

    我们需要一个集中的日志服务来聚合来自每个服务实例的日志。用户可以搜索和分析日志。他们可以配置在日志中出现某些消息时触发的警报。例如,PCF 确实有 Loggeregator,它从 PCF 平台的每个组件(路由器、控制器、diego 等)以及应用程序中收集日志。AWS Cloud Watch 也这样做。

    • 性能指标

    问题

    当服务组合由于微服务架构而增加时,密切关注事务就变得至关重要,以便可以监控模式并在问题发生时发送警报。我们应该如何收集指标来监控应用程序性能?

    解决方案

    需要度量服务来收集有关各个操作的统计信息。它应该聚合提供报告和警报的应用程序服务的指标。聚合指标有两种模型:

    • Push — 服务将指标推送到指标服务,例如 NewRelic、AppDynamics

    • Pull — 指标服务从服务中提取指标,例如 Prometheus

    • 分布式跟踪

    问题

    在微服务架构中,请求通常跨越多个服务。每个服务通过跨多个服务执行一个或多个操作来处理请求。那么,我们如何端到端地跟踪请求来解决问题呢?

    解决方案

    我们需要一项服务

    1. 为每个外部请求分配一个唯一的外部请求 ID。

    2. 将外部请求 ID 传递给所有服务。

    3. 在所有日志消息中包含外部请求 ID。

    4. 记录有关在集中式服务中处理外部请求时执行的请求和操作的信息(例如开始时间、结束时间)。

    Spring Cloud Slueth 和 Zipkin 服务器是一个常见的实现。

    • 健康检查

    问题

    实现微服务架构后,服务可能会启动但无法处理事务。在这种情况下,您如何确保请求不会发送到那些失败的实例?使用负载平衡模式实现。

    解决方案

    每个服务都需要有一个端点,可用于检查应用程序的健康状况,例如/health. 此 API 应检查主机的状态、与其他服务/基础设施的连接以及任何特定逻辑。

    Spring Boot Actuator 确实实现了 /health 端点,并且还可以自定义实现。

    5、跨领域关注模式

    • 外部配置

    问题

    服务通常也会调用其他服务和数据库。对于 dev、QA、UAT、prod 等每个环境,端点 URL 或某些配置属性可能不同。任何这些属性的更改都可能需要重新构建和重新部署服务。我们如何避免因配置更改而修改代码?

    解决方案

    外部化所有配置,包括端点 URL 和凭据。应用程序应在启动时或运行时加载它们。

    Spring Cloud 配置服务器提供了将属性外部化到 GitHub 并将它们作为环境属性加载的选项。这些可以由应用程序在启动时访问,也可以在不重新启动服务器的情况下刷新。

    • 服务发现模式

    问题

    当微服务出现时,我们需要解决调用服务方面的一些问题:

    • 使用容器技术,IP 地址被动态分配给服务实例。每次地址更改时,消费者服务都可能中断并需要手动更改。

    • 每个服务 URL 都必须被消费者记住并紧密耦合。

    那么消费者或路由器如何知道所有可用的服务实例和位置呢?

    解决方案

    需要创建一个服务注册表来保存每个生产者服务的元数据。服务实例应在启动时注册到注册表,在关闭时应注销。消费者或路由器应该查询注册表并找出服务的位置。注册中心还需要对生产者服务进行健康检查,以确保只有服务的工作实例可以通过它使用。有两种类型的服务发现:客户端和服务器端。客户端发现的一个示例是 Netflix Eureka,而服务器端发现的一个示例是 AWS ALB。

    • 断路器模式

    问题

    一个服务一般会调用其他服务来获取数据,存在下游服务宕机的可能。这样做有两个问题:第一,请求会一直往down服务,耗尽网络资源,降低性能。其次,用户体验将是糟糕且不可预测的。我们如何避免级联服务故障并优雅地处理故障?

    解决方案

    消费者应该通过代理调用远程服务,该代理的行为类似于断路器。当连续失败的数量超过阈值时,断路器会跳闸,并且在超时期间,所有调用远程服务的尝试都将立即失败。超时到期后,断路器允许有限数量的测试请求通过。如果这些请求成功,断路器将恢复正常操作。否则,如果出现故障,超时时间将重新开始。

    Netflix Hystrix 是断路器模式的一个很好的实现。它还可以帮助您定义可在断路器跳闸时使用的回退机制。这提供了更好的用户体验。

    • 蓝绿部署模式

    问题

    使用微服务架构,一个应用程序可以拥有多个微服务。如果我们停止所有服务然后部署一个增强版本,停机时间将是巨大的,并可能影响业务。此外,回滚将是一场噩梦。我们如何避免或减少部署期间服务的停机时间?

    解决方案

    可以实施蓝绿部署策略以减少或消除停机时间。它通过运行两个相同的生产环境 Blue 和 Green 来实现这一点。假设绿色是现有的实时实例,蓝色是应用程序的新版本。在任何时候,只有一个环境是实时的,实时环境服务于所有生产流量。所有云平台都提供了实施蓝绿部署的选项。

    微服务架构还使用了许多其他模式,例如 Sidecar、链式微服务、分支微服务、事件溯源模式、持续交付模式等。随着我们在微服务方面获得更多经验,该列表不断增长。我现在停下来听取您关于您正在使用的微服务模式的回复。

    PS:防止找不到本篇文章,可以收藏点赞,方便翻阅查找哦

    展开全文
  • 本课程是对分布式微服务架构设计模式进行讲解,以亿级QPS的电商网站为例对常见的技术架构进行分析,从高性能,高可用的角度比较各种方案的优劣点,重点讲解使用CQRS模式怎么进行高性能的微服务架构设计,读者学习本...
  • 什么是微服务,用MartinFowler的一段话:没有一个明确的定义,但简单来说是,以一组小型服务来构建成应用,每个服务运行在单一独立的进程,不同服务间采用轻量级的交互机制来通信,例如HTTP(RESTAPI)。这些组成应用...
  • 在Monolithic模式中,各个组件间通常通过函数形式调用。但在微服务架构中,每个微服务通常有多个实例,每个实例具有不同的位置,而且实例会动态变化,比如在负载发生变化时服务会进行扩容或缩容,或者某个实例所在的...
  • 微服务六种设计模式

    千次阅读 2021-10-25 10:24:46
    聚合设计模式常用于报表服务,在微服务系统中报表服务是肯定存在的。 2、代理设计模式微服务架构中代理服务是必然存在的,常用的代理服务是网关服务。 微服务的各个服务是没有状态的,需要通过统一的...

    1、聚合设计模式

        聚合设计模式常用于报表服务,在微服务系统中报表服务是肯定存在的。

     

    2、代理设计模式

        在微服务架构中 代理服务 是必然存在的,常用的代理服务是 网关服务。

        微服务的各个服务是没有状态的,需要通过统一的入口(代理服务)经过权限的校验、请求的过滤(非法请求、SQL注入等),然后请求具体的服务。

     

    3、分支设计模式

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

    4、异步消息传递设计模式

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

     

    5、链式设计模式

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

     

    6、数据共享设计模式

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

        在这种情况下,部分微服务可能会共享缓存和数据库存储。不过,这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言,这是一种反模式。 

    展开全文
  • 本文来自于阿里云,由火龙果软件Anna编辑、推荐。 有很多进程间通信技术可供开发者选择。...另外,也可以使用异步的基于消息的通信机制,比如AMQP或STOMP。消息的格式也不尽相同。服务可以使用具备可读性的格式,比如...
  • 有详细的书签目录 Microservice Patterns : With examples in Java 克里斯-理查森(Chris Richardson)
  • 第1章描述了微服务架构的关键思想是如何进行功能分解。你可以将应用程序构建为一组服务,而不是开发一个大型的单体应用程序。一方面,将微服务架构描述为一种功能分解是有用的。但另一方面,它留下了几个未解决的...
  • 微服务设计模式,你用了几个

    千次阅读 2021-08-09 20:08:44
    1. 分解模式 a. 按业务能力分解 b. 按子域分解 c. 扼杀者模式 2. 集成模式 a. API 网关模式 b. 聚合器模式 c. 客户端组合模式 3. 数据库模式 a. 每个服务的数据库 b. 共享数据库 c. 命令查询职责分离 ...

    目录

    1. 分解模式

    a. 按业务能力分解

    b. 按子域分解

    c. 扼杀者模式

    2. 集成模式

    a. API 网关模式

    b. 聚合器模式

    c. 客户端组合模式

    3. 数据库模式

    a. 每个服务的数据库

    b. 共享数据库

    c. 命令查询职责分离 (CQRS)

    d. Saga模式

    4. 可观察性模式

    a. 日志聚合

    b. 性能指标

    c. 分布式追踪

    d. 健康检查

    5. 跨领域关注模式(Cross-Cutting Concern)

    a. 外部配置

    b. 服务发现模式

    c. 断路器模式

    d. 蓝绿部署模式


     微服务架构已经成为现代应用开发的主流选择。虽然它解决了某些问题,但它不是灵丹妙药,也有几个缺点。因此,我们需要讨论微服务的设计模式,帮助我们解决一些问题。

    在深入研究设计模式之前,我们需要了解微服务的构建原则

    1. 可扩展性
    2. 可用性
    3. 弹性
    4. 独立、自主
    5. 去中心化治理
    6. 故障隔离
    7. 自动配置
    8. 通过 DevOps 持续交付

    但是,应用所有这些原则会带来一些挑战和问题。接下来,让我们讨论这些问题及其解决方案。

    1. 分解模式

    a. 按业务能力分解

    问题

    微服务的目标之一是让服务松散耦合,应用单一职责原则。但是,将应用程序分解成更小的部分必须符合逻辑。我们如何将应用程序分解为小服务?

    解决方案

    一种策略是按业务能力分解----业务能力是企业为了创造价值而做的事情,给定业务的能力集取决于业务类型。例如,保险公司的能力通常包括销售、营销、承保、理赔处理、计费等。每个业务能力都可以被认为是一种服务。

    b. 按子域分解

    问题

    使用业务能力分解应用程序可能是一个好的开始,但你会遇到所谓的“上帝类(God Classes)”,它并不容易分解。这些类将在多个服务中通用。例如,Order 类将用于订单管理、接单、订单交付等,我们如何分解它们?

    备注:

    ”去除上帝类”是指把一个看似功能很强且很难维护的类,按照职责把自己的属性或方法分派到各自的类中或分解成功能明确的类,从而去掉上帝类。

    解决方案

    对于“God Classes”问题,可以通过DDD(领域驱动设计)来拯救。它使用子域和有界上下文概念来解决这个问题。DDD 将为企业创建的整个域模型分解为子域,每个子域都有一个模型,该模型的范围将称为有界上下文。每个微服务都将围绕有界上下文开发。

    注意:识别子域并非易事。它需要对业务的了解。与业务能力一样,子域是通过分析业务及其组织结构并确定不同的专业领域来确定的。

    c. 扼杀者模式

    问题

    到目前为止,我们讨论的设计模式是分解绿地应用程序(Greenfield),但我们所做的 80% 的工作是处理棕地应用程序(Brownfield),它们是大型的单体应用程序。将上述所有设计模式应用于它们将很困难,因为把它们分解成更小的部分是一项艰巨的任务。

    备注:

    绿地应用程序(Greenfield)

    即一个新项目,从头开始一个新的软件项目。类比是在绿地上施工,无需改造或拆除现有结构。

    (来自http://en.wikipedia.org/wiki/Greenfield_project

    棕地应用程序(Brownfield)

    Brownfield开发是IT行业中常用的术语,用于描述现有结构首先需要拆除的网站,即在现有软件项目中构建。

    (来自http://en.wikipedia.org/wiki/Brownfield_(software_development)

    解决方案

    这就需要扼杀者模式(Strangler)来拯救。

    扼杀者模式是基于一个藤蔓扼杀它所缠绕的树的类比。此解决方案适用于 Web 应用程序,可以将服务分解为不同的域并作为单独的服务托管。一次做一个域,这将创建两个独立的应用程序,它们并排在同一个 URI 空间中。最终,新重构的应用程序“扼杀”或替换原始应用程序,直到你最终可以放弃传统的单体应用程序。

    [澳大利亚]地区的自然奇观之一是巨大的扼杀者藤蔓。 他们在无花果树的树枝上播种,并逐渐沿着树下工作,直到扎根在土壤中。 多年来,它们长成奇妙而美丽的形状,同时勒死并杀死了作为寄主的树。

    2. 集成模式

    a. API 网关模式

    问题

    当应用程序分解为较小的微服务时,需要解决一些问题:

    1. 如何调用多个微服务。
    2. 在不同的终端设备(如PC、APP和Pad)上,因为 UI 不同,应用程序需要后端服务的不同数据。
    3. 不同的消费者可能需要不同格式的响应数据。谁将进行数据转换?
    4. 如何处理不同类型的协议。

    解决方案

    API 网关有助于解决微服务带来的许多问题:

    1. API 网关是任何微服务调用的单一入口点。
    2. 它可以作为代理服务将请求路由到相关的微服务。
    3. 它可以将请求发送到多个服务并汇总结果以发回给请求者。
    4. 一刀切的 API 无法解决消费者的所有需求;此解决方案可以为每种特定类型的客户端创建细粒度的 API。
    5. 它还可以将请求协议(例如 AMQP)转换为另一种协议(例如 HTTP),反之亦然。
    6. 它还可以对不同的微服务,建立统一的身份验证/授权。

    b. 聚合器模式

    问题

    我们已经讨论了解决 API 网关模式中的聚合数据问题。但是,我们将在这里全面讨论它。当将业务功能分解为几个较小的代码段时,有必要考虑如何聚合每个服务返回的数据。这个责任不能留给消费者,因为它可能需要了解生产者的内部实现。

    解决方案

    聚合器模式有助于解决这个问题。它可以聚合来自不同服务的数据,然后再发送给消费者。这可以通过两种方式完成:

    1. 复合微服务:将调用所有需要的微服务,合并数据,并在应答之前转换数据。
    1. API 网关: 还可以将请求划分为多个微服务,并在将数据发送给消费者之前聚合数据。

    如果还要处理业务逻辑,建议选择复合微服务。

    c. 客户端组合模式

    问题

    当通过分解业务能力/子域来开发服务时,客户端必须从多个微服务中拉取数据。在单体世界中,客户端一般只需要调用一次后端服务来查询或刷新所有数据。然而,现在情况将不一样了,我们需要了解如何去做。

    解决方案

    对于微服务,客户端可能需要设计为具有多个部分/区域的骨架。每个部分都会调用一个单独的后端微服务来拉取数据。这称为单页应用程序 (Single Page Applications,SPA),像 AngularJS 和 ReactJS 这样的框架有助于轻松地做到这一点。在需要刷新时,应用程序能够刷特定区域而不是整个页面。

    3. 数据库模式

    a. 每个服务的数据库

    问题

    如何定义微服务的数据库架构也是一个问题:

    1. 服务必须是松耦合的。它们可以独立开发、部署和扩展。
    1. 业务请求处理可能会跨越多个服务。
    1. 一些事务需要查询多个服务拥有的数据。
    1. 数据库有时必须被复制和分片才能扩展。
    1. 不同的服务有不同的数据存储要求。

    解决方案

    为了解决上述问题,每个微服务必须设计一个数据库,它必须仅供该服务专用。它也应该只能通过微服务 API 访问,而不能被其他服务直接访问。例如,对于关系数据库,我们可以使用 private-tables-per-service、schema-per-service 或 database-server-per-service。每个微服务都应该有一个单独的数据库 id,以便可以给予单独的访问权限,并防止它使用其他服务表。

    备注:

    Private-tables-per-service——每一服务拥有一系列只能被该服务访问的表

    Schema-per-service——每一服务拥有一个为该服务所私有的数据库Schema

    Database-server-per-service——每一服务拥有自己的数据库

    b. 共享数据库

    问题

    每个服务一个数据库是微服务的理想选择。当应用程序是全新的并且要使用 DDD 开发时,这是可能的。但是,如果应用程序是单体应用程序并试图改进为微服务架构,那么就不是那么容易了。在这种情况下,合适的架构是什么?

    解决方案

    共享数据库并不理想,但这是上述场景的解决方案。大多数人认为这是微服务的反模式,但对于棕地应用程序,这是将应用程序分解为更小部分的良好开端。在这种模式中,一个数据库可以供多个微服务调用,但最多只能限制在 2-3 个,否则扩展性、自治性和独立性将难以执行。

    c. 命令查询职责分离 (CQRS)

    问题

    一旦我们实现了每个服务的数据库,就需要查询。那么,对于来自多个服务的联合数据,我们如何在微服务架构中实现查询呢?

    解决方案

    CQRS 建议将应用程序分成两部分——命令端和查询端。

    CQRS 将系统中的操作分为两类,即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称,即我们常说的新增,更新,删除这些操作,都是命令。而查询则和字面意思一样,即不会对数据产生变化的操作,只是按照某些条件查找数据。

    查询端使用物化视图处理查询部分。视图会被保存在订阅了事件的服务中,每个服务在更新数据时会发布出这些事件。例如,网店可以通过维护一个客户信息和订单信息的Join视图来查询特定区域客户和他们的近期订单。该视图由订阅了客户信息事件和订单信息事件的服务进行更新。

    d. Saga模式

    问题

    当每个服务都有自己的数据库,一个请求事务跨越多个服务时,我们如何保证跨服务的数据一致性呢?例如,对于电子商务应用程序,应用程序必须确保新订单不会超过客户的信用额度。由于 Orders 和 Customers 位于不同的数据库中,因此应用程序不能简单地使用本地 ACID 事务。

    解决方案

    Saga 代表一个高级业务流程,它由多个子请求组成,每个子请求都更新单个服务中的数据。每个请求都有一个补偿请求,在请求失败时执行。

    它可以通过两种方式实现:

    1. 事件编排 (Event Choreography):没有中央协调器(没有单点风险)时,每个服务产生并观察其他服务的事件,并决定是否应采取行动。
    2. 命令协调(Order Orchestrator):中央协调器负责集中处理事件的决策和业务逻辑排序。。

    4. 可观察性模式

    a. 日志聚合

    问题

    考虑一个用例,其中应用程序由在多台机器上运行的多个服务实例组成。请求通常跨越多个服务实例,每个服务实例都会生成一个标准化格式的日志文件,我们如何通过日志了解特定请求的应用程序行为?

    解决方案

    我们需要一个集中的日志服务来聚合来自每个服务实例的日志。用户可以搜索和分析日志,还可以在日志中配置出现某些消息时触发的警报。例如,PCF 确实有 Loggeregator,它从 PCF 平台的每个组件(路由器、控制器、diego 等)以及应用程序收集日志。AWS Cloud Watch 也有同样的作用。

    b. 性能指标

    问题

    当服务数量不断增加时,密切关注应用性能变得至关重要,以便可以出现问题时发送警报。我们应该如何收集指标来监控应用程序性能?

    解决方案

    需要度量服务来收集有关单个操作的统计信息。有两种聚合指标的模型:

    • Push — 服务将指标推送到指标服务,例如 NewRelic、AppDynamics、Prometheus
    • Pull — 指标服务从服务中提取指标,例如 Prometheus

    c. 分布式追踪

    问题

    在微服务架构中,请求通常跨越多个服务。那么,我们如何跟踪一个请求来排查问题呢?

    解决方案

    我们需要一项服务

    • 为每个外部请求分配一个唯一的外部请求 ID。
    • 将外部请求 ID 传递给所有服务。
    • 在所有日志消息中包含外部请求 ID。
    • 集中式记录和处理外部请求执行时操作的信息。

    Spring Cloud Slueth 和 Zipkin 服务器是一类常见的实现。

    d. 健康检查

    问题

    实施微服务架构后,有可能遇到服务已启动但无法处理请求的问题。在这种情况下,你如何确保请求不会发送到那些失败的实例?

    解决方案

    每个服务都需要有一个端点,可用于检查应用程序的健康状况,例如 /health, 此 API 应检查主机的状态、与其他服务/基础设施的连接以及任何特定逻辑。

    Spring Boot Actuator 实现了一个/health 端点,并且该实现也可以自定义。

    5. 跨领域关注模式(Cross-Cutting Concern)

    cross-cutting concerns”指的是两个非常不一样的组件存在一些类似的功能。

    a. 外部配置

    问题

    服务通常也调用其他服务和数据库。对于每个环境,如 dev、QA、UAT、prod,某些配置属性可能不同。任何这些属性的更改都可能需要重新构建和重新部署服务。我们如何避免因配置更改而修改代码?

    解决方案

    外部化所有配置,包括凭据。应用程序应在启动时动态加载它们。

    Spring Cloud 配置服务器提供了将属性外部化到 GitHub 并将它们作为环境属性加载的选项。这些可以在启动时由应用程序访问,也可以在不重新启动服务器的情况下刷新。

    b. 服务发现模式

    问题

    当微服务出现后,我们需要解决服务调用方面的几个问题:

    1. 使用容器技术,IP 地址被动态分配给服务实例。每次地址更改时,消费者服务都可能中断并需要手动更改。
    2. 每个服务 URL 都必须被消费者记住并紧密耦合。

    那么消费者或路由器如何知道所有可用的服务实例和位置呢?

    解决方案

    需要创建一个服务注册中心来保存每个生产者服务的元数据。服务实例应在启动时注册到注册表,并在停止时取消注册。消费者或路由器应查询注册表并找出服务的位置。注册中心还需要对生产者服务进行健康检查,以确保只有服务的工作实例可供通过它使用。有两种类型的服务发现:客户端和服务器端。

    服务发现(客户端)的一个例子是 Netflix Eureka,服务发现(服务器端)的一个例子是 AWS ALB。

    c. 断路器模式

    问题

    一个服务一般会调用其他服务来查询数据,但下游服务有可能宕机。这样做有两个问题:第一,请求会一直到宕机的服务,耗尽网络资源,降低性能。其次,用户体验会很差且不可预测。我们如何避免级联服务故障并优雅地处理故障呢?

    解决方案

    消费者应该通过代理调用远程服务,该代理的行为方式与电路断路器类似。当连续失败次数超过阈值时,断路器跳闸,并且在超时期限内,所有调用远程服务的尝试都将立即失败。超时到期后,断路器允许有限数量的测试请求通过。如果这些请求成功,断路器将恢复正常操作。否则,如果出现故障,超时时间将重新开始。

    Netflix Hystrix 是断路器模式的一个很好的实现。它还可以在断路器跳闸时使用回退机制。这提供了更好的用户体验。

    d. 蓝绿部署模式

    问题

    使用微服务架构,一个应用可以有多个微服务。如果我们停止所有服务,然后部署新版本,停机时间将会非常长,并且会影响业务。此外,回滚将是一场噩梦。我们如何避免或减少部署期间服务的停机时间?

    解决方案

    可以实施蓝绿部署策略以减少或消除停机时间。它通过运行两个相同的生产环境 Blue 和 Green 来实现这一点。让我们假设 Green 是现有的实时实例,而 Blue 是应用程序的新版本。在任何时候,只有一个环境处于活动状态,实时环境服务于所有生产流量。几乎所有云平台都提供了实施蓝绿部署的选项。

    还有许多其他与微服务架构一起使用的模式,如 Sidecar、链式微服务、分支微服务、事件溯源模式、持续交付模式等。如果你还知道其他的微服务模式,欢迎留言交流。

    参考链接: https://dzone.com/articles/design-patterns-for-microservices

    展开全文
  • 本文将介绍微服务架构设计中的设计模式、原则及最佳实践。我们将使用适当的架构设计模式和技术。通过本文,你将了解到如何从单体架构一步步演进到事件驱动的微服务架构,如何利用微服务分布式架构设计一个高可用、...
  • 微服务设计模式

    千次阅读 2019-08-29 19:12:28
    设计模式概览 服务设计模式 BFF BFF BFF(Backend for Frontend)也称聚合层或者适配层,上述架构从外到内依次为 端用户体验层->网关层->BFF层->微服务层,主要是讲内部复杂的微服务,适配成对各种...
  • 六种微服务架构的设计模式.pdf
  • 微服务架构设计.7z

    2019-08-05 10:43:08
    PPT主题是:微服务 主要从:1.什么是微服务 2....微服务架构的设计模式 4.springcloud介绍 5.Spring Cloud常见微服务公共组件 以上几个方面进行详细的介绍,适用于企业讲座讲解、自学、学校组会讲解等多种场合。
  • 微服务架构设计模式 pdf

    万次阅读 多人点赞 2020-09-14 10:30:41
    链接:https://pan.baidu.com/s/1RCsi9bDoPgQw0swztzsmBQ 提取码:jhie 若链接失效,请联系本人:18642984053@163.com
  • 微服务与传统单体服务 单体服务 一个项目中包含了所有的服务叫做单体服务 优点: 开发简单,对技术栈要求不高 部署、运维方便,只需要对一台机器、一个服务进行部署、运维 服务监控、问题排查简单,只需要对一台...
  • 文档:概要设计文档,可以帮我们处理程序性能瓶颈,程序移植性短板,也方便后期维护拓展,文档输出也方便后期交付和...7.3 设计模式 7.4 单元测试 8 可扩展设计 9 可靠性设计 9.1 故障隔离和自愈 9.2 数据可靠性
  • 微服务架构及设计模式.docx
  • - 微服务架构介绍 -微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看...
  • 微服务架构设计,软件快速发展的时代、软件规模化给团队带来的挑战,如何用微服务解决难题
  • 架构的关键是什么?架构就是取舍,进而架构师就是做出取舍的人。大家都认同,做架构的人的特征之一应该是“Independent”(独立),这也是我选择做独立解决方案进而设计产品的重要原因。...笔者推荐大家阅读这份微服务...
  • 11.DDD与微服务设计模式笔记

    千次阅读 2020-03-29 00:20:00
    --------------------------------------------------------------------------------- 单体架构到位服务 软件生命周期与架构演化 微服务立方体 ...微服务横向扩展划分——共享核心功能模式 ...
  • 聚合设计模式常用于报表服务,在微服务系统中报表服务是肯定存在的。 2、代理设计模式微服务架构中 代理服务 是必然存在的,常用的代理服务是 网关服务。 微服务的各个服务是没有状态的,需要通过统一的入口...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 92,742
精华内容 37,096
热门标签
关键字:

常见的微服务设计模式