随着线上业务越来越复杂, 服务越来越多, 系统结构也越来越复杂, 如下几个问题浮出水面:
- 知识管理混乱
- 系统结构太复杂, 仅仅有几个
资深
开发才了解, 唯一的'架构图'是N个月前资深
同事分享的时候画的, 早已过时 - 新人学习成本太高, 看过时的架构图/读源代码
- 老员工离职, 如何快速接盘? 这个话题可以写一本书. 但核心问题是知识管理.
- 系统结构太复杂, 仅仅有几个
- 单一服务报警, on-call 工程师无法准确评估是否下游服务会受影响, 或者是哪些上游服务有问题
- 例如, 某服务 rps 急剧下降, 但on-call 工程师甚至都搞不清楚都有哪些系统在调用该接口, 更别提判断是哪个系统的问题. 只有在'线上救火群'里大吼, 叫各个服务的工程师起床检查是否是自己系统的问题, 这简直就是
全民 on-call
的节奏
- 例如, 某服务 rps 急剧下降, 但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 却没有实现.
方案三: 结构化文本 + 版本管理 + 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": "其他系统"}
]
}
具体实现思路如下:
- 通过结构化文本(或者 python 文件, 类似 airflow 实现方式), 描述服务的依赖, 链接等
- 结构化文本放在 git 中做版本控制, 改动后通过 code review 流程, 让其他开发review.
- 通过文件夹形式, 组织服务描述文本
- 通过客户端工具, 校验配置文件是否合法
- 依赖是否正确
- 链接知否正确
- 通过 web ui, 展示渲染后的服务拓扑图
- 通过搜索等功能, 提高易用性
- 通过 API 方式, 整合报警, 让 on-call 工程师清晰知道直接系统依赖
- 通过 Cubism 重构监控系统, 整合系统拓扑, 定位系统问题
总结
这个系统我已经思考了一段时间, 中途去 Spark Summit 2016 偶遇 OpsClarity, 进一步整理了思路. 找时间把 demo 实现出来, 用一用, 再看大家反馈吧.
-- EOF --