如果用一个词来概括微服务的需求，那就是速度。微服务的流行使得开发者能够更高效地开发更多的功能，同时保证更可靠的性能。这种趋势已经彻底改变了开发人员创建软件的方式，而这种变化无疑在软件管理（包括监控系统）方面引起了涟漪效应。本文将重点关注高效监控微服务所需的根本性变化，并制定五项指导原则，希望能帮助读者采用最有效的监控方法来适应这种新的软件架构。监控是微服务控制系统的关键部分，系统越复杂，就越难了解各个组件的性能状态并解决相应的问题。然而，鉴于在从传统架构到微服务的过渡过程中软件交付发生了巨大变化，监控需要进行大规模改革以在微服务环境中保持良好的性能。应用以下五个指导原则将帮助您在使用微服务时建立更有效的监控机制，响应与微服务相关的技术变化，并调整相关的组织结构。作为微服务架构的重要组成部分，监控容器和运行在其内部的内容容器最近变得越来越重要。容器的速度、可移植性和隔离性优势让越来越多的开发人员能够轻松拥抱微服务模型。这些优点在很多书上都有介绍，大家想必都知道一二，这里就不赘述了，大家看懂就可以了。容器可以被认为是大多数系统的黑匣子，这对开发非常有用，因为它们从开发到生产，从笔记本电脑到云端都具有极强的可移植性。但是当涉及到服务的运维、监控和故障排除时，黑盒让一些常见的操作变得更加困难，让我们不禁要问：容器中到底在运行什么？应用程序/代码是如何执行的？能否监控重要的自定义指标？从DevOps的角度，我们不仅需要知道一些容器的存在，还需要深入了解容器内部的信息。在非容器化环境（例如主机或VM用户空间中的代理）中检测的进程可能无法与容器一起很好地工作，容器受益于小型、独立的进程，并且需要尽可能少地保持依赖性。此外，即使对于中等规模的部署，运行数以千计的监控代理也是极其耗费资源和编排的噩梦。容器有两种可能的解决方案：1）要求开发人员直接针对代码进行测试；2）利用通用的内核级测试方法查看主机上所有应用程序和容器的运行状态。我们不会在这里深入探讨这两种方法，但每种方法都有其优点和缺点，关键是哪种方法适合您的团队和服务。使用编排系统提高服务性能了解容器化环境中的操作数据是一项新挑战。单个容器的指标比构成功能或服务的所有容器的聚合信息具有更低的边际价值。这种类型的低利润数据对于应用程序级信息特别有用，例如哪些查询的响应时间最慢，或者哪些URL的错误最多。它们还适用于基础架构级别的监控，例如哪些服务正在使用超出其分配的CPU份额的容器资源等。越来越多的软件部署需要编排系统将逻辑应用程序蓝图转换为物理容器。常见的编排系统包括Kubernetes、MesosphereDC/OS和DockerSwarm。团队可以使用编排系统来(1)定义您的微服务和(2)了解部署中每个服务的当前状态。您可以争辩说编排系统比容器本身更重要，因为容器本身是短暂的（它们仅在存在时有效），而您的服务对于它们的短暂使用至关重要。DevOps团队应该重新定义警报，将重点放在监控与服务体验相关的特征上，因为这些警报是评估应用程序是否会受到影响的第一道防线。但是设置这些警报非常具有挑战性，因为如果您的监控系统不是容器原生的，它将变得非常困难。Container-native方案是利用业务流程的元数据，动态聚合容器和应用数据，并基于各个服务计算监控指标。根据所使用的编排工具，可能需要设计不同级别的结构。比如在Kubernetes中，通常有一个Namespace，ReplicaSets，Pod和一些容器。无论构成服务的容器的物理部署如何，这些不同层之间的聚合对于逻辑故障排除至关重要。为跨环境的弹性和服务做好准备弹性服务绝不是一个新概念，但容器环境的变化速度比虚拟化环境要快得多。这种快速变化的环境会对脆弱的监控系统造成严重破坏。传统架构需要频繁手动调整指标和基于软件的单独部署检查。可以为需要监控的每个指标专门定义此调优，或根据在特定容器中运行的应用程序进行配置。虽然它对于小规模操作（如几十个容器）是可以接受的，但这种方法无法承受任何更大规模的系统。对微服务的监控，必须能够在没有他人干预的情况下自动伸缩弹性服务。例如，如果一个DevOps团队需要手动定义一个容器来监控某个服务，这无疑是一个错误的决定，因为Kubernetes或Mesos全天会周期性地启动新的容器。同样，如果在构建新代码并投入生产时要求运维人员安装自定义的statspoint，那么当开发人员从DockerRegistry拉取镜像时，很可能会带来更多挑战。在生产环境中，跨数据中心或跨多个云的监控需要复杂的部署。跨环境监控无法通过单一的监控工具实现，因此需要部署一套监控系统，保证不同环境下的服务都能被监控到，维护好一个动态的、容器化的IT环境。监控API在微服务环境中，API是一种通用语言，API也是服务中唯一对其他团队开放的部分。从本质上讲，API的响应性和一致性可以看作是“内部SLA”，尽管SLA没有正式的定义。因此，API的监控是非常必要的。API监控可以以多种形式实现，但显然不能仅限于二进制检测。例如，将监控期间频繁出现的端点作为时间的函数进行分析是帮助团队检测服务使用中任何明显变化的有价值的方法，无论是由于设计引起的变化还是用户的变化。同时，你还需要关注服务中最慢的端点，因为它们可能暴露出系统中的严重问题，或者至少帮你指出系统中最需要优化的地方。在系统中跟踪服务调用的能力是另一个重要因素。在基础设施层面分解信息，从应用的角度看环境，一定会帮助你对用户使用服务时的用户体验形成更清晰、更全面的理解。“微服务”你的组织架构以上的建议都集中在微服务和监控技术的变革上。让我们关注另一个重要因素——人。想必大家都熟悉“康威定律”，它告诉我们，团队的组织结构本质上决定了最终的系统设计，而正是需要创建更快、更敏捷的软件，驱使团队不断思考如何改进系统在未来。开发重组团队结构和管理规则。因此，如果公司想要从新的软件架构中获益，技术团队必须在实施微服务时进行自我重构，这意味着原来的团队必须由更精简的团队组成，并且彼此之间的关系更松散。耦合，让你总能选择正确的方向去面对相应的需求。对于每个团队来说，他们可以更好地控制使用的语言、处理Bug的方式，甚至是运维的责任。基于这样的团队架构，DevOps团队可以构建这样一个监控平台：让每个微服务团队独立设置和管理告警、指标、仪表盘，从而全局监控整个系统的运维状态。结语是什么驱使大家积极向微服务转型？显而易见的因素是——速度。企业希望在更短的时间内为客户提供更多性能和价值的服务，因此为了保证速度，需要引入更新的技术，将架构向微服务转型，底层全面容器化，这已成为重要的发展趋势。展示。总而言之，微服务监控最基本的原则就是适应微服务带来的底层技术和架构的变化，而运维团队需要更清楚地了解这些变化，从而在一个时间段内实现有效的监控。更快更简单的方法。微服务监控。
