陈硕的 Blog

吾尝终日而思矣,不如须臾之所学也。吾尝跂而望矣,不如登高之博见也。……君子生非异也,善假于物也。

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

陈硕 (giantchen_AT_gmail)

Blog.csdn.net/Solstice

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

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

前文《分布式系统中的进程标识》我提到一个观点:分布式系统中的每个长期运行的、会与其他机器打交道的进程都应该提供一个管理接口,对外提供一个维修探查通道,可以查看进程的全部状态。一种具体的做法是在程序里内置 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 内部的服务器的状态页面究竟是什么样子,不过可以看看别的例子,比如 Hadoop。Hadoop 有四种主要 services:NameNode, DataNode, JobTracker, TaskTracker。每种 service 都内置了 http 状态页面,其默认 http 端口分别是:

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

如果某台机器运行了 DataNode 和 TaskTracker,那么我们可以通过 http://hostname:50075http://hostname:50060 来方便地查询其运行状态。

例外

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

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

总结

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

posted on 2011-03-30 00:03 陈硕 阅读(...) 评论(...) 编辑 收藏

导航

统计

公告