通过

微服务中的复原能力和高可用性

小窍门

此内容摘自电子书《适用于容器化 .NET 应用程序的 .NET 微服务体系结构》，可以在 .NET Docs 上获取，也可以下载免费的 PDF 以供离线阅读。

下载 PDF

适用于容器化 .NET 应用程序的 .NET 微服务体系结构电子书封面缩略图。

处理意外的故障是最难解决的问题之一，特别是在分布式系统中。 开发人员编写的大部分代码都涉及处理异常，这也是测试中花费的时间最多的代码。 问题比编写代码来处理失败更为复杂。 当运行微服务的计算机失败时会发生什么情况？ 不仅需要检测此微服务故障（本身存在一个难题），还需要重启微服务。

微服务需要具有对故障的恢复能力，并且能够经常在另一台计算机上重启以确保可用性。 这种复原能力也归结于代表微服务保存的状态，微服务可以从中恢复此状态，以及微服务是否可以成功重启。 换句话说，计算能力需要具有弹性（进程可以随时重启），状态或数据也需要具有韧性（不丢失数据且数据保持一致）。

在其他情况下（例如在应用程序升级期间发生故障时），复原问题会复杂化。 使用部署系统的微服务需要确定它是否可以继续前进到较新版本，还是回滚到以前的版本以保持一致状态。 需要考虑的问题包括是否有足够的机器可用以保持向前推进，以及如何恢复微服务的早期版本。 此方法要求微服务发出健康信息，以便整个应用程序和调度程序可以做出这些决策。

此外，复原能力与基于云的系统的行为方式相关。 如上所述，基于云的系统必须接受故障，并且必须尝试从故障中自动恢复。 例如，对于网络或容器故障，客户端应用或客户端服务必须有一种策略来重试发送消息或重试请求，因为在许多情况下，云中的故障是部分的。 本指南中的 “实现可复原应用程序 ”部分介绍了如何处理部分故障。 它使用 Polly 等库描述使用指数退避或 .NET 中的断路器模式重试等技术，该库提供了各种策略来处理此主题。

微服务中的健康管理和诊断

它看起来可能很明显，并且通常被忽视，但微服务必须报告其运行状况和诊断。 否则，从运作的角度来看，几乎没有什么洞察。 跨一组独立服务关联诊断事件，并处理计算机时钟偏差，以理解事件顺序是具有挑战性的。 与通过商定的协议和数据格式与微服务交互的方式相同，需要标准化如何记录运行状况和诊断事件，最终最终出现在事件存储中用于查询和查看。 在微服务架构中，确保不同的团队对单一日志记录格式达成一致至关重要。 需要一致的方法来查看应用程序中的诊断事件。

健康检查

运行状况与诊断不同。 运行状况是微服务报告其当前状态以采取适当的措施。 一个很好的例子便是使用升级和部署机制保持可用性。 尽管由于进程崩溃或计算机重新启动，服务当前可能运行不正常，但服务可能仍在运行中。 你最不需要的就是通过进行升级来使情况变得更糟。 最佳方法是先进行调查，或允许微服务恢复时间。 微服务的运行状况事件有助于我们做出明智的决策，实际上有助于创建自我修复的服务。

在本指南的 实现健康检查于 ASP.NET Core 服务 部分中，我们将介绍如何在微服务中使用新的 ASP.NET HealthChecks 库，以便它们可以将其状态报告给监视服务以采取适当的行动。

还可以选择使用一个名为 AspNetCore.Diagnostics.HealthChecks 的优秀开源库，可在 GitHub 上用作 NuGet 包。 该库还提供独特的健康状况检查，处理两种类型的检查：

  • 实时性：检查微服务是否处于活动状态，也就是说，如果微服务能够接受请求并做出响应。
  • 就绪情况：检查微服务的依赖项（数据库、队列服务等）是否已准备就绪，以便微服务可以执行它应该执行的作。

使用诊断和日志记录事件流

日志提供有关应用程序或服务运行方式的信息，包括异常、警告和简单的信息性消息。 通常，每个日志采用文本格式，每个事件有一行，但异常也经常跨多行显示堆栈跟踪。

在基于单一服务器的应用程序中，可以将日志写入磁盘（日志文件）上的文件，然后使用任何工具对其进行分析。 由于应用程序执行仅限于固定服务器或 VM，因此分析事件流通常不太复杂。 但是，在跨业务流程协调程序群集中的多个节点执行多个服务的分布式应用程序中，能够关联分布式事件是一项挑战。

基于微服务的应用程序不应尝试单独存储事件或日志文件的输出流，甚至不尝试管理事件路由到中心位置。 它应该是显而易见的，这意味着每个进程应该仅将其事件流写入标准输出，而标准输出将被其运行的执行环境基础构架所收集。 这些事件流路由器的一个示例是 Microsoft.Diagnostic.EventFlow，它从多个源收集事件流并将其发布到输出系统。 这些可以包括开发环境或云系统（如 Azure Monitor 和 Azure 诊断）的简单标准输出。 还有良好的第三方日志分析平台和工具，可以搜索、警报、报告和监视日志，甚至实时监视日志，例如 Splunk 或 中间件。

管理健康和诊断信息的协调器

创建基于微服务的应用程序时，需要处理复杂性。 当然，单个微服务易于处理，但数十种或数百个类型和数千个微服务实例是一个复杂的问题。 这不仅仅是构建微服务体系结构，如果你想要有一个稳定且有凝聚力的系统，还需要高可用性、可寻址性、复原能力、运行状况和诊断。

提供微服务支持平台的群集示意图。

图 4-22. 微服务平台是应用程序运行状况管理的基础

图 4-22 中显示的复杂问题难以自行解决。 开发团队应专注于解决业务问题，并使用基于微服务的方法构建自定义应用程序。 他们不应专注于解决复杂的基础结构问题：如果这样做，任何基于微服务的应用程序的成本都会很大。 因此，有一些面向微服务的平台（称为业务流程协调程序或微服务群集），试图解决构建和运行服务以及高效使用基础结构资源的难题。 此方法减少了生成使用微服务方法的应用程序的复杂性。

不同的业务流程协调程序听起来可能类似，但每个业务流程协调程序提供的诊断和运行状况检查在功能和成熟度状态上有所不同，有时取决于 OS 平台，如下一节中所述。

其他资源

上一页下一页