摘要：本篇博客沒有新東西，只不過是把去年 在珠三角技術沙龍做的一次演講 的其中一張 ppt 展開講一講。

本文標題中的“易于維護”指的是 supportability，不是 maintainability。前者是從運維人員角度說，程序管理起來很方便，日常的勞動負擔小；后者是從開發人員的角度說，代碼好讀好改。

前文《 分布式系統中的進程標識 》我提到一個觀點： 分布式系統中的每個長期運行的、會與其他機器打交道的進程都應該提供一個管理接口，對外提供一個維修探查通道，可以查看進程的全部狀態 。一種具體的做法是在程序里內置 http 服務器。

今天展開談一談這么做的必要性。分成兩個方面來說：1) 在服務程序內置監控接口的必要性；2) http 協議的便利性。

必要性

在程序中內置監控接口可以說是受了 Linux procfs 的啟發。在 Linux 下，查看內核的狀態不需要任何特殊的工具，只要用 ls 和 cat 在 /proc 目錄下查看文件就行了。要知道當前系統中運行了哪些進程，每個進程都打開了哪些文件，進程的內存和 CPU 使用情況如何，每個進程啟動了幾個線程，當前有哪些 TCP 連接，每個網卡收發的字節數等等，都可以在 /proc 中找到答案。Linux Kernel 通過 procfs 這么一個探查接口把狀態充分暴露出來，讓監控操作系統的運行變得容易。

但是 procfs 也有兩點明顯的不足：

• 它只能暴露 system-wide 的數據，不能查看每個進程內部的數據；
• 它是本地文件系統，必須要登錄到這臺機器上才能查看，如果要管理有很多臺機器，勢必增加工作量。

對于第一點，舉例來說，我想知道某個我們自己編寫的服務進程的運行情況：

• 到目前為止累計接受了多少個 TCP 連接
• 當前有多少活動連接 （這個可以通過 procfs 查看）
• 一共響應了多少次請求
• 每次請求的平均輸入輸出數據長度是多少字節
• 每次請求的平均響應時間是多少毫秒
• 進程平均有多少個活動請求（并發請求）
• 并發請求數的峰值是多少，出現在什么時候
• 某個連接上平均有多少個活動請求
• 進程中 XXXRequest 對象有多少份實例
• 進程中打開了多少個數據庫連接，每個連接的存活時間是多少
• 程序中有一個 hashmap，保存了當前的活動請求，我想把它打印出來
• 某個請求似乎卡在某個步驟了，我想打印進程中該請求的狀態

這些正當需求只有通過程序主動暴露狀態才能滿足，否則，就算 ssh 登錄到這臺機器上，也看不到這些有用的進程內部信息。（總不能 gdb attach 吧？那就讓服務進程暫停響應了。且不說 gdb 打印一個 hashmap 有多麻煩。）

便利性

如果程序要主動暴露內部狀態，那么以哪種方式最為便利呢？當然是 http。http 的好處有：

• 它是 TCP server，可以遠程訪問，不必登錄到這臺機器上
• 最基本的 http 協議的實現起來很簡單，不會給服務端程序帶來多大負擔，見 muduo::net::HttpServer 的例子
• 不必使用特定的客戶端程序，用普通 web 瀏覽器就能訪問
• 可以比較容易地用腳本語言實現客戶端，便于自動化的狀態收集與分析
• http 是文本協議，緊急情況下在命令行用 telnet 甚至 wget 也能訪問（比方說你在家通過 ssh 連到公司服務器解決某個線上問題，這時候沒有 web 瀏覽器可用）
• 借助 http URL 的路徑，很容易實現有選擇地查看一些信息，而不是把進程的全部狀態一股腦兒 dump 出來，見 muduo::net::Inspector 的例子
• http 天生支持聚合，一個瀏覽器頁面可以內置多個 iframe，一眼就能看清多個進程的狀態
• 必要的時候還可以用 rest 的方式實現高級的聚合，見我在演講中的“一種 REST 風格的監控”

另外，我們討論分布式系統是運行在企業防火墻之內的基礎設施，http 的安全性應該由防火墻保證。就好比你的 hadoop master 和 memcached 不會暴露給外網一樣，在公司內部使用 http 只要沒有人故意搞破壞就沒事。

實例

演講當時我舉了 google 的例子：

當然，我們看不到 google 內部的服務器的狀態頁面究竟是什么樣子，不過可以看看別的例子，比如 Hadoop。Hadoop 有四種主要 services：NameNode, DataNode, JobTracker, TaskTracker。每種 service 都內置了 http 狀態頁面，其默認 http 端口分別是：

• NameNode 50070
• DataNode? 50075
• JobTracker? 50030
• TaskTracker? 50060

如果某臺機器運行了 DataNode 和 TaskTracker，那么我們可以通過? http://hostname:50075 ?和? http://hostname:50060 ?來方便地查詢其運行狀態。

如果不方便內置 http 服務，那么內置一個簡單的 telnet 服務也不難，就像 memcached 的 stats 命令那樣。

相反，如果不在程序開發的時候統一預留這些維修通道，那么運維起來就抓瞎了——每個進程都是黑盒子，出點什么情況都得拼命查 log 試圖恢復（猜測）進程的狀態，工作效率極低。

構建易于維護的分布式程序