摘要:本篇博客没有新东西,只不过是把去年在珠三角技术沙龙做的一次演讲的其中一张 ppt 展开讲一讲。
本文标题中的“易于维护”指的是 supportability,不是 maintainability。前者是从运维人员角度说,程序管理起来很方便,日常的劳动负担小;后者是从开发人员的角度说,代码好读好改。
前文《分布式系统中的进程标识》我提到一个观点:分布式系统中的每个长期运行的、会与其他机器打交道的进程都应该提供一个管理接口,对外提供一个维修探查通道,可以查看进程的全部状态。一种具体的做法是在程序里内置 http 服务器。
今天展开谈一谈这么做的必要性。分成两个方面来说:1) 在服务程序内置监控接口的必要性;2) http 协议的便利性。
在程序中内置监控接口可以说是受了 Linux procfs 的启发。在 Linux 下,查看内核的状态不需要任何特殊的工具,只要用 ls 和 cat 在 /proc 目录下查看文件就行了。要知道当前系统中运行了哪些进程,每个进程都打开了哪些文件,进程的内存和 CPU 使用情况如何,每个进程启动了几个线程,当前有哪些 TCP 连接,每个网卡收发的字节数等等,都可以在 /proc 中找到答案。Linux Kernel 通过 procfs 这么一个探查接口把状态充分暴露出来,让监控操作系统的运行变得容易。
但是 procfs 也有两点明显的不足:
对于第一点,举例来说,我想知道某个我们自己编写的服务进程的运行情况:
这些正当需求只有通过程序主动暴露状态才能满足,否则,就算 ssh 登录到这台机器上,也看不到这些有用的进程内部信息。(总不能 gdb attach 吧?那就让服务进程暂停响应了。且不说 gdb 打印一个 hashmap 有多麻烦。)
如果程序要主动暴露内部状态,那么以哪种方式最为便利呢?当然是 http。http 的好处有:
另外,我们讨论分布式系统是运行在企业防火墙之内的基础设施,http 的安全性应该由防火墙保证。就好比你的 hadoop master 和 memcached 不会暴露给外网一样,在公司内部使用 http 只要没有人故意搞破坏就没事。
演讲当时我举了 google 的例子:
当然,我们看不到 google 内部的服务器的状态页面究竟是什么样子,不过可以看看别的例子,比如 Hadoop。Hadoop 有四种主要 services:NameNode, DataNode, JobTracker, TaskTracker。每种 service 都内置了 http 状态页面,其默认 http 端口分别是:
如果某台机器运行了 DataNode 和 TaskTracker,那么我们可以通过 http://hostname:50075 和 http://hostname:50060 来方便地查询其运行状态。
如果不方便内置 http 服务,那么内置一个简单的 telnet 服务也不难,就像 memcached 的 stats 命令那样。
相反,如果不在程序开发的时候统一预留这些维修通道,那么运维起来就抓瞎了——每个进程都是黑盒子,出点什么情况都得拼命查 log 试图恢复(猜测)进程的状态,工作效率极低。