确保微服务优化运行的5个挑战

步才捷

关注点分离（SoC）是一项设计原则，规定软件的构建应根据关注点或总体功能来确定不同的部分，30多年来一直被用来决定如何构建技术。在单体应用中，它体现在典型的3层架构中的表现层、业务层和数据层的分离。

微服务采用了这个概念，并将其颠覆。他们将同一个应用程序以这样的方式分离出来，应用程序的单一代码库可以被分解并单独部署。这样做的好处是巨大的，但也是有代价的，通常体现在时间和金钱两方面，除了将现有的应用程序过渡到容器所带来的巨大的前期投资之外，维护该应用程序也带来了新的挑战。

挑战1：似乎很难监控整体

虽然单体应用程序也有其自身的挑战，但在单体中回滚一个“坏”版本的过程是相当简单的。在容器化应用中，事情就变得复杂许多。无论是将单体应用逐步分解为微服务，还是从头开始构建一个新系统，都有更多的服务需要监控。其中每一个都可能会：使用不同的技术或语言；运行在不同的机器或容器上；使用K8s或类似的技术进行容器化和编排。

随之而来的是，系统变得高度分散，这也意味着需要监控的东西也多了起来。以前只有一个单体进程，而现在可能有几十个容器化进程运行在不同的区域，有时甚至是不同的云。这意味着不再有一套单一的运维指标来统治他们，IT运维团队可以用它来评估应用程序的一般正常运行时间。取而代之的是，团队现在必须处理数以百计（甚至数以千计）的指标、事件和告警类型，他们需要从中分离出有效信号和无效噪音。

解决方案

DevOps监控需要从扁平化的数据模型转向分层模型，在这种模型中，可以随时观察到一系列高级系统和业务KPI。只要有一点偏差，团队就必须进入指标层次结构，查看干扰来自于哪个微服务，并从那里了解实际发生故障的容器。这很可能需要从数据存储和可视化的角度重新调整DevOps工具链。利用开源的时序DB工具，诸如Prometheus和Grafana 7.0等使得这个目标非常容易实现。

挑战2：跨服务日志记录

在谈论监控应用程序时，首先要提出的事情之一是日志。服务器每天都会产生的IT日志相当于碳的排放量，最终导致溢出的硬盘驱动器以及存储和工具成本。即使采用单体架构，日志也可能已经使你的工程师有些头疼。

使用微服务，日志变得更加分散。一个简单的用户业务可以通过许多服务进行，所有这些服务都有自己的日志记录框架。要解决问题，必须从业务可能通过的所有服务中提取不同的日志，来了解问题所在。

解决方案

这里的主要挑战是了解单个业务如何在不同服务之间流动。为了实现这一点，需要对传统的单体程序在顺序业务执行期间记录事件的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理（我们特别喜欢Jaeger的方法），但对于希望将单体重构为微服务的企业而言，转向异步、跟踪驱动的日志记录仍需要付出艰巨的努力。

挑战3：部署一项服务会破坏另一项服务

单片机世界中的一个关键假设是：所有代码都是在同一时间部署的。这意味着应用程序处于最脆弱状态的时间范围是一个已知的、相对较短的时间段（即部署后的24 ～ 48 h）。在微服务的世界里，这个假设不再成立，由于微服务本质上是相互交织的，其中一个服务细微的变更可能会导致行为或性能问题，而这些问题会在另一个服务中体现出来。因此所面临的挑战是：当前出现故障的微服务使得另一个开发团队并没有预料到他们的代碼会出现中断。这既会导致整个应用的意外不稳定性，也会导致一些组织内部的摩擦。虽然微服务架构可能让部署代码的过程变得更容易，但实际上却让部署后验证代码的过程变得更难。

解决方案

企业必须创建共享的发布日历，并且每当部署相关的微服务时，都要分配资源用于密切测试和监控整个应用的行为。在没有跨团队协调的情况下部署新版本的微服务，这个方法就像牛油果加吐司一样，是解决这一挑战的成功秘诀。

挑战4：难以找到问题的根本原因

在这一点上，你已经锁定了有问题的服务，提取了所有需要提取的数据，包括堆栈跟踪和日志中的一些变量值。你可能还有一些APM解决方案，比如New Relic、AppDynamics或Dynatrace。从那里，你会得到一些额外的关于相关方法异常处理的数据。但是，问题的根本原因呢？

你从日志中得到的前几位变量数据很可能像面包屑，指向下一条线索的方向，而不是更进一步的原因。在这一点上，需要尽我们所能，发掘出更多应用程序下的“魔力”。传统上，这需要发出关于每个失败事务状态的详细信息，即到底为什么失败。这里的挑战是，需要开发人员具有巨大的预见性，知道需要哪些信息来提前排除问题。

解决方案

当微服务中的错误根源横跨多个服务时，制定一个集中的问题根源检测方法至关重要。团队必须考虑需要哪些信息颗粒来诊断未来的问题，以及它们应该在什么层级上发出日志，以便考虑性能和安全因素，这是一座高高的山，而且是一座攀登路上永无止境的山。

挑战5：版本管理

值得强调的问题是，从典型的单体架构中层模型过渡到微服务的图模型。由于超过80 %的应用程序代码通常是第三方代码，因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入“依赖地狱”的关键因素。

考虑这样一种情况：一些团队在使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有），而其他团队则使用X.Z版本。这就增加了由于不同版本之间缺乏兼容性而产生的关键软件问题风险。

而在这之前还要提醒自己，任何一个微服务使用第三方代码的旧的更脆弱的版本，都会产生安全问题———这是黑客的天堂。允许不同的团队在孤岛般的repo中管理他们的依赖性，在单体世界中可能是可行的，但在微服务架构中，这是绝对不可以的。

解决方案

公司必须重新设计他们的构建流程，以便第三方和共享实用程序代码利用集中式artifact仓库。团队应该只允许将自己的代码存储在单独的仓库中。

与大多数科技行业的进步一样，微服务采用了一个熟悉的概念，并将其颠覆。他们重新思考了大规模应用的设计、构建和维护方式，他们带来了许多好处，但也带来了新的挑战。当我们把这5个主要挑战放在一起看时，可以看到他们都源于同一个理念。因此，每当采用像微服务这样的新技术时，底线是既需要重新思考，也需要重新调整代码的构建、部署和观察方式。总之，微服务所带来的优势是难以拒绝的，但风险也是巨大的。