服务治理的一些思考

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

• 知识管理混乱
  • 系统结构太复杂, 仅仅有几个资深开发才了解, 唯一的'架构图'是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 宣传图

---

方案三: 结构化文本 + 版本管理 + 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 --