构建易于维护的分布式程序

清疚 2022-09-30 00:46 101阅读 0赞

陈硕 (giantchen\_AT\_gmail)

Blog.csdn.net/Solstice

摘要：本篇博客没有新东西，只不过是把去年[在珠三角技术沙龙做的一次演讲][Link 1]的其中一张 ppt 展开讲一讲。

本文标题中的“易于维护”指的是 supportability，不是 maintainability。前者是从运维人员角度说，程序管理起来很方便，日常的劳动负担小；后者是从开发人员的角度说，代码好读好改。

前文《[分布式系统中的进程标识][Link 2]》我提到一个观点：**分布式系统中的每个长期运行的、会与其他机器打交道的进程都应该提供一个管理接口，对外提供一个维修探查通道，可以查看进程的全部状态**。一种具体的做法是在程序里内置 http 服务器。

![embedhttp][]

今天展开谈一谈这么做的必要性。分成两个方面来说：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，可以远程访问，不必登录到这台机器上
 *  TCP server 的另一个好处是能安全方便地防止程序重复启动，这个已在前文有论述。
 *  最基本的 http 协议的实现起来很简单，不会给服务端程序带来多大负担，见 muduo::net::HttpServer 的例子
 *  不必使用特定的客户端程序，用普通 web 浏览器就能访问
 *  可以比较容易地用脚本语言实现客户端，便于自动化的状态收集与分析
 *  http 是文本协议，紧急情况下在命令行用 telnet 甚至 wget 也能访问（比方说你在家通过 ssh 连到公司服务器解决某个线上问题，这时候没有 web 浏览器可用）
 *  借助 http URL 的路径，很容易实现有选择地查看一些信息，而不是把进程的全部状态一股脑儿 dump 出来，见 muduo::net::Inspector 的例子
 *  http 天生支持聚合，一个浏览器页面可以内置多个 iframe，一眼就能看清多个进程的状态
 *  除了 GET method，如果有必要，还可以实现 PUT/POST/DELETE，通过 http 协议来控制并修改进程的状态，让程序“能观能控”（“能观”“能控”是自动控制领域的术语，这里借用一下）
 *  必要的时候还可以用 rest 的方式实现高级的聚合，见我在演讲中的“一种 REST 风格的监控”

另外，我们讨论分布式系统是运行在企业防火墙之内的基础设施，http 的安全性应该由防火墙保证。就好比你的 hadoop master 和 memcached 不会暴露给外网一样，在公司内部使用 http 只要没有人故意搞破坏就没事。

## 实例 ##

演讲当时我举了 google 的例子：

[![google][]][google 1]

当然，我们看不到 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_50075] 和 [http://hostname:50060][http_hostname_50060] 来方便地查询其运行状态。

## 例外 ##

如果不方便内置 http 服务，那么内置一个简单的 telnet 服务也不难，就像 memcached 的 stats 命令那样。

如果服务程序本身以 RPC 方式提供服务，那么可以不必内置 http 服务，而是增加一个 RFC 调用实现相同的功能。这个 RPC 可以命名为 admin()，输入的内容类似 url，返回的是该 url 对应的页面内容，可以是文本格式，也可以是 RPC 原生的打包格式。

## 总结 ##

在自己编写分布式程序的时候，提供一个维修通道是很有必要的，它能帮助日常运维，而且在出现故障的时候帮助排查。相反，如果不在程序开发的时候统一预留这些维修通道，那么运维起来就抓瞎了——每个进程都是黑盒子，出点什么情况都得拼命查 log 试图恢复（猜测）进程的状态，工作效率极低。

[Link 1]: http://blog.csdn.net/Solstice/archive/2010/10/19/5950190.aspx
[Link 2]: http://blog.csdn.net/Solstice/archive/2011/03/29/6285216.aspx
[embedhttp]: /images/20220708/5de499e73dd743c09e9c6909d290b543.png
[google]: /images/20220708/27213318aa3f4fe48194d77511d2109f.png
[google 1]: http://hi.csdn.net/attachment/201103/29/0_1301414607xyKm.gif
[http_hostname_50075]: http://hostname:50075
[http_hostname_50060]: http://hostname:50060