线上巡检机制

在上个文章中探讨了微服务架构中规模化产品的集群化的验证方式，这样的目的是可以实现针对服务可持续的验证。微服务架构它的特点之一是服务太多，很难保障所有的服务都是可用的，有可能出现这样的一个情况就是晚上上线的时候，产品的各个业务形态都是正常的，但是到第二天的时候，某个服务由于某些问题导致服务不可用然后影响到具体的业务形态，从而影响到客户的使用，接着而来的就是各种复盘以及问题的追究，这种是最让人头疼的。也会让业务交付的团队承担不应该属于自己的问题。那么这就涉及一个很核心的问题，这问题到底是谁的责任了？总不能让运维去承担吧。

其实抛开谁来承担责任这个说法，下来需要思考的是如何通过技术的手段来解决这个问题，从而避免让用户再次发生。首先需要明确的是在微服务的架构下，这样的事故是无法避免的。当雪崩的时候，没有一片雪花是漂亮的。微服务架构的特性本身就存在混沌的无序状态，但是混沌和不可确定性完全不是一件事，一个混沌的体系首先来说它是稳定的，只要其独特的不规则模式在面对微小的扰动时得以维持。混沌可以说它在局域上是无法预测的，但是在全局上是完全可以预测和把控的。在这样的产品架构体系下，混沌无处不在，同时它是稳定的，需要追求的是如何在技术量化的角度下来保障服务的可用性，让二者之间达成一种平衡的状态。

接着来思考，一个上线完好的产品会在什么状态下服务不可用，可能这中间存在OOM，队列堵塞，线程死锁等其他异常情况，让服务出现崩溃，从而导致服务不可用。首先所有的服务都无法人为或者技术保障来做到万无一失，那么就需要思考的是在出现问题的情况下，如何能够快速的知晓问题以及进行紧急的修复问题，从而减少客户的影响，让服务可持续的交付市场。这种情况下，可以使用线上巡检机制。

线上巡检机制可以把它理解为实时的进行轮训监控，如果一旦服务出现问题，触发报警的机制通知相关的人员进行紧急的处理。那么这地方，实时就需要交付团队来结合具体的业务形态来进行评估，这中间没有一个权威的值，可根据产品服务的用户以及产品的形态来决定这个时间，本人在工作中一般是半小时或者十五分钟的时间为界定，也就是每隔十五分钟进行轮训的检查。极端的情况是刚轮训检查完，服务是没有任何问题的，然后过了一分钟，服务出现不可用，那么问题就会到下一刻时间才能够知道，也就是知晓问题的暴露时间是十五分钟，如果在你实际的业务形态中，觉得十五分钟还是太长，那么可以设置的时间更短，但是不建议到秒级，因为那么对服务而言也是一种性能的损耗。

针对线上巡检的机制可以沿着两个维度来思考，一个是单纯的验证服务的可用性，也就是服务返回200的状态码认为服务是可用的，另外一种是结合业务场景来进行，因为服务返回200的状态码不代表服务提供的业务场景是可用的。下面案例代码是针对一个登录服务每隔10分钟的轮训检查，主要核心是检查服务可用性，没带具体的业务场景。具体案例代码如下：

#! /usr/bin/env python
# -*- coding:utf-8 -*-
#author:无涯
import  requests

def test_service_available():
   '''轮训检测登录服务'''
   assert requests.get(
      url='http://192.168.0.103:5000/login').status_code==200

下来可以把这些整合到CI的平台，每隔10分钟进行轮训的检测，具体如下：

每隔十分钟执行的效果如下所示：