集群管理要点

第一章：RD/OP 实际上在写同一个分布式系统

一、每一个应用都是集群的一部分，每一个RD都有一套本身的集群管理方式

有的设计得很是简单：一个配置文件，读取一下数据库的ip和端口

有的设计得很是复杂：使用zookeeper这样的名字服务，本身作监控，本身部署代码，本身作服务发现等

RD的视角不多考虑运维的问题，RD视角出发的集群管理基本上是以程序可以运行起来为标准的。

RD无法不考虑集群管理，由于没有这个，程序是没法独立运行的。

RD无法太多的去考虑集群管理，由于大部分的应用的开源的，没法假设实际的运维工具栈。

二、每一个运维系统都是在给应用打补丁，每一个OP都在给RD擦屁股

运维系统与分布式应用没有什么区别。运维系统其实是在作adapter，把每一个接入的应用建模成同样的分布式应用。

OPDEV实际上不是在写运维自动化系统，他们在写的是一个分布式系统的集群管理模块。

OP实际上不是在接入系统，而是在把各类乱七八糟，半拉子的分布式应用改形成可运维的模式。

一堆互相作法不一样的系统，每一个系统又由RD/OP两种角色的人各搞半拉子工程拼接而来。

=================

第二章：面向场景面向过程的思惟

发布：新的版本上线

变动：全部对已有版本的改动

配置更新：变动的一种，用某种接口修改配置使其生效

扩容缩容：变动的一种，增长机器

开区合服：变动的一种，增长一个业务上的set

故障处理：变动的一种，修复线上机器的故障

过程，传文件：须要一种通用的文件传输机制

过程，执行脚本：须要一种通用的获取ip，脚本执行机制

过程，调用API：须要一种通用的调用云服务的api的机制

过程，组合：面向每一个场景的每一个操做，都要有一个过程。更大的组合是对一堆过程拼装。

结果是一大堆没法重用的脚本，没法审查，没法验证。bash/ant 等语言不是惟一问题，没有足够好的人来写脚本也不是惟一问题。为何须要这么多大致上是重复脚本，才是问题。

unscalable thinking

==============

第三章：对状态进行建模

idea：对状态进行建模。比对实际的状态和预期的状态得出动做。

想法很好，可是实践起来发现这个事情其实很坑：

问题1，从上往下事无巨细的描述状态：从最上层的每一个机器上运行多少个进程，到最底层的有几个文件，都有什么内容。

问题2，静态地描述全局：须要描述有多少个ip地址，每一个ip上都部署了什么，每一个配置文件里的依赖项都是静态肯定的

问题3，动做很是难搞对：没法测试这个部署脚本。不少时候在一个空机器上运行会挂掉，可是在个人机器上运行就是成功。

问题4，跑起来太慢了，并且不可靠：须要从外网下载一堆东西，很慢。即使不用下载，运行一堆apt-get也快不到哪里去

================

第四章：docker

docker解决的问题是状态能够是一个很大粒度的东西。不用细粒度到文件级别，能够把一个进程的全部依赖打包成一个黑盒。apt-get仍是yum，就不要紧了。

================

第五章：名字服务，服务注册，服务发现

smartstack作的事情实际上是名字服务的统一化。构建一个进程和服务级别的名字服务（大部分运维出发的CMDB，都是IP级别的），而后把全部人的名字服务所有统一成一个，能够网络依赖问题。

================

第六章：marathon & helix 

这两项工具其实干的事情是相似的。与其事无巨细地描述预期的状态，不如给必定一些规则，让系统去自动决定最佳的状态是什么。给定5台机器不一样负载，上面要跑10个进程，marathon会帮我搞定每台机器上跑哪些进程。

helix也是相似，告诉helix须要多少个partition，都应该是什么状态，由helix去分配。

==================

第七章：detc

现状：一堆互相作法不一样的系统，每一个系统又由RD/OP两种角色的人各搞半拉子工程拼接而来。用一大堆脚本，以过程化的思惟去管理系统。

预期：一堆系统虽然功能不一样，可是用彻底一致的方式来管理。接管全部RD/OP承担的集群管理工做，全盘地处理问题。以面向状态地思惟去建模，虽然仍然有脚本，可是都是原子化可复用的。