隨著線上業(yè)務越來越復雜, 服務越來越多, 系統(tǒng)結構也越來越復雜, 如下幾個問題浮出水面:
- 知識管理混亂
- 系統(tǒng)結構太復雜, 僅僅有幾個
資深開發(fā)才了解, 唯一的'架構圖'是N個月前資深同事分享的時候畫的, 早已過時 - 新人學習成本太高, 看過時的架構圖/讀源代碼
- 老員工離職, 如何快速接盤? 這個話題可以寫一本書. 但核心問題是知識管理.
- 系統(tǒng)結構太復雜, 僅僅有幾個
- 單一服務報警, on-call 工程師無法準確評估是否下游服務會受影響, 或者是哪些上游服務有問題
- 例如, 某服務 rps 急劇下降, 但on-call 工程師甚至都搞不清楚都有哪些系統(tǒng)在調用該接口, 更別提判斷是哪個系統(tǒng)的問題. 只有在'線上救火群'里大吼, 叫各個服務的工程師起床檢查是否是自己系統(tǒng)的問題, 這簡直就是
全民 on-call的節(jié)奏
- 例如, 某服務 rps 急劇下降, 但on-call 工程師甚至都搞不清楚都有哪些系統(tǒng)在調用該接口, 更別提判斷是哪個系統(tǒng)的問題. 只有在'線上救火群'里大吼, 叫各個服務的工程師起床檢查是否是自己系統(tǒng)的問題, 這簡直就是
- 系統(tǒng)架構改造/review 無參考
- 系統(tǒng)改造第一件事: 叫各個系統(tǒng)開發(fā), 一起在黑板前畫系統(tǒng)結構. 人要叫齊, 要不有遺漏中途改方案好痛苦
- 大型推廣活動上線前, 做系統(tǒng)容量評估/規(guī)劃, 無統(tǒng)一參考.
- 系統(tǒng)架構更改, 如何廣而告之
- 也屬于知識管理范疇, 但覺得應該單獨拎出來
明確了問題, 看看我們有哪些方案可選
方案一: 引入類似 Dapper 的 trace 系統(tǒng)
核心思路就是每次 request 帶著一個唯一 ID, 每個系統(tǒng)收到后寫日志, 后續(xù)分析系統(tǒng)依賴. 開源實現由很多, 例如 CAT, pinpoint等. 引入這些系統(tǒng)對 troubleshooting 也有很大幫助.
但也有幾個問題無法解決:
- 多語言. 沒有看到一個 framework 能夠涵蓋各種語言. 我廠使用的語言有: Java, Ruby, Go, C++
- 無法解決知識管理問題. 僅僅是線上系統(tǒng)拓撲
- 僅僅標記依賴資源類型, 沒有具體資源
- 比如, 標識哪個 MySQL 數據庫, 哪個 Kafka Topic.
方案二: 使用 Agent 分析協(xié)議, 識別系統(tǒng)拓撲和資源
既然 Dapper 類似的系統(tǒng)無法解決問題, 直接開啟'上帝視角'通過抓包分析協(xié)議不就行了?
然而, 現實是骨感的:
- 實現難度大, 各個系統(tǒng)的協(xié)議都要重新實現一番
- 加密協(xié)議如何解?
ROI 太低. 放棄. 不過前幾天去灣區(qū)參加 Spark Summit 2016, 在展臺發(fā)現一家創(chuàng)業(yè)公司 OpsClarity 正式用分析協(xié)議的方式實現了服務拓撲管理. 當然, 他們的產品沒有這么簡單. 跟他們聊天發(fā)現, 資源識別的粒度他們也沒有做到很精細, 比如僅僅識別了 Kafka, 但具體是哪個 topic 卻沒有實現.
OpsClarity 宣傳圖
方案三: 結構化文本 + 版本管理 + code review + 可視化
既然協(xié)議分析 ROI 太低. 是不是可以參考 CloudFormation, 實現一個結構化文本方式描述服務的系統(tǒng)? 比如配置文件:
{
"name": "系統(tǒng)名稱, 唯一",
"desc": "系統(tǒng)簡介",
"links": [
{
"monitor": "監(jiān)控系統(tǒng)鏈接"
},
{
"wiki": "wiki 系統(tǒng)鏈接"
}
],
"resources": [
# 這里是系統(tǒng)暴露的資源, 例如 MySQL DB, Kafka topic, AWS S3 bucket 等
],
"depends-on": [
# 這里該服務所依賴的服務. 例如: RDS 數據庫.
{"name": "aws-rds.rds-name.db-name"},
{"name": "其他系統(tǒng)"}
]
}
具體實現思路如下:
- 通過結構化文本(或者 python 文件, 類似 airflow 實現方式), 描述服務的依賴, 鏈接等
- 結構化文本放在 git 中做版本控制, 改動后通過 code review 流程, 讓其他開發(fā)review.
- 通過文件夾形式, 組織服務描述文本
- 通過客戶端工具, 校驗配置文件是否合法
- 依賴是否正確
- 鏈接知否正確
- 通過 web ui, 展示渲染后的服務拓撲圖
- 通過搜索等功能, 提高易用性
- 通過 API 方式, 整合報警, 讓 on-call 工程師清晰知道直接系統(tǒng)依賴
- 通過 Cubism 重構監(jiān)控系統(tǒng), 整合系統(tǒng)拓撲, 定位系統(tǒng)問題
總結
這個系統(tǒng)我已經思考了一段時間, 中途去 Spark Summit 2016 偶遇 OpsClarity, 進一步整理了思路. 找時間把 demo 實現出來, 用一用, 再看大家反饋吧.
-- EOF --
