确保微服务最佳运行的5个方面

如今，单体架构模式正在逐渐淡出人们的视线，越来越多的组织开始使用微服务架构模式。并且，这个趋势还要持续流行下去。之所以如此，是因为微服务延续了工程师数十年来一直采用的原则–关注点分离（Separation of Concerns ，SoC）原则。

当组织采用微服务架构后，要想成功运行它们达到预期效果，请牢记以下五个方面。

微服务的挑战

关注点分离（Separation of Concerns ，SoC）是一种设计原则，是使用“关注点”分离来构建软件。在单体应用程序中，这体现在典型的3层体系结构（显示层，业务层和数据层）分离中。其实，这也是职责单一原则的应用。

微服务将这一概念付诸实践，他们将应用程序拆分开，以使该应用程序的单个功能可单独开发部署。这样做的好处是巨大的，但它们也是有代价的–使得运营和运维成本增加。

随着组织将现有应用程序转换为容器，虽然带来了巨大的好处，但维护该应用程序还带来了新的挑战。

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

尽管单体应用有其自身的挑战，但单体应用的监视相当简单。在容器化的应用程序中，事情要复杂得多。无论你是逐步将单体应用程序分解为微服务，还是从头开始构建新系统，现在都需要监视更多服务。这些都将可能：

• 使用不同的技术/语言
• 部署在不同的机器/容器
• 使用K8s进行编排

使用微服务架构后，组织的软件系统变得高度分散，这也意味着有很多需要监视的地方，并且对集中监控的需求也越来越大。

这意味着不再有任何一套Ops指标可以统一采集和处理所有指标。然而，IT/Ops团队又需要使用这些指标来评估应用程序的总体正常运行时间，因此，团队现在必须处理大量（甚至数千个）度量指标，事件和警报类型，并从中获取到有用的信息。

解决方案： DevOps监视，需要从平面数据模型转变为分层模型，在该模型中，团队能够深入到度量层次结构中，以查看故障来自于哪些微服务，并从那里进入到发生故障的实际容器。从数据存储和可视化的角度来看，这很可能需要对DevOps工具进行重新设计。开源的时间序列数据库和工具（例如，Prometheus 和 Grafana 7.0 ）使这成为一个非常容易实现的目标。

挑战2：跨服务的日志记录

在谈论应用程序的监视时，首先要考虑的事情之一是：日志，日志，日志。服务器每天都会产生相当于”碳排放量”的IT排放量–非结构化文本的GB量规模的数据，最终导致更大的采集，存储和解析工具成本。

即使采用单体架构，你的日志也可能已经使你的工程师有些头疼。使用微服务，日志变得更加分散。一个简单的用户请求现在可能需要经过许多个服务，而且所有这些服务可能都有自己特有的日志记录框架。

要解决软件中出现的问题，你必须从用户请求过程通过的所有服务中提取所有不同的日志，以了解出了什么问题。

解决方案：这里的主要挑战是–需要了解用户单个请求，是如何在不同服务之间“流动”。为了实现这一点，需要对传统的单体应用，在顺序执行期间记录日志的方式进行大量修改。尽管已经出现了许多框架来帮助开发人员进行处理（例如， Jaeger），但对于希望将整体重构为微服务的组织而言，转向异步，跟踪驱动的日志记录仍是一项艰巨的努力。

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

单体应用中的一个关键因素是所有代码都在同一时间部署，这意味着应用程序最容易受到攻击的时间段是已知的且相对较短的时间段–应用部署时。

在微服务的世界中，这种因素不再成立，由于微服务与生俱来就相互交织，一个服务的更新变化会导致功能异常或性能问题，而这种问题有时只会在另一个服务中表现出来。

如果部署一项服务出现异常，继而破坏另一项服务，这可能会导致整个应用程序出现意外的不稳定，以及导致组织上的一些摩擦冲突。

解决方案：每当部署相关的微服务前，组织必须在团队之间创建共享的发布日历，并分配资源以紧密测试和监视整个应用程序的行为。

挑战4：寻找问题的根本原因

至此，你已经确定了有问题的服务，采集了要采集的所有数据，包括堆栈跟踪和日志。你可能还拥有某种APM解决方案，例如New Relic，AppDynamics或Dynatrace。从那里，你将获得程序运行的相关数据，但是，什么才是问题的根本原因呢？

传统上，这需要有关于每个失败请求的状态的详细信息（即确切地说，为什么失败）。这里的挑战是，这需要开发人员进行大量的预见，以提前知道他们需要什么信息才能解决问题。

解决方案：当程序异常跨越多个服务时，采用什么方法找到根本原因至关重要。团队必须考虑需要使用哪些信息粒子来诊断未来的问题，以及应该将它们记录在什么级别上来兼顾性能和安全性方面的考虑。这是一个艰巨的挑战，而且永无止境。

挑战5：三方代码的版本管理

另一个问题，我们之前提到过，但我们认为值得再次强调，从典型的单体架构过渡到微服务架构，由于超过80％的应用程序代码通常是第三方代码，因此在公司的不同微服务之间共享第三方代码的方式的良好管理，就可能避免出现前所未有的“依赖地狱(dependency hell)”。

考虑一种情况，有些微服务团队使用第三方组件的XY版本，而其他团队则使用XZ。由于不同版本之间缺乏兼容性，或者版本之间的行为发生细微变化，这很可能会就增加软件问题的风险，也会增加软件错误进行故障排除的困难。

任何使用较旧，易受攻击的第三方代码的微服务，都会为黑客提供便利条件。在单体应用环境中，允许不同的团队各自管理代码仓库中的依赖关系可能是可行的。但在微服务体系结构中，这是绝对禁止的。

解决方案：采用微服务的公司必须考虑重新设计他们的代码构建流程，以利用集中化的组件存储库（比如，Artifactory）来存储第三方和共享的实用程序代码。只能允许微服务团队将自己的代码存储在各自的存储库中。

总结

与大多数技术进步一样，微服务采用了熟悉的概念并将其颠倒过来。微服务重新考虑了大型应用程序的设计，构建和维护方式，他们带来了许多好处，但也带来了新的挑战。所以，组织在采用微服务等新技术时，需要重新思考代码的构建，部署和监控方式。

译文链接： https://thenewstack.io/5-steps-to-ensure-your-microservices-are-running-optimally/