前言
服务树这个名词几乎所有运维和运维开发同学都不陌生，但是服务树的原理和为啥用服务树估计大家并不了解，本文先来讨论下这些基本概念，下文讨论如何实现，下图为其核心组件stree-index
服务树与资源管理
其实无论是引入CMDB或服务树的一个重要目的是完成对应用运行所依赖的资源管理
资源包含什么
既然是应用运行时依赖的，那么自然能想到的是诸如ecs/elb/rds/dcs/domain/等
- ecs：就是机器，具体可以是虚拟机/物理机，可以轻松的设计出这一张表
+-------------------+--------------+------+-----+-------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+--------------+------+-----+-------------------+----------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| uid | varchar(100) | NO | UNI | NULL | |
| name | varchar(200) | NO | | NULL | |
| hash | varchar(100) | NO | | NULL | |
| cloud_provider | varchar(20) | NO | | NULL | |
| account_id | int(11) | NO | | NULL | |
| region | varchar(20) | NO | | NULL | |
| tags | json | YES | | NULL | |
| instance_type | varchar(100) | NO | | NULL | |
| charging_mode | varchar(10) | YES | | NULL | |
| private_ip | json | YES | | NULL | |
| public_ip | json | YES | | NULL | |
| availability_zone | varchar(20) | NO | | NULL | |
| vpc_id | varchar(40) | YES | | NULL | |
| subnet_id | varchar(40) | YES | | NULL | |
| status | varchar(20) | NO | | NULL | |
| security_groups | json | YES | | NULL | |
| created_at | datetime | NO | | NULL | |
| create_time | datetime | NO | | CURRENT_TIMESTAMP | |
| update_time | datetime | NO | | CURRENT_TIMESTAMP | |
+-------------------+--------------+------+-----+-------------------+----------------+
- elb：代表负载均衡器，elb可以分为L4/L7，承接服务的入口和转发流量
- rds：代表关系型数据库，engine可以分为 mysql/PostgreSQL
- dcs：代表nosql型缓存，engine可以分为redis/memcached
- domain：代表域名常，可以解析到elb/ecs
- 其余资源：凡是能应用运行所依赖的并且需要管理的都可以继续添加资源
资源记录维护模式
基于物理机房的采购入库模式
- 如果有物理idc的话，那么一定有个采购系统，那么信息的新增入口应该在这里
- 然后可以写一个
info-agent部署在所有节点上采集信息上报到服务组件汇总
基于公有云的信息同步方式
- 如果是基于公有云的形式，那么新增/删除资源等操作最终都需要到具体的云上操作
- 如果公有云能提供每次增量更新的信息(比如几点几分新开了10台规格为xx的ecs)，并将这个信息以类似公有云消息通知服务
SMN推送到注册好的借口即可完成对资源的增量更新 - 那么多个公有云账号下面其实有资源的全局视图
- 所以只能通过一个
sync-worker组件定时同步，然后在sync中做to_add,to_del,to_mod的set 做增量更新
引入树级结构目的
- 经过上面讨论的内容我们已经有了若干张资源表:ecs/elb/rds/dcs
- 但是资源和业务好像没有什么关联
- 所以要引入一颗树
树级结构组织形式
- 一个三级树结构展示
祖父层级一:
父层级一:
子层级一
子层级二
子层级三
父层级二:
子层级一
子层级二
子层级三
祖父层级二:
父层级三:
子层级一
子层级二
子层级三- 服务树单一标识的表现形式：使用
.分隔父子结构 比如 a.b.c
服务的标示
具体要几级完全取决于树级结构的实现方式及其合理的业务解释
- 解释一下：有些同学不清楚到底要设计几层:其实几层都可以，前提是你能给出一个较为合理的解释
命名规范一 三层 {产品组}.{项目}.{应用} group.project.app G.P.A- 其中g:代表提供相同大方向能力的一个team，比如
基础架构部 - 其中p:代表g中一个具体的项目，比如
监控 - 其中a:代表p中一个具体的应用，通常贴近运行时的应用，多个a可以立起一个p，比如
query - 上面的例子总结一下就是一个gpa：
infrastructure.monitor.query
资源和服务节点绑定关系
- 资源 资源绑定在服务/应用级别
- 即资源绑定在A上面，所有资源都围绕A
所以上面的G.P.A三段模型不能扩展成G.P.A.R
- 其中R代表region，因为有的资源无法绑定在R维度
- region只应该作为一个查询tag使用
资源和服务节点如何绑定
- 可以给资源记录打上G.P.A三个tag
服务树核心功能
- 说了半天了我们现在可以得出服务树核心功能包括：资源查询、资源管理、授权
- 其中
灵活的筛选业务与资源的关联关系是核心功能中的核心
查询
一个好的服务树查询组件应该支持业务/资源维度任何标签组合的结果
查询模式
- eq 等于 : key=value
- not_eq 不等于 : key!=value
- reg 正则匹配 : key=~value
- not_reg 正则非匹配 : key!~value
- 对比 : key> value几种查询举例
查询业务与资源的关系
- 举例1:查询a组下b项目使用ecs情况：得到结果是两个ecs
- 举例2:查询a组下b项目c应用使用elb情况
查询条件叠加一个标签的分布情况
- 举例1: 查询infrastructure.monitor.query项目中ecs按照规格分布情况，可以看到这个gpa的cluster标签有四个，展示他们的分布情况
根据资源元数据标签查询
- 举例1: 查询region region-a 使用ecs情况
复杂查询
- 举例1: 查询region为c，ip以10.10开头的，属于 infrastructure.monitor.query项目并且规格不是4c_8g的ecs列表
翻译成查询条件
其中type字段在代码中的对应关系为
资源统计功能
- 这个功能其实是查询延伸出来的，区别是查询是
被动而且局部的，资源统计是主动而且全局的 - 而且可以提供长时间的资源变化曲线:例如可以近看到一个月某个gpa按照某个标签的分布曲线
全局资源统计
查询gpa下属服务ecs按照云厂商分布
ecs特殊统计
按规格统计:可以看到几c几g
ecs核数
ecs内存g
管理
- 资源申请
- 资源流转
- 资源回收
授权
因为team可以绑定在g/p/a任意维度
- 举例： team-a：包含两个人(张三和李四)
- 有gp:infrastructure.monitor下属两个a为query和alert
- 可以将team-a和infrastructure.monitor.query绑定也可以绑定到
infrastructure.monitor上代表team-a拥有不同的权限
- 王五使用发布系统对infrastructure.monitor.query发布时，可以查看发布请求人王五是否在对应的授权team中来判断是否放行此次发布
权限分类
- 分类一：增删team中user的权限
- 分类二：查看gpa资源权限
- 分类三：管理gpa资源权限
未完待续。。。
有疑问加站长微信联系（非本文作者）
