江苏龙网

  1. 主页 > 生活百科 > >

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

架构


越来越多的软件部署需要使用编排系统来将应用程序的逻辑规划转化为物理容器的部署 。常见的编排系统包括 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 提交甚至工作职责都会拥有更大的控制能力 。




推荐阅读


上一篇：C++常见避坑指南

下一篇：17 个你需要知道的 JavaScript 优化技巧