最近，公司进行了新的架构设计，原来一个区服一组进程，变成了对外只有一台服，后面N组多进程进行服务的模式。于是，管理进程就变成了一个头痛的问题。原来是在写代码的目录里放置各种脚本解决的，关闭脚本，开启脚本，重启脚本，更新脚本，还有一打用来看各种日志的脚本。这些脚本还是严重目录相关的，要执行某些命令，只能cd到指定目录执行（或者用硬连接+设置脚本所在目录为当前目录解决？whatever）。遇到实际部署的时候，还需要ssh到指定机器上，运行指定脚本，有时候还担心服务器起不来，需要人肉ssh过去看status或者tail日志看。

现在，有supervisor，将所有这些烦恼一扫而光！supervisor有两个组件：supervisord和supervisorctl，组成了client/server结构。supervisord负责读入配置文件，然后以子进程方式启动配置中定义的程序，将对应的program进行后台化（daemonize）处理。supervisorctl则负责和supervisord进行沟通，获取运行中的进程信息，包含pid，uptime等信息。supervisorctl既可以通过命令行参数进行控制，又能够直接进入一个特有的shell，通过这个shell管控进程组。这样，既能够让部分同学准确把握进程状况，又能避免放开shell权限，一举多得。

以前做服务器逻辑的多并发，采用gevent可以很自然对应到逻辑上的并发微线程，但是处理部分游戏逻辑，需要用到锁，有时候还需要跨进程的锁。所以，当时一直很渴望有个网关进程顶在前头，将网络通信先行串行化，然后后台跑起多个不同工作任务的进程，消化不同的数据包。这样，每个进程处理的任务简单，比较容易做到正确和高效。然后没有并发事件，可以避免锁。现在想来，其实这种架构，是将部分业务逻辑的压力，压在了多进程上，名曰“分布式处理”，实际运行时，对进程的管控需求会提高，增加了运行时管理的难度。比如，一般需要一个master管理这种异质进程，控制其生生灭灭。

使用supervisor，可以简化进程管理这方面的压力。但是，部分跟业务逻辑相关的进程生命周期，还是需要主动干预。哪些情况下，进程被关闭是正常，什么情况下需要重启进程，还是需要费心搞清楚的。幸而supervisor给了一个不错的思路。剩下的就是多服务器配置的生成和管理了，希望能找到可靠的开源工具。