运维平台中的集群管理功能设计
我在一次沙龙上说过，做一件事情和做一件具体的事情差别很大。
和很多人交流的时候，其实我是希望他做一件事情，把这件事情负责起来，但是从他们惯有的思维来看，他们希望我给他一个明确的任务，或者很具体的任务，所以从我的要求来说，那样会让我感觉要不断等待，不断推动，有时候等不了就自己做了，而做事情的同事会感觉事情好像催的很紧，好像做与不做差别不是很大，一段时间下来，发现大家都挺累。
这个过程其实还蛮痛苦，我也做了一些尝试和体验，说实话从我的角度来说，还没有达到预期，所以我也是一边摸索，一边总结。
比如我很早就规划了数据库的集群元数据管理功能，但是因为各种原因没有推动下来，于是乎我自己先做了一个简单的页面，也能看过去。
但是这个功能细细想起来，有很多的改进之处。
如果确定实例的粒度是IP和端口，也就是通过IP信息和端口能够锁定一个数据库实例。我感觉有3个问题，但是暂时还没想明白怎么处理：
1.在这个前提下，我要做集群信息管理。直接放上来一个元数据管理，粒度还是IP和端口。细细想来好像这么设计集群是不妥的。如果这样，我干嘛不直接使用实例信息管理呢。
2.集群信息相对来说是高度抽象的概念，我们使用是希望能够清晰明了的查看。集群有很多种类型，或者有很多的维度，比如最简单的主从复制，即一主一从，或者一主多从，算是最基础的集群吧，在这个基础上还有MHA的高可用集群，还有基于中间件的分布式集群。这些集群信息如果维护，是整合还是隔离开来。
3.集群要涉及到集群管理节点或者中间件信息，这些不是数据库实例，如果在集群信息中标识，或者看起来不是那么突兀。
4.回归到本源，我们做这个集群信息管理，其实一个最朴实的需求，就是我不论青红皂白，输入一个IP信息，能够返回一整个集群的信息，如果分门别类就更好了。
想明白这点之后，我发现需要分维度来展现数据。
首先，我们所说的集群，其实是希望像MHA,中间件这个层级的集群信息，因为这种集群信息相对来说更加系统化，我们其实不希望直接看到主从复制的基础信息，但这个信息是否属于集群信息，其实也算，而且如果有的话，对我们熟悉环境大有帮助，所以这个信息我们可以分维度来展现。而思路再上一层抽象，那就是我们其实可以分为两个大的维度，概览信息和明细信息。
我们希望看到的集群信息其实是数量很少的，比如有10~20套的集群，可能涉及的服务器有上百台。入口的信息就是集群的概览信息，有了这一层级的信息，我们就可以加上机房，业务描述等附加属性，这样集群信息也丰富，也可以更加专注。
而对于集群明细信息，我们就可以分为多个维度来展现了，比如基础的主从复制是一类，然后就是集群信息。
这些其实是最基础的需求和规划。
我们基于这个可以做更多的分析，而这个分析工作其实就要集合大家的智慧了，比如技术实现上，我自己想了一个方式，但是交给同事去用的时候，发现使用习惯不大一样，或者他感觉比较别扭，那么这个功能就很难用起来。如果这个方案是我们一起想出来的，那这个事情就是一个较大的起点了。
所以我拿着上面的信息和同事做了一些讨论，在讨论的过程中，把一些疑点问题也想清楚了，这个想清楚的过程就是亮点了，是不光我觉得能说得通，而且我能让同事也认可这种方式。
首先我提了下面几个疑问，一起讨论怎么解决，算是几个边界问题的确认。
1.单实例数据库不纳入集群范畴
2.主从复制是否归为集群，讨论后确认应该收集这个信息
3.MySQL的MHA和MyCAT集群的部分元数据信息会重复，如何处理？ 最后讨论是根据集群的编号来隔离，信息是公用数据表。
这些边界明确了，就是数据的访问逻辑了，就是回归到最原始的需求，我们要这个功能干嘛，最基本的需求就是能够查看集群信息。
所以数据访问逻辑方面，我们做了一些改进，自认为还不错。
1）在集群列表中，点击查看集群明细，跳转到集群明细页面
2）输入IP和端口信息，跳转到集群明细页面，功能和集群列表中跳转的功能一致
根据输入的IP和端口，确定实例的角色，从主从关系表中查询返回
根据输入的IP和端口，确定集群信息（可能不唯一），从集群明细表中查询返回（可能返回多个集群信息）
这一层讨论好，其实数据库设计层面的事情也就理清楚了，来看看程序端的具体设计和实现了。
实现细节：
1.集群列表信息的维护，设计一个表
集群列表需要的元信息：
数据库类型 集群编码 集群名称 集群类型 集群版本 集群入口（IP:端口） 业务描述 创建时间 机房 操作
2.主从关系的维护，设计一个表，实例的明细信息从实例管理（cmdb_serverr)中获取
Master_ip master_port slave_ip slave_port
3.集群明细信息的维护，设计一个表，根据数据库类型和集群编码唯一确定集群
数据库类型 集群编码 节点类型（中间件，管理节点，实例） 节点IP 节点端口 节点版本 节点状态
这些信息都是一点一点整理出来，这些信息明确了，开发的时候，那心里就亮堂多了，尽管没有数据库的表，但是我知道需要显示什么信息，可以快速迭代出一个页面来。
然后基于页面做后台的逻辑处理和数据库设计实现。
整个过程有很多工作就可以并行了。等我开发好，同事整理的数据也推送过来了，也算是可持续交付了。
通过这样一个尝试，发现自己需要先规划，先理出一个大题的思路和基本的实现，就可以从产品设计，功能实现等几个维度进行下钻，最后的结果是经过讨论后得到的为佳，自己拍脑袋想的很可能不对症，也算是集思广益吧。