一、背景

====

容器和微服务的呈现并失去大量利用，从根本上扭转了利用零碎的组成和运行形式。而随着开发人员开始利用编排零碎来治理和部署容器，规定进一步产生了变动。以往主机上的一个简略利用，当初已成为一个简单的、动静编排的、多容器的体系架构，这同时也对利用的监测提出了全新的挑战。

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

在微服务的架构当中，原有的单体利用被拆解成为多个层面、更小粒度、独立运行的服务。而 API 是这些服务裸露给其余服务的惟一组件。同时，API 也是拜访微服务的首要通信形式。

对 API 的运行、响应状态的无效监测，对微服务的整体监测是非常重要的：

· 可能捕捉特定办法、性能或端点的运行瓶颈；

· 可能监测各个办法、性能或端点的调用频率；

· 可能跟踪用户业务在多个零碎之间的交互行为。

5、微服务的监测体系要匹配组织架构

提到架构，咱们就不得不关注康威定律，即任意一个软件都反映出制作它的团队的组织构造，如下图所示：

康威定律同样实用于微服务的监测体系。要容许团队依据本人的设计和了解来定义本身提供服务的监测指标、报警准则，以及监测数据的展现形式，毕竟他们是对这些服务最理解的人，也是最终为服务的品质负责、解决服务问题的人。

六、总结

微服务架构的呈现，以及联合容器技术的宽泛应用，扭转了利用的开发、部署、运维的原有模式，同时也对监测利用提出了更高的要求。Sysdig 带来的五大要害准则可能帮忙咱们针对微服务和容器的个性，设计更为全面、更有针对性的监测体系。

当然，随着微服务架构和容器技术的一直进化，监测的体系和准则也是要随之一直调整的。越早意识到这样的转变，就能更早更容易地适应架构和技术的更新。

参考文献

· Principles of monitoring microservices

https://www.youtube.com/watch…

· The Five Principles of Monitoring Microservices

https://thenewstack.io/five-principles-monitoring-microservices

** 欢送观看 JFrog 杰蛙每周二在线课堂，点击报名：

https://www.bagevent.com/even…
**