更多的服务全天候可用，更少的内存与 cpu 占用
在今年 3 月 20 号的时候，我有了一个设想：在我的那台小小的 2c2g 云服务器上跑我的所有设想，以后我分享的每篇文章，其中可能配套的一些网站服务，我的读者都可以随时去访问。
这里有一个难题，就是内存不够，我大多使用 Node 构建应用程序，一般而言一个服务的内存占用可能在 100MB 到 200MB 之间
2g 的内存只够支撑十来个服务，更别说其中有些服务，它内存占用峰值会到六七百兆，这更加限制了我的发挥，我只能时常清理掉之前萌发想法时部署的服务
于是这期间，我断断续续尝试去做这个东西。一开始是用 Node 实现的，但发现性能不是特别好，而且对于一些 socket 层面的转发，用 Node 不是很好实现。
直到最近，我终于用 AI 使用 RUST 实现了一版
类 serverless 服务管理：DynaPM
众所周知提供一个网站服务一般来说得先运行服务然后等用户访问
当我有一百个这样的服务都需要随时能让人可以访问，然后我的服务器内存也不足以容纳下这一百个服务同时运行，有什么办法可以在不增加服务器资源的情况下实现吗？
有的，兄弟有的，可以通过一层中间件来将先运行服务然后等用户访问反转变成用户来访问了再运行服务。
这种思路在程序中很常见，比如 lazy call 的懒加载思想/依赖反转。
核心思路很简单，其实就是做一个类似于网关的东西，用于动态启停实际运行的服务
由 DynaPM 监听对应端口，当请求到来时，根据 host 域名等查询配置表，判断属于哪个服务，再执行对应的服务拉起命令，等服务启动成功后，再将网络请求转发过去。
等闲置一段时间之后，再将服务 kill 掉。
所有服务启动跟关停的命令都是可自定义的，所以的话甚至于说可以用它来管理 Docker 服务，也就是任意的服务都可以使用它来进行管理
服务的冷启动时间只取决于服务本身，网关增加的耗时应该在只在几个毫秒
实际效果
像我这种开发者，我的服务可能并不是同时有那么多人访问，他们可能都是分散着时间段去访问不同的服务。也就是真正同时需要启动的服务可能是很少的
下面是我服务器过去 24 小时的一个实机运行的数据
从图中可以看到，大部分情况下同一时刻需要维持的服务可能只有两三个而已，使用 DynaPM 之后，我服务器的常态内存占用从 1G 多降低到了 550 兆,并且 CPU 的负载也降低了许多，之前可能常态在 5% 上下波动，现在能够降到 3%
代价是什么？
代价就是我访问服务的冷启动时间平均会延迟到 2 秒左右，这个主要看服务自身启动速度。我有一些 Rust 服务延迟是在 200 毫秒左右，基本上是用户无感知的。
更奇妙的想法
基于这个特性，我想到作为前端开发者，本地常挂着多个前端项目的开发，非常吃内存，且有些服务需要时不时手动运行。
如果改用这个管理，是不是就不需要手动启动服务了？
想要用的时候自然可用，平时也不会一直占用本地开发机内存，导致居高不下。
于是想想做就做，很快啊，也实现了。
用起来也是非常棒的，以后调试项目时，我能直接通过 dynapm 面板点击进入，并具备类似 portless 的特性。
这样我就不需要再记端口号，只需记住服务名，直接浏览器打开 项目名.localhost 即可访问 🎉
今天尝试了一下 dynapm.localhost 这种动态启停服务+portless 的特性 在 dev server 用起来真的很爽，再也不需要去对应项目执行 pnpm dev 了
此致，敬礼
1
Select Language