转载

从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），但对于希望将整体重构为微服务的组织而言，转向异步，跟踪驱动的日志记录仍是一项艰巨的努力。