微服务的设计模式

Posted ServiceMesher

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务的设计模式相关的知识,希望对你有一定的参考价值。

译者:崔秀龙

原文:https://dzone.com/articles/design-patterns-for-microservices-1

这是一篇杂烩文,虽然结构比较混乱,但是对微服务相关概念的介绍还是较为全面的。


微服务能在企业中发挥积极作用。因此了解微服务架构(MSA)设计的一般目标或原则,以及一些微服务的设计模式,都是是很有意义的。

  • 降低成本:MSA 降低了 IT 服务的设计、实现和管理的总体成本。

  • 提高交付速度:MSA 能够提高服务的实现速度。

  • 增强健壮性:MSA 能够增强我们服务网络的健壮性。

  • 提供可视化支持:MSA 能够为服务和网络提供更好的可视化支持。

你需要理解微服务架构的构建原则:

  • 伸缩能力

  • 可用性

  • 健壮性

  • 弹性

  • 独立的匿名服务

  • 去中心化的治理

  • 故障隔离

  • 自动供给

  • 通过 DevOps 实现持续交付

在系统建设中,坚持上述原则会遭遇很多挑战和问题。这些问题在很多解决方案中都会出现。如果能够正确的使用合适的设计模式,就能够克服这些问题。微服务的设计模式可以分为五大类,每个大类中都包含一些设计模式。

微服务的设计模式

拆分模式

根据业务能力进行分解的方式,能降低服务耦合度,实现单一职责的服务目标。这里说的业务能力是来自业务架构模型的一个概念,是企业用来创造价值的行为。业务能力通常对应到业务对象上,例如:

  • 订单管理负责订单

  • 客户管理负责客户

利用子域进行拆分

使用业务能力对应用进行拆分是个好的开端,但是往往会遇到不易分解的超级类。这种超级类在很多服务中都很普遍。用 DDD 子域来进行服务的定义。DDD 把应用的问题空间(业务)当作领域。一个领域由多个子域构成。每个子域负责业务的不同部分。子域可以分为几类:

  • 核心:业务中的关键差异因素,也是应用程序中的价值核心。

  • 支撑:和业务有关,但并非关键差异;可以自建,也可以外包。

  • 通用:并不针对业务,理想情况下,可以使用现成的软件实现。

订单管理的子域包括:

  • 产品类目服务

  • 库存管理服务

  • 订单管理服务

  • 配送管理服务

根据事务、两段提交进行拆分

这种模式可以分解事务上的服务,这样系统中就会有会有多个事务。分布式事务中的一个重要概念就是事务协调者。分布式事务由两个步骤组成:

  • 准备阶段:这个阶段中,事务的所有参与者都做好准备,并通知事务协调者,它们已经准备好完成事务。

  • 提交或归滚阶段:这个阶段里,事务协调者会向所有参与方发出提交或回滚命令。

相对于单一微服务来说,两端提交的问题就是慢。在微服务之间进行事务协调,就算是在同一网络中,也会拖慢系统;所以这种方式在高负载场景中并不常见。

绞杀者模式

前面三个设计模式都是对绿地(Greenfiled)应用进行拆分,但是还有 80% 的棕地(Brownfiled)需要对付——它们是传统、庞大的单体应用。绞杀模式为此而生。这种模式会创建两个独立的应用,一同运行在同样的 URI 空间中。随着时间点的推移,新的重构了的应用会绞杀或者替换掉原有应用,最后就可以关掉单体应用了。这种模式分为转换、共存和终结三个步骤。

  • 转换:用现代的方式创建一个并行的新站点。

  • 共存:现存站点保持原样一段时间。从现存站点重定向到新站点,渐进式的实现功能。

  • 终结:从现存站点上移除旧的功能。

舱壁模式

这个模式把应用的元素隔离开来,这样一个失败之后,其它的还能继续工作。这个模式可以类比船体结构,因此被称为舱壁。根据消费者的负载以及可用性要求,把服务分割为不同的群。这种设计能够对故障进行隔离,即使遇到故障,也能为部分消费者提供服务。

Sidecar 模式

这种模式把应用的组件部署到一个不同的容器中,从而更好地完成隔离和封装。这种模式让应用能够把多种组件和技术整合在一起。这种模式的情况很像摩托车的挎斗,因此被称为 Sidecar,Sidecar 附着在主应用上,并且为主应用提供支持能力。Sidecar 还和主应用共享同样的生命周期,它的创建和销毁都是和主应用同步进行的。Sidecar 模式有时也被称为 Sidekick 模式,这是本文中介绍的最后一个分解模式。

集成模式

API 网关模式

应用被分解成更小的微服务之后,就会出现一些待解决的问题了。

  • 如何处理来自不同渠道的不同微服务的调用

  • 如何处理不同的协议

  • 不同消费者可能需要不同格式的响应。

API 网关就是用来处理这类问题的。

  • API 网关是所有微服务调用的单一入口。

  • 可以作为代理服务器,将特定请求路由到特定微服务。

  • 可以把调用结果进行聚合,发回给消费者。

  • 可以为每种类型的客户端创建细粒度的 API。

  • 还能转化请求和响应的协议。

  • 可以代微服务进行认证、鉴权的工作。

聚合模式

业务功能被分拆为多个更小的代码段之后,如何把各个微服务返回的数据进行整合就是个问题了。这种责任不应该抛给消费者自行解决。

聚合模式可以解决这种问题。这种模式的关键是如何把多个不同服务的响应数据进行聚合,然后将最终响应发回给消费者。可以用两种方式来完成任务:

  • 用一个复合微服务调用所有必须的微服务,把数据拼装成合适的结果发回给客户端。

  • 用 API 网关把请求拆分为对多个微服务的调用,然后聚合返回结果发回给客户端。

如果这一过程中有业务逻辑,推荐使用复合微服务的方式。其它情况下,API 网关是个好方法。

代理模式

这种 API 网关只会使用 API 网关开放微服务。例如一个 API 网关有三个 API 模块:

  • 移动 API:为 FTGO 手机客户端提供 API。

  • 浏览器 API:为浏览器中运行的 javascript 应用提供 API。

  • 公共 API:为第三方开发者提供的 API。

路由网关模式

这种 API 网关负责对请求进行路由。它通过将请求路由给特定服务的方式来完成 API 调用。当它接到请求的时候,会根据请求在路由表中查找合适的服务。举个例子来说,路由表可能会将一个 HTTP 方法和路径映射为服务的 HTTP URL。这种能力和 nginx 等服务器的反向代理功能一致。

链式微服务模式

有的微服务会有多种依赖,例如销售服务依赖于产品和订单服务。链式微服务模式能够为请求提供合并的结果。

微服务 1 收到的请求会向后传递给微服务 2 和微服务 3。所有这些服务都是同步调用。

分支模式

微服务可能需要从多个数据源(或者微服务)获取数据。分支模式是聚合模式和链式模式的混合体,用来并行的处理和两个或更多个微服务进行交互。被调用的微服务可以是一个微服务组成的链条。分支模式还可以根据业务需要,调用多个或者一个微服务链条。

客户端 UI 分解模式

根据业务功能或者子域进行解耦,完成服务开发之后,负责用户体验的服务必须从多个微服务拉取数据。在单体服务的世界中,UI 接收到请求之后,只需要一次后端调用就能够获取所有数据,从而完成刷新或提交动作。然而现在不同了。在微服务的环境下,UI 要把页面/屏幕分割为多个区域。每个区域会调用独立的微服务来获取数据。AngularJS 或者 ReactJS 这样的框架能够简化这些工作。在单页面应用(SPA)中,每个微服务都有自己对应的页面组件。UI 团队要负责把多个特定服务的 UI 组件组装起来,形成页面骨架,最终完成整体页面/屏幕的输出。

数据库模式

在微服务中定义数据库架构,需要考虑几个要点:

  • 服务必须松耦合。可以独立的被开发、部署以及扩缩容。

  • 业务事务可能需跨越多个服务。

  • 有的业务事务需要查询隶属于多个服务的多种数据。

  • 数据库必须能够被复制或者共享从而满足规模要求。

  • 不同服务有不同的数据存储需求。

服务独占数据库

为了满足上述要素,每服务必须拥有各自的数据库;数据库必须被特定服务所独占。对这些独占数据是不能直接访问的,只能通过微服务 API 进行数据访问。例如关系性数据库来说,可以用服务专属的数据表、专属结构或者专属数据库。

服务共享数据库

我们刚说过,微服务领域的理想情况就是每服务都独占数据库。那么共享数据库就是反模式的。但是在单体应用拆分为微服务的过程中可就没那么容易了。后面的阶段中,可以转向每服务独占数据库的模式。共享数据库并不理想,但是在迁移过程中是有用的。多数人会认为这不符合微服务需求,但是对于既有应用,这是一个好的拆分起点。绿地应用就不该这样了。

命令和查询的隔离(CQRS)

一旦实现了服务独占数据的模式,就有了拼接多个服务的数据的需要。CQRS 把应用分成两部分——命令和查询。

  • 命令端用来处理创建、更新和删除。

  • 查询端用物化视图来处理查询。

事件源模式会为任何数据变更创建事件。物化视图订阅事件流,以此来保持更新。事件源模式的典型用法就是根据数据来管理应用程序的当前状态。例如传统的增删改查模型是从存储读取数据的。这其中存在锁定数据的需要,通常要用事务来解决。

事件源模式

事件源模式定义了处理数据操作的方法,以事件序列进行驱动,每个事件都记录在只支持追加写入的存储之中。应用程序会发送一系列事件,这些事件把每个数据操作强制写入到存储之中进行持久化。每个事件代表对数据的一些修改(例如 AddedItemToOrder)。这些事件保存在事件库中。事件库中发布的事件,其典型用途就是在应用修改实体时,维持物化视图的状态,可以用于外部系统的集成。例如一个系统可以维护一个所有客户订单的物化视图,这个视图用于在 UI 中展示。在应用加入新订单、或者在订单的项目中进行增删以及修改送货信息时,这些变更产生的事件就可以用来更新物化视图。下图描述了这个模式的概况。

微服务的设计模式

Saga 模式

在每个服务都有了自己的数据库之后,如果出现了跨服务的事务的时候,如果确认服务的数据一致性呢?在请求失败时,每个请求都要执行一个补偿请求。可以用两种方式来实现。

  • 没有中央协调机制,每个服务都会生成事件,也监听别的服务的事件,从而对是否采取动作进行决策。这是一种两方或多方的协作方式,任何一方都没有控制其它成员的能力,甚至可能对其它成员都是不可见的。这种做法能够对活动进行协调,并且能分享信息和价值。在跨越域或者可见区域进行协调时就可以用这种方法。在简单场景中,可以和网络协议类比,它定义了各参与方之间的请求和响应模式。

微服务的设计模式

  • 使用编排器负责决策,对业务逻辑进行排序。如果能够对过程中所有参与者都有控制权,并且他们都存在于同一个控制域,就可以控制活动的流程了。这种情况多见于组织内部的业务流程。

微服务的设计模式

观察性模型

日志聚合

日志聚合针对的是包含多个服务的应用。请求经常会跨越多个服务实例。每个服务实例都生成标准格式的日志文件。我们需要一个中央日志服务,把各个服务实例的日志聚合起来。用户可以对日志进行搜索和分析。可以对日志系统进行配置,如果出现了特定信息,就触发告警。例如 PCF 的日志聚合器会从 PCF 的每个组件(router、controller、diego 等)和应用中搜集日志。AWS 的 Cloud Watch 也做了同样的事情。

性能指标

微服务架构下服务数量会急剧增加,就需要提高监控的重视程度,在问题发生时,才能及时的发送警报。需要有一个度量服务来收集各种统计信息。应用提供的报告和告警都应该发送给这个服务。聚合指标有两种模型:

  • 推:服务把指标推送给监控服务,例如 NewRelic、AppDynamics

  • 拉:监控服务自行拉取指标数据,例如 Prometheus。

分布式跟踪

微服务架构下,请求经常会跨越多个服务。每个服务又要用一个或多个操作,调用多个服务来处理请求。要对请求进行端到端的跟踪,有个跟踪 ID 会非常有帮助。可以用下列方法来引入事务 ID 从而解决这一问题:

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

  • 把外部请求的 ID 传递到所有服务。

  • 在所有日志信息中输出这一外部的请求 ID。

健康检查

实现了微服务架构之后,微服务自身可能出现无法处理业务的情况。每个服务都需要有一个端点,用来检查应用的健康情况。这个 API 可以检查主机的状态、到其它服务、基础设施的连接情况,以及一些别的逻辑。

跨领域模式

外部配置

服务发现模式

  • 客户端:例如 Netflix Eureka。

  • 服务端:例如 AWS ALB。

微服务的设计模式

熔断模式

服务通常需要调用其它服务来获取数据,有时候下游服务会出现故障无法提供服务。这种情况下有两个问题:首先请求会持续发送给宕机的服务,耗尽网络资源,降低性能;其次,用户体验会变差,结果也无法预测。消费者应该通过代理服务器调用远程服务,这个代理可以扮演电路中的熔断器的角色。当错误持续出现到一个阈值时,熔断行为被触发,在一定时间内,所有调用该服务的请求都会立刻失败。时间窗口过后,熔断器允许一定数量的访问尝试。如果这些尝试成功了,熔断器恢复为正常的放行状态;如果再次出现故障,就再次进入开路状态。要调用一个容易故障的服务或共享资源,这种模式非常有用。

微服务的设计模式

蓝绿部署模式

在微服务架构中,一个应用会由多个服务构成,如果停掉所有服务,部署一个增强版本,停机时间会对业务造成很大影响。同样回滚过程也会是一个噩梦。蓝绿部署模式避免了这种问题。蓝绿部署的策略能够降低或免除服务的停机时间。这种策略同时运行两个一致的生产环境,用这种方式来解决问题。假设绿色是现存的服务实例,而蓝色是新版本。任何时间里,只有一个环境是在线的,这个在线环境会处理所有生产通信。所有的云平台都提供了蓝绿部署的支持。

 推荐阅读 






点击 阅读原文 查看更多

以上是关于微服务的设计模式的主要内容,如果未能解决你的问题,请参考以下文章

微服务设计模式(系列)-微服务拆分

微服务设计模式(系列)-微服务拆分

六种常用的微服务架构设计模式(建议收藏)

微服务架构及设计模式

微服务架构的设计模式

前端微服务设计