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

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

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

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

必要性

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

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

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

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

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

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

便利性

如果程序要主動暴露內(nèi)部狀態(tài)，那么以哪種方式最為便利呢？當(dāng)然是 http。http 的好處有：

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

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

實例

演講當(dāng)時我舉了 google 的例子：

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

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

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

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

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

構(gòu)建易于維護的分布式程序