繁华落尽褪去，留下的不过是平淡。
技术与管理，两者之间总感觉有冲突，把大量的时间放在管理之中，让人感觉相当的烦躁。
那就看看在分布式系统中如何离开处理这种复杂而又矛盾的事情。
分布式系统架构
在分布式系统中，分为两种架构：一种架构是P2P架构，这种架构可以redis的cluster集群，采用的是DHT，一致性的hash算法，组建一个集群的时候，可以划分多个虚拟节点，这些虚拟节点组建成一个环，从而将物理服务器分布在这个环中，从而将数据进行打散进行存储，在进行扩容或者缩容的时候，只会影响相邻的机器，将顺时针的方向的服务器进行数据迁移即可，在此种架构中，没有所谓的中心节点，每台服务器存储所有的元数据信息，从而客户端访问的时候，只要访问其中的一台，从而可以获取到所有的元数据信息。
另外一种架构就是具有中心节点的架构，例如etcd存储的时候，是有中心节点的；例如在使用k8s的时候，也是具有master的角色的，大部分的分布式系统在设计的时候，总是会有中心节点的概念。在这种架构中，以k8s为例来进行说明。
在k8s中存在两种服务器的角色，一种是master，运行各种控制进程和调度进程，并且对外统一提供对外的接口；一种是node节点，主要用来运行相关的应用，也就是运行具体的pod，pod中运行具体的容器来提供服务。
在容器的分布式管理中，其实swarm更加简单，在安装docker之后就可以启用相关的集群模式，在这种模式下，也是分为master和slave的角色，但是在默认情况下，与k8s不同的是，master节点会直接运行相关服务的容器，也就是说，在swarm mode之中，这种master不但要进行管理的指责，还要做具体的任务。
那么问题来了，k8s的流行程度比swarm mode的流行程度要高很多，WHY？
按照一般的理解，swarm mode还能充分的利用master的资源来运行更多的任务，而k8s的master要占用很大的资源，那应该swarm mode更加流行了。。。
考虑一种场景，容器千千万，不在一个两个了，那么master是否成为瓶颈状态。在使用master的时候，master中要存储大量的元数据信息，例如pod存放的位置，node节点的相关信息，service等相关元数据，占用的内存是否让master不堪重负。
再考虑一种场景，在具有中心节点的架构之中，中心节点要做很多的事情，例如：对外统一暴露服务的端口，调度服务的运行，进行服务的监控，进行故障的恢复，服务的负载均衡，数据的分片复制，存储相关的元数据，而这些都是大量的CPU计算类型，在存储的时候，也是一个IO密集型的操作，如果再加上运行相关的具体任务，会不会是压垮master的最后一根稻草？
在团队中，一个leader的功能和master的工作差不多，而leader是否成为瓶颈那么就要考虑各种策略了，是否应该让leader参与到team具体的工作之中呢？？？
如何减轻master的工作？
在数据读取服务或者客户端请求元数据的时候，可以分离指令流和数据流，请求了master，返回各种元数据，master将权限进行下放，放到具体的node中，让node具有读写的权限，从而客户端在请求的时候，不用每次都请求master，从而减轻master的压力。
权限下放了，会不会造成node节点的混乱呢？解决这个问题的时候，在每个node之上运行一个kubelet进程，主要作用就是定时汇报node的相关信息。--这也就是每天的日报和每周的周报的由来？？？
权限下放了，会不会造成任务无法均衡呢？k8s解决这个问题的时候，是由master来进行统一调度的，会查看各种node节点的负载信息，从而将任务分配到压力比较小的node节点之中。--这也就是领导所谓的脑袋决定屁股的由来？？？
其实，说这么多。。。中心的论点在于，master是否重要！！！
master是否是废物
一直在纠结一个事，像master这种中心节点或者是leader是否是废物，能做什么？我需要的不过是分布式存储中的各种chunkserver来进行存储。
在分布式存储中，提供服务的是各种chunkserver，用来要用来存储各种非结构话数据，例如文件，图片，视频等信息，真正做事的也就是这些chunkserver。
在分布式存储中，master也只不过是用来存储元数据信息和各种管理工作，那么如果废除master会有什么结果？
master不在，群龙无首，当权限下放的时候，chunkserver能正常的进行读写服务，但是如果是一个新的请求，那么这些chunkserver就懵逼了，根本就不能提供服务。。。
一个好的master应该。。。雨露均占。。。。
其实说了那么多，验证了master的作用很大，而且非常有有意义存在。。。
其实我就想说，当开始做管理的时候，总是觉得不做实际的事不踏实。。。
其实我就想说，作为master的全局掌控，如果不能协调到资源，这种master没有存在的意义，你作为一个master有何作用？？？
其实我就想说，作为一个chunkserver，负责存储就好了，而作为一个master节点，要干的事情太多了。。。是否能协调开来，是否能全局调度，是否能全局恢复，是否能整体负载。。。到最后技术都不是问题，人。。。才是最根本的问题！！！
其实我就想说。。。当成为了一个master节点之后，如果单纯的是数据流存储数据，其实在这个过程中，master的参与感是很弱的。。。而对于其他的整体对外服务，整体的负载均衡。。。master的作用很重大。。
当新鲜感过了，归于平静。。。如何提高团队的士气？？？？
要有强烈的信念和长远的理想，能耐得住寂寞。。。。多少人耐不住寂寞。。。
饼有多大。。。就有多强的战斗力。。。。
那么问题来了，如何进行分布式存储的监控呢？监控方式如下：
1、 定期10S对指定的测试文件进行读写操作，不通过，告警，此举可以检测chunkserver的服务是否正常
2、 定期检查挂载点是否存在，不存在或者改名，告警，此举可以查看文件系统是否正常
3、 定期检查具体的关键目录
在服务提供的过程中，自动下发测试任务，这种测试监控方法是极好的，例如分布式存储，我就专门建一个chunk，写入读取数据来进行测试。
例如一个redis集群，写入一个key一个value，这种定时检测也是极好的。
例如一个web服务，定时的访问url，返回响应码和响应时间，这种自动下发测试任务也是很酷的。
例如一个云数据库，定时创建一个数据库实例，然后读写，HA切换，最后销毁实例，释放资源，这种也是极好极好的。。。
如何检测你活着。。。隔15S亲一口就可以了么？还有其他方法吗？。。。这就是心脏脉搏的跳动原理吗？？？？