序言

  我以为有了蚊帐，就可以高枕无忧。。。。万万没想到，我把我和蚊子都放到了蚊帐里面，照样缠绵一晚上。。。

    基础架构即服务，如果没有风，再好的服务都是虚拟的。

    基础架构再好，不知道业务影响，也是屁用没有，服务高可用，是否影响业务，是否影响平台，其实还是需要知道业务架构的，才能知道这个服务是否对平台透明，是否对业务透明。。。透明是最好的了，用户无感知。

使用python来检测服务的高可用

  先看一下服务检测的结果，下面是服务的检测日志，五秒钟检测一次：

    以下是检测服务的脚本：

    随手写的一个脚本，没啥格式，有兴趣的就看看，没兴趣的就拉倒，反正我写一次我就忘记我写过了，在这里重点阐述的是思想。

    使用的场景是，用来测试分布式文件系统mogilefs服务是否可用，在这里不是使用常用的检测方式来检测服务是否可用，而是使用功能性测试的方式来进行检测。

    上述的每一个方法，就是测试一项功能。

    在分布式系统中，分布式文件系统是分布式存储的一种特例，而分布式文件系统和分布式存储的主要区别就是分布式文件系统一般提供了挂载的接口，而分布式存储一般是使用SDK的方式进行，而分布式文件系统也会提供SDK接口，但是这种接口会遵循POSIX规范，其实也就是unix文件系统的中read，wreite，open等操作，每种语言都会提供。

    在上述的检测脚本中，不是看每个进程是否存活来进行检测，在进程端口监听的情况下，也有可能不能提供服务，例如进程hang住，进程假死等情况发生，当使用功能性测试的时候，就不存在了，所以在分布式文件系统中，主要就是测试：能不能创建文件，能不能下载文件，能不能查询文件，从而每隔几秒来检测一次，从而达到能正常提供服务的检测。

    这种方式的检测好处在于，在生产环境中开辟一块测试的地方来进行测试，例如在分布式存储中的一个测试bucket，对于用户不可见，但是却可以进行读写测试。。。安全的测试最重要。。。每次生产出现问题了，如何测试服务是否可用？

    检活脚本，不是单纯的看进程，看端口，而是看功能是否正常。

    这种脚本，可以写的无比复杂，因为你要考虑各种场景，例如查询元数据来判断主控服务器是否正常；上传文件查看chunkserver功能是否正常；访问文件来查看前端负载均衡服务是否正常。。。场景太多，可以慢慢优化

    当你有了这种检测脚本的时候，你就可以进行各种测试了，例如，将元数据库进行关闭，查看脚本的日志情况；将元数据服务器进行宕机，查看查看日志；将chunkserver进行关闭，来查看服务。。。

    很多人在写java程序的时候，打死不愿意写一个test.html来判断服务是否正常。。我也是服。。。非要用端口进程的方式进行检测，测你妹啊。。。没准那个人死了，但是尸体还在。。。嗯。。。僵尸进程。。。

python？

    其实。。。到处都在吹嘘python多么叼，各种模块，各种使用率，导致每个人都去看，去try。。。但是，有的时候，看看自己的需求，没准你会了，其实屁用没有。。。

    重点还是在于你的规划，不是么。。。

    就像你使用redis，其实也只有几种适用的场景。。。并不是万能的银弹。。。那么问题来了。。。什么标准才是标准呢？？？？

    看了分布式存储，最好的存储？是否全部都应该用分布式存储？

    看看各种用的分布式，各种情况决然不同，各种各样的业务导致了各种各样的需求，考虑的东西不一样，从而使用的方法不同，那么问题来了，你是否能灵活使用这些工具？？？

    看起来是一个死循环，你学一样工具，然后使用一样工具，然后看所有的东西都是这个工具。。。

    那么问题来了，一个模块有很多，使用的场景也有很多，识别到它的优缺点，然后灵活使用，然后又要掌握这么多模块。。。你又花多少时间准备？？

    投入。。。实际产出比例。。。

    最终的核心问题就是：你的规划是什么样的；你用python的出发点是什么样的？单纯的准备？有没有实际产出？写一个系统？写一个脚本？做一个监控玩玩？

    当时间充足的时候可以玩玩，当有deadline的时候，那么可能只有一个选择。。。。好好珍惜现在，设想你的未来。。。。

    不忘初心。。。风来。。。

    

    一直以为有钱人都很跋扈，心都是黑的。长大后才发现，很多有钱人都懂得很多，经历很丰富，做事儿很认真，为人很宽厚，理性，比穷人更好相处----心灵毒鸡汤

    其实相对于理想，梦想，野心。。。。谈钱更简单，这是最简单的方式。。。也是最直接的方式。。。契合了unix的设计思想。