服务治理的一些思考

随着线上业务越来越复杂, 服务越来越多, 系统结构也越来越复杂, 如下几个问题浮出水面:

  • 知识管理混乱
    • 系统结构太复杂, 仅仅有几个资深开发才了解, 唯一的'架构图'是N个月前资深同事分享的时候画的, 早已过时
    • 新人学习成本太高, 看过时的架构图/读源代码
    • 老员工离职, 如何快速接盘? 这个话题可以写一本书. 但核心问题是知识管理.
  • 单一服务报警, on-call 工程师无法准确评估是否下游服务会受影响, 或者是哪些上游服务有问题
    • 例如, 某服务 rps 急剧下降, 但on-call 工程师甚至都搞不清楚都有哪些系统在调用该接口, 更别提判断是哪个系统的问题. 只有在'线上救火群'里大吼, 叫各个服务的工程师起床检查是否是自己系统的问题, 这简直就是全民 on-call 的节奏
  • 系统架构改造/review 无参考
    • 系统改造第一件事: 叫各个系统开发, 一起在黑板前画系统结构. 人要叫齐, 要不有遗漏中途改方案好痛苦
    • 大型推广活动上线前, 做系统容量评估/规划, 无统一参考.
  • 系统架构更改, 如何广而告之
    • 也属于知识管理范畴, 但觉得应该单独拎出来

明确了问题, 看看我们有哪些方案可选


方案一: 引入类似 Dapper 的 trace 系统

核心思路就是每次 request 带着一个唯一 ID, 每个系统收到后写日志, 后续分析系统依赖. 开源实现由很多, 例如 CAT, pinpoint等. 引入这些系统对 troubleshooting 也有很大帮助.
但也有几个问题无法解决:

  • 多语言. 没有看到一个 framework 能够涵盖各种语言. 我厂使用的语言有: Java, Ruby, Go, C++
  • 无法解决知识管理问题. 仅仅是线上系统拓扑
  • 仅仅标记依赖资源类型, 没有具体资源
    • 比如, 标识哪个 MySQL 数据库, 哪个 Kafka Topic.

方案二: 使用 Agent 分析协议, 识别系统拓扑和资源

既然 Dapper 类似的系统无法解决问题, 直接开启'上帝视角'通过抓包分析协议不就行了?
然而, 现实是骨感的:

  • 实现难度大, 各个系统的协议都要重新实现一番
  • 加密协议如何解?

ROI 太低. 放弃. 不过前几天去湾区参加 Spark Summit 2016, 在展台发现一家创业公司 OpsClarity 正式用分析协议的方式实现了服务拓扑管理. 当然, 他们的产品没有这么简单. 跟他们聊天发现, 资源识别的粒度他们也没有做到很精细, 比如仅仅识别了 Kafka, 但具体是哪个 topic 却没有实现.

OpsClarity 宣传图
OpsClarity 宣传图


方案三: 结构化文本 + 版本管理 + code review + 可视化

既然协议分析 ROI 太低. 是不是可以参考 CloudFormation, 实现一个结构化文本方式描述服务的系统? 比如配置文件:

{
  "name": "系统名称, 唯一",
  "desc": "系统简介",
  "links": [
    {
      "monitor": "监控系统链接"
    },
    {
      "wiki": "wiki 系统链接"
    }
  ],
  "resources": [
# 这里是系统暴露的资源, 例如 MySQL DB, Kafka topic, AWS S3 bucket 等
  ],
  "depends-on": [
# 这里该服务所依赖的服务. 例如: RDS 数据库.
    {"name": "aws-rds.rds-name.db-name"},
    {"name": "其他系统"}
  ]
}

具体实现思路如下:

  1. 通过结构化文本(或者 python 文件, 类似 airflow 实现方式), 描述服务的依赖, 链接等
  2. 结构化文本放在 git 中做版本控制, 改动后通过 code review 流程, 让其他开发review.
  3. 通过文件夹形式, 组织服务描述文本
  4. 通过客户端工具, 校验配置文件是否合法
  • 依赖是否正确
  • 链接知否正确
  1. 通过 web ui, 展示渲染后的服务拓扑图
  • 通过搜索等功能, 提高易用性
  1. 通过 API 方式, 整合报警, 让 on-call 工程师清晰知道直接系统依赖
  2. 通过 Cubism 重构监控系统, 整合系统拓扑, 定位系统问题

总结

这个系统我已经思考了一段时间, 中途去 Spark Summit 2016 偶遇 OpsClarity, 进一步整理了思路. 找时间把 demo 实现出来, 用一用, 再看大家反馈吧.

-- EOF --

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,980评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,178评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,868评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,498评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,492评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,521评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,910评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,569评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,793评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,559评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,639评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,342评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,931评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,904评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,144评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,833评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,350评论 2 342

推荐阅读更多精彩内容