微服务设计模式

《微服务设计模式》由会员分享，可在线阅读，更多相关《微服务设计模式（13页珍藏版）》请在金锄头文库上搜索。

1、微服务架构已经成为现代应用程序开发的主流。虽然说它能够解决某 些问题，但却也不是万金油。而我们在使用这个体系架构时，还有许 多的问题要我们解决。这就需要学习这些问题的通用模式，并通过可 复用的解决方案来解决问题。因此，有必要讨论微服务的设计模式。 但是在深入研究设计模式之前，我们还需了解微服务架构的构建原 理：1、可拓展性2、可用性3、弹性4、独立自主5、分散治理6、故障隔离7、自动配置8、通过 DevOps 持续交付应用这些构建原理会带来一些挑战和问题。让我们讨论这些问题及其 解决方案。分解模式按业务能力分解问题：微服务就是让应用服务松散耦合，但是将应用程序分解成较小的部分 还必须要在逻辑上

2、实现。那我们如何将应用程序分解为小型服务呢？ 解决方案： 一种策略就是按业务能力分解，业务能力是企业业务价值的体现。业 务的功能取决于业务的类型。例如，保险公司的业务能力通常包括销 售，市场营销，承保，理赔处理，开票，合规性等。每种业务能力都 可以视为一种服务，但它面向的是业务而不是技术。按子域划分问题： 按业务功能来分解应用程序或许是个不错的思路。但是我们可能会遇 到某些比较难以分解出来的类(God Classes)，这种类在多种服务 中通用。比如，订单类用于“订单管理”，“接单”，“订单交付” 等业务中。那我们该如何来分解呢？解决方案：对于这种难以分解出来的(God Classes)类，使

3、用DDD (即领域驱 动设计)可以解决。它使用子域和有界上下文概念来解决此问题。DDD 将为企业创建的整个域模型分解为子域。每个子域都有一个模型，该 模型的范围称为有界上下文。每个微服务将围绕有界的上下文进行开 发。注意：确定子域并不是件容易的事，这需要对业务有一定的了解。像 业务功能一样，通过分析业务及其组织结构并确定不同的专业领域来 标识子域。扼杀者模式问题：到目前为止，我们所讨论的设计模式都是分解未开发的应用程序，但是我们所做的工作中有80%是用于已开发的应用程序(brownfield applica tions )中，这是个大型的整体应用程序。上述所有设计模式 并不是适用于它们，因为把

4、它们作为一个整体应用的同时将它们拆分 成一个个较小的部分是一项艰巨的任务。解决方案： 扼杀者模式可以解决此类问题。扼杀者模式是以缠绕类的藤蔓植物作 为类比。该解决方案是与Web应用程序配合使用，在Web应用程序之 间来回调用，对于每个URL的调用，一个服务可以分为不同的域并作 为单独的服务托管。这个想法是一次做一个域，这将会创建两个单独 的应用程序，它们并行存在于同一个URL空间中。最终，新重构的应 用程序会“扼杀”或者替换原来的应用程序，直到最后可以停止整个 应用程序。整合模式API网关模式问题：1、当一个应用程序被分解为多个微服务时，还有一些问题需要解决：2、如何调用多个微服务来抽象化生产

5、者信息。3、在不同设备上(比如台式机，移动设备和平板电脑)，由于 UI 可能存在不同，应用程序需要不同的数据来响应相同的后端 服务。4、不同的使用者对于可重复使用的微服务响应格式可能不同， 那由谁来进行数据转换或者字段操作。5、生产者微服务可能不支持某些类型协议的处理方式。解决方案：1、API 网关有助于解决因微服务实现而引起的许多问题，而不仅限 于上述问题。2、API 网关是任务微服务调用的单一入口点。3、用作代理服务，将请求路由至相关的微服务，从而抽象出生 产者的详细信息。4、将一个请求发送至多个服务，然后把响应结果聚合后发送回 消费者。5、通用的 API 网关无法满足所有的消费者需求。可

6、以为每种特 定类型的客户端创建细粒度的 API 。6、将协议请求（例如AMQP ）专换成另外一个协议（例如HTTP ） 反之亦然，以便生产者和消费者处理它。7、它还可以减轻微服务的身份验证 /授权责任。聚合模式问题：我们已经讨论过如何解决API网关模式中的聚合数据问题。但是，接下来我们将会更加全面地讨论它。比如，在将业务功能分解为几个较 小的逻辑代码时，有必要考虑聚合每个服务返回的数据。这个任务不 能留给消费者，因为如果这么做消费者可能需要了解生产者应用程序 的内部实现。解决方案：聚合模式有助于解决此类问题。它讨论了关于如何聚合来自不同服务 的数据，然后将最终响应结果发送给消费者。我们可以通过

7、以下两种 方式来实现：1、复合微服务将调用所有必需的微服务，整合数据，并在回退 数据之前转换数据。2、用 API 网关将请求划分为多个微服务并聚合数据，然后再将 其发送给使用者。3、如果要应用任何业务逻辑，建议选择使用复合微服务。否则，API 网关是已建立的解决方案。客户端 UI 组合模式问题：当通过分解业务功能/子域来开发服务时，负责用户体验的服务必须从多个微服务中提取数据。在整体应用中，从UI到后端服务只有一 次调用，以检索所有数据并刷新/提交UI页面。但是，现在情况不一 样了。我们需要了解如何去做。解决方案：对于微服务，必须将 UI 设计为具有屏幕/页面的多个部分/区域的框 架。每个部分

8、都调用单个后端微服务以提取数据，这称为组合特定服 务的 UI 组件。比如 AngularJS 和 ReactJS 之类的框架可以轻松地做 到这一点。这些屏幕称为单页应用程序（SPA）。这使应用程序可以 刷新屏幕的特定区域而不是刷新整个页面。数据库模式每个服务一个 数据库 问题： 1、如何来定义微服务的数据库体系结构？让我们来看下需要解决的 那些问题：2、服务必须松耦合。它们可以独立开发，部署和扩展。3、业务事务可能会强制跨越多个服务的不变量。4、一些业务事务需要查询多个服务中的数据。5、为了进行扩展有时必须对数据库进行复制和分片。6、不同服务具有不同的数据存储要求。解决方案： 为了解决上述问题

9、，必须为每个微服务设计一个数据库。它必须仅对 该服务专用，只能由微服务 API 访问它，其他服务无法访问。例如， 对于关系型数据库，我们可以使用每个服务一个专用的表，每个服务 一个 schema 或每个服务一个数据库服务器。每个微服务应具有一个 单独的数据库ID，这样就可以提供单独的访问来设置一个隔离，防 止它使用其他服务的表。每个服务共享数据库问题：我们已经讨论了每个服务一个数据库是微服务的理想选择，这在应用程序开发前并且要使用DDD开发时，是可能实现的。但是，如果应用 程序是一个整体并且试图闯入微服务时，那么非规范化就不是那么容 易了。在这种情况下合适的架构是什么呢？解决方案：每个服务共享

10、数据库不是理想的选择，但却是上述情况的可行解决方 案。大多数人认为这是微服务的反模式，但这对于棕地应用程序来说， 是将应用程序分解成较小逻辑部分的一个很好的开始。这不适合绿地 应用程序。在这种模式下，一个数据库可以与一个以上的微服务对齐， 当然也不是无限制的，最多限制为2-3 个微服务，否则扩展性，自主 性和独立性将难以执行。命令査询职责隔离（CQRS）问题：一旦我们实现了每个服务的数据库，就肯定会有查询，而且这需要来 自多个服务的联合数据这是不可能的。那我们应该如何在微服务 架构中实现查询呢？解决方案：CQRS 建议将应用程序分为两部分命令端和查询端。命令端负责 处理创建，更新和删除请求。查

11、询端负责通过使用实例化视图来处理 查询的部分。通常将事件源模式与 CQRS 一起使用来为任何数据更改 创建事件。通过订阅事件流，可以使实例化视图保持更新。Saga 模式问题：当每个服务都有自己的数据库并且一个业务事物跨越多个服务时，我 们该如何确保各个服务之间的数据一致性呢？例如，对于客户有信用 额度的电子商务应用程序，该应用程序必须确保新订单不会超过客户 的信用额度。由于订单和客户位于不用的数据库中，因此应用程序不 能简单地使用本地ACID事务。解决方案：Saga 相当于由几个子请求组成的高级业务流程，每个子请求在单个 服务中更新数据。每个请求都会有一个补偿请求，该请求在请求失败 时执行。它

12、通过两种方式实现：1、编排( Choreography )：当没有总协调时，每个服务都会 生成和监听另一个服务时间，并决定是否应该采取行动。2、编排器( Orchestration )：负责一个 Saga 的决策和业务逻 辑排序观测模式日志汇总问题：一个应用程序由在多台服务器上运行的多个服务实例组成，请求通常 跨越多个服务实例。每个服务实例均以标准化格式生成日志文件。我 们该如何通过日志了解特定请求的应用程序行为呢？解决方案：我们需要一个集中式日志记录服务，该服务可以汇总每个服务实例的 日志。用户可以搜索和分析日志。他们可以配置某些消息出现在日志 中时触发警报。例如，PCF (Pivotal

13、Cloud Foundy)确实具有Loggeregator，它从PCF平台的每个组件(路由器、控制器、diego 等)以及应用程序中收集日志。AWS Cloud Watch也做了同样的事情。 性能指标问题： 当使用微服务架构而导致的服务组合增加时，对事务进行监控就变得 非常重要，以便在出现问题时可以监视模式并发送告警。我们应该如 何收集指标来监控应用程序性能呢？解决方案： 需要一个度量服务来收集关于单个操作的统计信息。它应该聚合提供 报告和告警的应用程序服务的指标。聚合度量有两种模型：1、 推送 ：服 务将 指标 推送 到指 标服 务， 例如 NewRelic ， AppDynamics2、提

14、取：指标服务从服务中提取指标，例如 Prometheus分布式跟踪问题：在微服务架构中，请求通常跨越多个服务。每个服务通过跨多个服务执行一个或多个操作来处理请求。那么，我们如何跟踪端到端请求来 解决问题呢？解决方案：我们需要一项服务：1、为每个外部请求分配一个唯一的外部请求 ID2、将外部请求 ID 传递给所有服务3、在所有的日志消息中包含外部请求 ID4、记录有关请求和在集中服务中处理外部请求时执行的请求和 操作的信息（例如，开始时间、结束时间）5、Spring Cloud Slue th 以及 Zipkin server 都是通用实现。健康检查问题：当实施了微服务架构时，服务可能会启动，但

15、无法处理事务。在这种 情况下，如何确保请求不会转到那些失败的实例呢？使用负载均衡模 式实现。解决方案：每个服务都需要有一个端点，可以用来检查应用程序的健康度，比如/health。这个API应该检查主机的状态、与其他服务/基础设施的连 接以及任何特定的逻辑。Spring Boot Actuator确实实现了一个/health端点，并且该实现也可以自定义。横切关注模式外部配置问题：服务通常也会调用其他服务和数据库。对于开发、QA、UAT、prod等 每个环境，端点URL或某些配置属性可能不同。任何这些属性的更改 都可能需要重新构建和重新部署服务。如何避免对配置更改进行代码 修改呢？解决方案：外部化所有配置，包括端点url和凭证。应用程序应该在启动或运行 时加载它们。Spring Cloud config server提供了将属性外部化到GitHub并将其 作为环境属性加载的选项。应用程序可以在启动时访问它们，也可以 在不重启服务器的情况下刷新它们。服务发现模式问题：1、当微服务出现的时候，我们需要解决一些关于调用服务的问题：2、使用容器技术， IP 地址被动态分配给服务实例。每次地址更 改时，使用者服务可能会中断，并需要手动更改。3、每个服务的 URL 都必须被使用者记住并成为紧密耦合的。那么消费者或者路由