对于微服务架构监控应该遵守的原则

随着软件交付方式的变革，微服务架构的兴起使得软件开发变得更加快速和灵活。在这种情况下，监控系统成为了微服务控制系统的核心组成部分。随着软件的复杂性不断增加，了解系统的性能状况和及时排除问题变得更加困难。因此，监控系统也需要与时俱进，进行全面的改造，以更好地适应微服务环境的需求，并能够更好地发挥作用。

新兴的微服务架构对软件开发带来了速度和灵活性的提升，从而改变了传统的软件开发模式。其中，速度是微服务的核心需求之一。为了更好地满足这一需求，监控系统也需要随之进行调整和改进。

监控在微服务体系结构中变得尤为关键，因为随着软件复杂性的增加，我们需要更好地了解系统的性能和及时发现问题。下面是我们制定的五个指导性原则，以帮助我们整监控方法：

1. 监控容器及其内部：微服务通常在容器中运行，因此监控容器本身以及容器内的各种组件和资源是至关重要的。
2. 关注服务性能而不是容器性能：在微服务架构中，重点应该放在监控服务的性能和健康状态上，而不是单纯地监控容器的资源使用情况。
3. 监控弹性和多地部署的服务：微服务架构的一个优势是其弹性和多地部署的能力，因此监控系统需要能够有效地跟踪和管理这些特性。
4. 监控 API：微服务通常以 API 的形式提供服务，因此监控这些 API 的性能和可用性对于确保整个系统的稳定运行至关重要。
5. 将监控映射到组织结构：根据我们的组织结构和团队的职责，设计监控系统的结构，确保监控数据能够直观地反映出整个组织的运行状态。

通过遵循这五个原则，可以建立起更加有效和全面的微服务监控系统，从而更好地应对微服务架构所带来的技术和组织上的挑战。

下面我们细说这五个原则

监控容器及其内部

随着微服务架构的流行，容器技术已成为构建微服务的重要组成部分。容器具有速度、可移植性和隔离性等优势，使得开发人员更容易接受微服务模型。容器的好处已经被广泛讨论，不再赘述。

然而，对于外部系统来说，容器就像一个黑盒子一样。这对于开发人员来说是非常方便的，因为容器可以轻松地在不同的环境中部署。但是一旦容器开始运行，当需要监控和解决服务问题时，这个黑盒子就会成为挑战，因为常规的监控方法往往无法生效。我们需要深入了解容器内部运行的情况：究竟运行了哪些程序和代码？它们的性能如何？是否有重要的输出指标？从DevOps的角度来看，我们需要更深入地了解容器，而不仅仅是知道它们的存在。

在非容器环境下，常见的监控方法是在主机或虚拟机的用户空间内运行一个代理程序。然而，这种方法并不适用于容器环境。容器的优点之一是轻量级，它们将各种进程隔离开来，并尽可能地减少依赖关系。

此外，大规模使用成千上万个监控代理对于即使是中等规模的部署来说都是一种昂贵的资源浪费和管理上的挑战。对于容器环境，有两种潜在的解决方案：

1. 要求开发人员直接监控他们的代码：让开发人员负责监控其代码的性能和运行状况。这种方法可以让开发人员更深入地了解其代码的运行情况，但可能会增加他们的工作负担，并且对于整个系统的全面监控可能不够全面。
2. 利用内核级的检测方法：使用一种通用的内核级监控方法来查看主机上的所有应用程序和容器活动。这种方法可以减少代理的数量，并提供更全面的监控覆盖范围，但可能会影响主机的性能，并且可能无法提供与每个容器相关的详细信息。

每种方法都有其优点和缺点，选择最适合环境的方法取决于我们的具体需求和限制。

利用业务流程系统提醒服务性能

在容器环境中理解运行数据并不容易，相比于单个容器，聚合多个容器组成的功能或服务的复杂度要低得多。

这种方法特别适用于应用程序级别的信息，比如哪个请求具有最短的响应时间，或者哪些 URL 遇到了最多的错误。同样，它也适用于架构级别的监控，比如哪个服务的容器使用了超出事先分配的 CPU 资源。

越来越多的软件部署需要使用编排系统来将应用程序的逻辑规划转化为物理容器的部署。常见的编排系统包括 Kube.NETes、Mesosphere DC/OS 和 Docker Swarm。团队可以利用编排系统来定义微服务，并理解每个服务当前状态。可以说编排系统甚至比容器本身还要重要，因为容器是临时的，只有在满足服务需求时才会存在。

DevOps 团队应该将告警重点放在服务运行特征上，以尽可能贴近监控服务的实际体验。如果应用受到影响，这些告警是评估事态的第一道防线。但是获得这些告警并不容易，除非监控系统是基于容器本身的。

容器本身的监控解决方案利用编排元数据来动态聚合容器和应用程序数据，并按每个服务计算监控度量。根据使用的编排工具，可能希望在不同的层次进行深入监测。例如，在 Kubernetes 中，通常会有 Namespace、ReplicaSet、Pod 和其他一些容器。聚合这些不同的层次对于排除逻辑故障是非常必要的，与构成服务的容器的物理部署无关。

监控弹性Elastic和多地部署Multi-Location的服务

弹性服务并不是一个新概念，但在原生容器环境中的变化速度比在虚拟环境中要快得多。这种快速变化会严重影响监测系统的正常运行。

传统系统的监测通常需要根据软件部署进行手动调整。这种调整可能是具体的，例如定义要捕获的单个指标，或者基于应用程序在特定容器中的操作来配置要收集的数据。在小规模环境下（例如几十个容器），我们可能可以接受这种手动调整，但在大规模环境下就难以承受了。微服务的集中监控必须能够自动地随着弹性服务的增长和缩减而调整，无需人工干预。

举例来说，如果 DevOps 团队必须手动定义哪些服务需要监控，那么他们很可能会失手，因为像 Kubernetes 或 Mesos 这样的平台每天都会定期创建新的容器。同样，如果在将代码部署到生产环境时需要运维团队安装一个定制的状态端点，这也会给开发人员从 Docker 仓库获取基础镜像带来更多的挑战。

在生产环境中，建立面向跨越多个数据中心或多个云的复杂部署的监控是一项挑战。例如，如果服务跨越私有数据中心和 AWS，那么亚马逊的 AWS CloudWatch 就很难实现这一点。因此，我们需要建立一个能够跨不同地域的监控系统，并能够在动态的原生容器环境下运行。

监控 API

在微服务环境中，API 接口是通用的，并且本质上是将服务暴露给其他团队的唯一组件。事实上，API 的响应和一致性可以看作是“内部 SLA”，即使还没有定义一个正式的 SLA（服务等级协议）。

因此，API 接口的监控也是必不可少的。API 监控可以采用不同的形式，但很显然，它绝对不是简单的二进制上下检查。例如，了解像时间函数这样的最常使用的端点是很有价值的。这使得团队可以看到服务使用的变化，无论是由于设计更改还是用户的变化。

还可以记录服务最慢的端点，这些可能会揭示出重大的问题，或者至少指向需要在系统中进行优化的区域。

最后，跟踪系统服务响应的能力是另一个非常重要的能力，它主要是供开发者使用的，但也有助于你了解整体用户体验。同时，将信息基于底层和应用程序视角分成两大部分也是很有帮助的。

将监控映射到组织结构

对于熟悉康威定律的人来说，系统的设计是基于开发团队的组织结构。创造更快、更敏捷的软件推动了团队重新思考他们的开发组织和管理规则。因此，如果他们想要从这种新的软件架构（微服务）中获益，他们的团队必须将微服务映射到团队自身的结构中。换句话说，他们需要更小、更松散耦合的团队，这些团队可以自主选择自己的方向，只要能够满足整体需求即可。在每个团队中，他们对于开发语言的使用、bug 提交甚至工作职责都会拥有更大的控制能力。