微服务监测的五大原则

JFrogChina · · 685 次点击 · · 开始浏览

这是一个创建于的文章，其中的信息可能已经有所发展或是发生改变。

一、背景

容器和微服务的出现并得到大量应用，从根本上改变了应用系统的组成和运行方式。而随着开发人员开始利用编排系统来管理和部署容器，规则进一步发生了变化。以往主机上的一个简单应用，现在已成为一个复杂的、动态编排的、多容器的体系架构，这同时也对应用的监测提出了全新的挑战。

Sysdig，是专注于系统故障排查和监控工具的公司，其产品Sysdig Cloud是定位于容器系统故障排查和监控的平台。在今年召开的JFrog SwampUp用户大会上，Sysdig公司提出监测容器及构建在其上的微服务的五大关键原则。这些原则充分考虑了容器和微服务与传统架构在运维方式上的差异。

本文即是根据Sysdig公司在本次大会上的演讲视频整理而成的。

二、微服务是什么

要正确地监测微服务，首先要正确地理解什么是微服务。

演讲首先引用了Martin Fowler关于微服务的定义（Martin Fowler是国际著名的面向对象分析设计、UML、模式等方面的专家，敏捷开发的创始人之一，现为ThoughtWorks公司的首席科学家。很多人了解微服务架构都是从Martin Fowler的这篇文章开始的），即“微服务架构”描述了一种将软件应用程序设计为一组可独立部署的服务的特定方式。其中，“围绕业务能力的特性”，也就是说，微服务的划分不是依据程序的大小，而是以业务能力的拆分为基准的。这种业务细分后的服务，以及自动化部署、端点智能、去中心化控制这四大概念，是设计如何监测微服务时需要时刻考虑的。

传统架构下，应用的所有功能都实现在同一进程下，应用的扩展就是在多个服务器上复制整体的进程。而在微服务架构下，应用功能被拆分成了粒度更小、相互独立的服务，而这些服务都能够被独立地管理和部署。这样，应用的扩展和修改都可以按需只针对部分服务进行，而不会影响其他正在运行的服务。

微服务并不是SOA（Service-Oriented Architecture，面向服务架构），微服务相比SOA里的服务而言具有更小的关注点。这种全新的架构理念也带动了基础架构等多个领域的创新，其中就包括了针对应用的监测。

三、容器是什么

当前很多微服务都是运行在容器的基础之上的，那么设计针对微服务的监测同样要考虑容器的特性。

首先需要强调的是，容器（Container）并不是轻量级的虚机，它不像虚机一样拥有独立的虚拟化的操作系统，而是直接构建和运行在主机的操作系统之上。

容器除了镜像（image），也就是我们分层构建出来的目标应用之外，还包括了主机操作系统提供的进程沙盒（sandbox）。进程沙盒保证了容器之间的隔离，使得每个容器都像是运行在一台独立的虚机之上。

进程沙盒包括以下几个部分：

控制组（Cgroups）：规定了可以使用的资源的数量，如CPU、内存、网络等；

命名空间（namespaces）：规定了可以使用哪些控制组提供的资源；

安全模块（Seurity Modules）实现了容器之间的隔离。

在实际应用的过程中，容器的开发者和使用者都关注在镜像上，感觉不到进程沙盒的存在。进程沙盒的这些部分是由容器的运行态程序自动和镜像加载在一起的。

四、微服务与容器

从以上针对微服务和容器概念的回顾和分析来看，二者的特性是非常匹配的。利用容器的各种特点能够便捷地实现微服务架构的各种设计需要。

因此，虽然微服务架构刚刚出现时也是运行在虚机之上的，但目前大多数的微服务都是基于容器来实现的。那么设计针对微服务的监测也同样要考虑到容器的特性。

在我们的设计和印象当中，微服务应该是按照上图这样清晰的架构运转的。然而实际情况并非如此。随着微服务和容器规模的扩大，我们真正面对的是如下图一样的场景。显然，在这样的场景下，要全面、准确、有效地实现对微服务的监测，是一个巨大的挑战。

五、监测微服务的五大关键原则

微服务和容器的出现和大量应用，带动了架构、开发、部署、运维等多个领域的创新，也对应用的监测提出了新的要求。在传统架构中，监测关注的是虚机或主机上运行的单体应用。而在微服务+容器的架构下，应用已经分解为更细粒度、相互隔离、独立运行的进程。那么针对微服务的监测也就需要转向针对这些进程的关注。

Sysdig在此次大会上介绍了监测微服务应用需要遵循的五大关键原则：

1、监测容器，同时也要监测容器内运行的应用

针对于容器内运行的进程，监测要格外关注针对其使用资源的限制，以防止单个容器占用和消耗主机的所有资源，从而影响到主机上其他容器的运行。同样，针对编排器同样要监测和限制对主机资源的占用，尤其是在应用规模自动调整的时候，要保证合理地使用主机资源。

同时，我们不能把容器当成黑盒，必须监测到容器内运行的各种应用，如各种服务进程、数据库等。监测要收集这些应用运行的各种度量指标，如JVM的各种参数等。当然，监测也应该收集那些开发者自己定义的，针对容器内应用运行的各种度量指标。

2、监测业务自身的性能，而不是容器的性能

在实际运行当中，每一个容器的生命周期通常都不会特别的长。容器的编排系统会随时关注容器的运行状态，当发生异常时，编排系统会自动的进行调整，如删除有问题的容器，重新部署一个同样的容器加以代替；或者根据容器运行的状态自动地进行规模上的调整等。而开发者和运维者应该集中关注容器内业务应用的运行状态。

3、监测具有弹性，以及多地部署的服务

微服务的部署特性驱使我们在设计的阶段就要考虑到规模性的问题。当服务的规模从10扩展成20，扩展成50，甚至于扩展成100的时候，针对服务的监测要如何自动调整去覆盖和适应这些自动扩展的规模。同样，针对多地部署的服务，我们又该如何根据不同的组织和分类，如站点、位置、区域等，来汇聚和统计服务的整体性能。这些都是在设计监测方案之初就要重点考虑的。

4、监测API