本文源码：GitHub·点这里 || GitEE·点这里

一、分布式故障

分布式系统的架构，业务开发，这些在良好的思路和设计文档标准之下，是相对来说好解决的，这里的绝对是指比拟分布式架构下生产环境的忽然故障。

在理论的开发中，有这样一个很妖娆的状况：越是外围简单的业务，越是放心出问题，越容易出问题。

所以当外围服务的链路呈现故障时，如何疾速定位问题就是一件很头疼的事件，尤其是一些非凡状况下，问题很含糊很难复现，外加客户或者领导督促，这种场景心里暗影是大部分开发都有的。更有甚者，可能问题产生的切入点的开发是某人负责的，理论问题是产生在申请链路的其余服务上，这种状况遇多了，甩锅程度会直线回升。

越是简单的零碎，越是经验丰富的开发或者运维，对监控零碎就越是有执念，尤其是全链路的监控，底层，网络，中间件，服务链路，日志察看预警等，用来疾速定位问题，省时省心。

二、全链路监控

1、监控档次

在分布式系统中，须要监控的体系和档次极其简单，通常整体上划分为三个档次：应用服务，软件服务，硬件服务。

通常状况，运维治理硬件服务，开发治理利用和软件服务。

2、应用服务

应用层为开发的业务逻辑服务，也是最容易突发问题的一个层面，当在一家公司待久了，因为开发过多个业务线，就会感觉本人不是开发，是个打杂的，每天都要分出大量工夫解决各种问题。应用层监控波及上面几个外围模块：

申请流量

任何服务，高并发的流量都会裸露各种服务问题，尤其外围接口的流量更是监控的重点。

服务链路

一次申请产生问题，疾速判断问题所在的服务，或者哪些服务之间，这对疾速解决问题是至关重要的。

日志体系

外围接口日志记录也是必备的性能，通常状况下基于日志体系的剖析后果，能够明确零碎的异样点，重点优化。

3、软件服务

为了解决分布式系统的各种简单业务场景，通常会引入各种两头软件来做撑持，例如必备的数据库，缓存，音讯 MQ 等，通常这些中间件都会有自带的监控治理端口。

数据库 ：较多应用 Druid 监控剖析；

音讯队列 ：罕用 RocketMQ 和控制台；

Redis 缓存 ：提供命令获取相干监控数据；

还有一些公司甚至间接在中间件层开发一套治理运维和监控的聚合平台，这样更容易从整体上剖析问题。

4、硬件服务

硬件层面，运维最关注的三大核心内容：CPU、内存、网络。底层硬件资源暴发的故障，来自下层的应用服务或者中间件服务触发的可能性偏高。

硬件层面的监控有许多成熟的框架，例如 zabbix，grafana 等，当然这些组件性能很丰盛，不仅仅在硬件层利用。

5、雪崩效应

有些故障导致大面积服务瘫痪，也称为雪崩效应，可能故障源没有疾速解决，也没有熔断机制，导致整个服务链路全副垮掉，这是常见的问题，所以在解决故障时，要学会基于全栈监控信息，全局关联剖析外围故障点，疾速切断单点服务的故障，保障整个零碎的可用性。

三、注意事项

监控零碎尽管作用很大，然而理论搭建的时候难度还是很大，须要有较好的意识，不是业务开发那种感觉，方方面面需要都须要解决，做监控零碎的根本策略如下。

1、选择性

不是所有服务的所有环境，和所有接口都须要监控，通常都是监控外围链路，外围中间件，和服务所在环境。

例如：交易链路，交易库，和部署的环境；或者大客户高并发业务，一旦出问题须要及时响应，立刻解决。说的间接点，带来收益的服务是须要重点关注的。

非关键服务即便呈现问题，是有缓冲工夫的，所以不须要破费精力增加监控，在做监控零碎的时候存在这样一句话：简略的链路增加监控，简单了容易出错；简单链路增加监控，更简单更容易出错，然而这样却是为了更好的解决故障。

2、独立性

监控零碎的自身产生故障，不能影响失常业务流程，即便在肯定状况下没有监控信息，也不能因为监控服务影响失常业务服务。

3、整体性

聚合的监控零碎能够察看监控链路的全局状态，这样能够疾速定位故障坐标，能够关联性剖析问题起因。

4、预警性

例如 CPU 忽然升高，某个中间件服务忽然进行，内存占用过高，这些能够基于监控零碎做预警告诉，而后邮件或者音讯告诉到相干负责人，达到疾速响应的目标，这个场景大部分开发都相熟，且有心理暗影。

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

举荐浏览：架构设计系列