微服务监测的五大原则

1、背景

====

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

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

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

2、微服务是什么

=========

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

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

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

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

3、容器是什么

=======

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

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

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

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

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

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

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

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

4、微服务与容器

从以上针对微服务和容器概念的回顾和分析来看，两者的特性是很是匹配的。利用容器的各类特色可以便捷地实现微服务架构的各类设计须要。

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

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

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

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

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

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

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

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

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

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

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

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

四、监测API

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

对API的运行、响应状态的有效监测，对微服务的总体监测是十分重要的：

· 可以捕获特定方法、功能或端点的运行瓶颈；

· 可以监测各个方法、功能或端点的调用频率；

· 可以跟踪用户业务在多个系统之间的交互行为。

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

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

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

6、总结

微服务架构的出现，以及结合容器技术的普遍使用，改变了应用的开发、部署、运维的原有模式，同时也对监测应用提出了更高的要求。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...**