微服务长什么样

微服务架构本质是带自身特点的面向服务的分布式架构模式。

微服务架构特征是有更细粒度服务边界，倡导独立开发、测试、部署、扩展等等，更细粒度带来的敏捷提升，以及分布式系统固有的复杂性。

服务治理

为什么需要监控？

微服务是一个分布式的架构模式，它一直以来都会有一些自身的问题。

• 以问题的形式来理解为什么需要监控体系，也是我们需要监控体系的理由

首先是问题的定位。

当系统发从单个节点扩张到很多节点的时候，如果系统的某个点出现问题，对于我们的运维和开发人员来说，这时的问题定位可能就会变成一个挑战。

1. 分散在各个服务器上的日志如何处理
2. 业务流程出现问题，如何快速的定位问题发生在哪个环节、哪个点

数据支撑

当新的业务进来以后，系统能否支持，系统运行的状况又是怎样？

还有现在的一些电商要做促销活动，容量规划怎么做？

我们可以通过监控手段对系统进行衡量，或者做一个数据支撑。

对服务的系统认知

要理解分布式系统是怎样一个拓扑结构，如何部署，系统之间怎样通信，系统目前是怎样的性能状况，以及出了问题我们要怎么去发现它。

1. 如何跟踪业务流的处理顺序和处理结果
2. 如何实现事故的预警，如资源不足
3. 如何分析系统的性能瓶颈

这些都可能是分布式系统需要面对的问题。出现这些问题后，监控就是一个比较常用、有效率的一个手段。

总的来说，监控主要解决的是感知系统的状况。

要监控什么

• 服务概览信息：如服务名称、服务部署所在机房、主机、服务包含的API、服务相关配置信息、服务负责人、开发人员、运维人员信息等
• 服务性能指标：如响应实现、流量、成功、失败数、请求频率等
• 服务拓扑关系：服务之间的调用关系
• 服务调用链：服务的整个调用链监控
• 服务版本信息：服务版本，客户端版本等
• 服务治理状态：服务注册情况、服务状态、熔断等
• 组件内部状态：活跃线程数、处理请求数等

监控体系和内容

监控体系从底到上分为：基础设施监控、系统层监控、应用层监控、业务层监控、端用户体验监控

监控的内容分为五个部分：日志监控，Metrics监控（服务调用情况），调用链监控，告警系统和健康检查。

日志监控，国内常用的就是ELK+KAFKA来实现。健康检查和Metrics，像spring boot会自带。

Trace调用链监控

调用链监控是用来追踪微服务之前依赖的路径和问题定位。例如阿里的鹰眼系统。主要原理就是子节点会记录父节点的id信息。

下图是目前比较流行的调用链监控框架。

基于容器的微服务监控

对于微服务系统来说，相对比较复杂的是监控，容器编排，还有日志收集，容器编排目前有很好的实现，比如Kubernetes, Swarm, Mesos,等等，这些都解决了容器的编排问题，这里之所以提到容器编排，是因为微服务的落地比较好的实现方式就是运行在容器当中，多亏了这些开源组件的存在，很多微服务所要考虑的问题都被集成到这些平台中了。

那么对于这种多说上千万个虚拟容器的大集群来说，监控到底怎么实现呢？

基于容器的微服务监控大致可以分为，容器与宿主机的监控(基础监控)，API监控，调用链监控以及应用本身的监控

1. 容器与宿主机的监控

基于容器的微服务监控和原始的监控是有很大区别的，因为服务的实例生存周期很短，分分钟可能就会有容器的生灭。

微服务的容器与宿主机的监控离不开CPU,内存,磁盘,网卡这些基础的性能指标。

对于宿主机的监控来说，我们可以依然使用原始的监控方式，每个宿主机安装一个代理来采集服务器的性能指标，代理在采集性能指标的时候可以打上时间戳和相应的标签来区分不同性能指标的数据维度（metric），然后将监控数据汇总到时间序列数据库，里面的数据可以对接目前一些开源的组件来进行可视化的展示，也可以对接报警服务（结合报警服务的报警策略）进行报警。

容器的监控自然就和宿主机不太一样了，我们不能说给每个容器镜像内部都集成一个监控代理（agent）,这样的话侵入性太强, 不易于维护。目前有比较成熟的开源产品Prometheus，它有很多的Exporter可以用来采集监控数据，例如我们想采集Kubernetes上所有容器（pod）的性能指标的话，Promethus可以通过直接配置多个Kubernetes ApiServer的Endpoints来监控整个Kubernetes集群。

2.API监控

微服务对外暴露的api都是经过服务网关来访问的，那么我们可以在网关上对这些api进行流量的分析与监控，监控api的访问量，api的响应体状态码，当某些指标达到阀值时我们就可以进行报警，目前也有很多开源的产品可以使用，例如Kong，它可以安装很多功能性插件，其中就有dashboard插件，以及监控插件。

3.调用链监控

有了对整个微服务调用链的监控，我们就会有一种一览全局的感觉，对整个微服务集群的部署情况，以及运行情况了如指掌，可以很快的定位问题，协同开发人员进行性能调优，量化运维部门的价值。目前有谷歌的Google Dapper但是没有开源只有论文，Zipkin, OpenTracing,这些都是根据谷歌的论文开发的开源产品都很不错。

4.应用本身的监控

微服务应用本身的监控的方式就比较多样了。这里我就说一下我自己基于Kubernetes实现的微服务应用级的监控插件，先上个图：

在Kubernetes的master节点，也就是安装apiserver的那台服务器上运行一个监控插件，该插件可以通过一个kubernetes提供的官方客户端来访问apiserver,首先我们要告知插件要监控哪个namespace下的哪个service，然后，插件通过和apiserver进行交互获取某个service下所有Pods的实例，插件会并发访问所有pod提供的/metrics接口（Path可配）,并给每个pod的返回数据（json格式，遵守一定的数据格式契约）打上pod_name的标签来标识每个pod返回的metrics，打上pod_name标签的同时也会打上service_name的标签用来区分具体是哪个service的监控数据。通过插件收集整理后的数据会上传到时间序列数据库中，后续就可以根据数据进行可视化分析以及展示（Granfana），同样若是结合开源监控Prometheus, OWL也可以实现监控报警，只不过结合不同的监控需要返回它们所需要的监控数据格式罢了。

参考链接：

https://juejin.im/post/5add3b05f265da0b80705525

https://blog.csdn.net/crave_shy/article/details/81334845