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

1、每个应用都是集群的一部分,每个RD都有一套自己的集群管理方式

有的设计得非常简单:一个配置文件,读取一下数据库的ip和端口

有的设计得非常复杂:使用zookeeper这样的名字服务,自己做监控,自己部署代码,自己做服务发现等

RD的视角很少考虑运维的问题,RD视角出发的集群管理基本上是以程序能够运行起来为标准的。

RD没法不考虑集群管理,因为没有这个,程序是无法独立运行的。

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

2、每个运维系统都是在给应用打补丁,每个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承担的集群管理工作,全盘地处理问题。以面向状态地思维去建模,虽然仍然有脚本,但是都是原子化可复用的。

 

posted on 2015-10-26 01:31  taowen  阅读(1049)  评论(0编辑  收藏  举报