老式的单体应用程序正逐步被微服务分解和取代。大大小小的企业都在进行这种转型，但这并不意味着转型就很容易。在企业进行微服务转型的过程中是存在诸多挑战的，但有一些选择可以简化工作。

译者丨布加迪

策划丨徐杰承

老式的单体应用程序正逐步被微服务分解和取代。大大小小的企业都在进行这种转型，但这并不意味着转型就很容易。在企业进行微服务转型的过程中是存在诸多挑战的，但有一些选择可以简化工作。

转型原因

企业向微服务转型出于几个原因。一个应用程序被分解成小块后，测试起来更容易、部署起来更快速。这种模块化还为开发人员和团队带来了范围更明确的职责。

然而，即使最积极、最能干的公司也需要关注以下几个重要的问题，才能确保成功转型：

  • 在重写大量代码时如何保持质量？

  • 如何理解所有活动组件？

  • 如何观察自己的环境？

  • 如何监测影响？

这些问题的答案归结为两大方面：可观察性和监测。虽然许多开发人员将两个术语混为一谈，但两者之间还是存在一些细微的差别的。

可观察性首先出现在整条链路中。系统或应用程序必须是可观测的，之后才能被监测。实际上，这意味着需要安装操作系统层面的服务或代理，而对应用程序而言，则需要公开端点。一旦公开了关键信息，就可以对其进行监测。监测告诉您哪些内容损坏了（或即将损坏）、以及其中的损坏原因。

注意事项

从单体架构向微服务转型应对用户透明。为了实现这个目标，您的监测系统需要考虑一些关键问题。

  • 是否可以通过提供足够的正常运行时间和可用性，满足客户的需求？

  • 应用程序响应速度是否够快？

  • 发现问题并排除问题需要多久？

  • 开发人员如何管理变更？

不妨让我们更详细地了解以一下这些问题、以及如何应对它们：

1. 是否可以通过提供足够的正常运行时间和可用性，满足客户的需求？

在大多数情况下，对于目前的单体应用程序，您已经有了这个问题的答案。接下来将介绍的是面向客户的应用程序的正常运行时间，以及部署或计划外中断导致的停机时间。

就微服务而言，跟踪正常运行时间与单体程序很相似，但在开发“关键路径”微服务时需要确定更多的数据点。比如说，如果将登录逻辑提取为单独的微服务，前端微服务的可用性可能会上升。然而，登录服务停机时间将对您的用户产生重大影响。

换句话说，这个问题的答案对于微服务来说比较复杂，但是适当的工具和从始至终跟踪请求的能力将帮助您实现这一目标。

2. 应用程序响应速度是否够快？

在单体应用程序中，活动组件更加靠近——所有组件都在同一环境中。但在微服务中，由于请求不再通过单体应用程序来传输，而是可能向不同的微服务生成多个请求，因此向分布式微服务转型将影响应用程序的响应能力。

为了解决这个问题，您需要监测自己的应用程序和基础设施，专注于监测技术管理结构中的智能化和可视化。通过获取从请求到结果的指标，并通过多个微服务和系统对其进行跟踪，能够为您提供所需的见解和答案。

3. 发现问题并排除问题需要多久？

单体应用程序中的一个重大问题可能会使整个系统陷入停顿。然而，当系统建立在解耦和模块化的微服务架构上时，其中的问题可能是潜伏性的，这将更加难以发展。

快速识别问题的能力需要可观察性和监测的共同支持。因此，微服务的组件需要可观察性，以便对其进行监测。而在出现问题时，需要警告提供详细信息，以缩短排除和解决故障的时间。比如说，没有其他信息的“CPU使用率高”警报几乎没有用处。但如果警报显示“在X时间段内系统上的CPU使用率持续保持高位”，并有能够显示过去几分钟内进程使用大量CPU资源的视图。这种警报会大大缩短解决故障的时间。

4. 开发人员如何管理变更？

开发人员的情绪可能难以衡量，但这非常重要。减员在企业生命周期的任何阶段都是一种风险，尤其是当您正在进行重大转型时，减员对企业的影响将更加显著。

解决这个问题的最简单方法是，是通过与相关团队进行非正式对话，或者对开发人员进行较正式的调查。即便您开发团队中的大部分人都感受到了单体架构的弊端，并希望进行这种转型，但了解团队中每个开发人员的想法仍非常重要。

工具帮助

工具很重要，这点毫无疑问。工具有助于确定和衡量服务级别指标（SLI)，这些指标会影响您的服务级别目标（SLO）。借助良好的工具，您可以实现快速的启动运行，并减少麻烦。

向微服务转型应该会对您的SLI/SLO带来积极的影响，但若要做到胸有成竹，唯一的办法是借助良好的可观察性、更好的监测，以及对环境整体的了解。

自建or开源

决定使用哪些工具时，许多企业的本能反应是自己搞。毕竟，没有人比自己的开发人员或SRE团队更了解本企业的可观察性和监测需求？事实上，“自己搞”工具（尤其是要做到有效和准确）困难重重，且容易出错。大多数选择自己开发工具的企业，都会后悔走这条艰难的道路。

另外的选择是走开源路线。Prometheus + Jaeger + Grafana架构可满足您在转型期间的大部分需求。

在这种架构中，您将使用安装在系统上或作为库包含在应用程序代码中的Prometheus客户端。客户端捕获指标后将其公开，供Prometheus服务器抓取并存储在时序数据库中。

Jaeger执行分布式跟踪，为通过微服务系统的事务捕获指标和数据。

同时，Grafana与Prometheus和Jaeger数据源一起提供可视化和仪表板。

这种开源架构让您有机会根据需要来修改和配置工具。它还可能直接支持一些基本的使用场景。当然其缺点是，对于每个工具，您都需要紧跟版本，更新安全补丁及配置变动。此外，开源解决方案常常会在以后带来扩展方面的难题。随着更多微服务不断构建，管理软件和存储遥测数据的成本都会上升。因此在选择工具时，建议企业还是要从自身需求角度出发。

总结

当企业从单体架构像微服务转型时，所面临的挑战是确保顺利转型，同时自始至终保持（或提高）应用程序的质量。而在这个过程中，可观察性和监测是保持质量的关键。