本文介绍一种关于微服务的反模式，Chris Richardson将其命名为“Microservices ate my application（微服务吞噬了我的应用）”。它描述了一种情况，即技术（在此指微服务架构）成为工程组织所犯错误的替罪羊。这个反模式的名称灵感来源于英语表达“The dog ate my homework”（狗吃了我的作业），它指的是未完成作业的一个难以置信的借口。

反模式：微服务“吞噬”了我的架构

这种反模式的一个实例如下。一个组织努力使用微服务架构模式构建应用程序。他们遇到了许多持续存在的问题，包括开发缓慢、数据不一致、性能不佳和可用性低。但该组织没有为自己做出的决策负责（这些决策才是导致问题的原因），而是归咎于微服务架构。

成群的微服务不会攻击项目

虽然将问题归咎于微服务架构既容易又方便，但事实是微服务不会成群结队地攻击无辜的项目。项目失败的根本原因在其他方面——具体来说是两个问题的结合。第一个问题是组织有时会做出糟糕的架构设计决策。第二个问题是组织经常忽视事情出错的警示信号。让我们依次来看每个问题，首先是糟糕的架构设计决策。

问题1：糟糕的架构设计决策 => 糟糕的架构

应用程序的架构是一组设计决策的组合。因此，架构的质量反映了架构设计决策的质量。糟糕的设计决策往往会导致架构问题——在使用微服务架构模式时尤其如此。有许多设计决策需要做出，其中许多决策影响重大。即使是小的失误也可能产生深远的影响。

问题2：忽视事情出错的迹象

导致项目失败的第二个原因是组织忽视了表明需要纠正方向的明显警示信号。开发项目不会在一夜之间失败——总是有早期迹象表明出了问题。组织必须保持警惕，在出现问题迹象时采取行动。例如，如果开发速度变慢，就必须调查原因。

现在让我们看看避免这种反模式的方法。

避免“微服务吞噬了我的应用”反模式

有四种推荐的方法来避免“微服务吞噬了我的应用”反模式：

  • 对自己的设计决策负责
  • 改进设计决策过程
  • 通过进行更小、更安全和可逆的更改来降低风险
  • 跟踪和改进指标

让我们依次来看每个建议。

建议1：对自己的设计决策负责

三个建议中的第一个是你和你的组织要对自己的设计决策负责。

如果一个决策被证明是有缺陷的，要为此负责——这是过程的一部分。

错误是不可避免的，但它们也提供了宝贵的学习机会。

当然，承认错误的自由需要一种鼓励学习和成长的积极文化。

建议2：改进设计决策过程

第二个建议是你和你的组织要改进架构设计决策的过程。做出更好设计决策的一个好方法是进行审慎设计。审慎设计是一个七步过程：

  • 了解背景
  • 定义问题
  • 定义评估解决方案适用性的标准
  • 寻找候选解决方案
  • 评估每个候选解决方案的权衡
  • 选择最佳解决方案
  • 记录解决方案

应该使用审慎设计过程做出的关键架构设计决策的示例包括：

  • 在开始开发时是采用单体优先（通常）还是微服务优先（有时）的方法
  • 何时将单体应用重构为微服务
  • 何时定义一个新服务

建议3：进行更小、更安全和可逆的更改

第三个建议是通过进行更小、更安全和可逆的更改来降低风险。如果进行较小的更改，你将更快地从生产和用户那里获得反馈。这也会使从错误中恢复变得更加容易。例如，一个组织应该使用绞杀者模式逐步将单体应用重构为微服务，而不是进行大规模重写。

建议4：跟踪和改进指标

第四个建议是组织要持续跟踪和审查关键指标，包括：

  • DORA 指标
  • 设计时耦合指标，例如分析 Git 历史记录以识别经常同步更改的服务，并跟踪对每个服务 API 进行破坏性更改的频率
  • 团队情绪，包括开发体验指标

应该定期审查这些指标，如果存在问题则采取行动。

DORA指标用于衡量软件开发团队的表现：

  • 部署频率 - 软件更改部署到生产环境的频率。
  • 变更前置时间 - 从代码提交到部署所需的时间。
  • 服务恢复时间 - 生产环境事故或中断后恢复服务所需的时间。
  • 变更失败率 - 导致失败或需要补救的生产部署的百分比。

参考引用