最近更新.rss.xml

基于这个特性，我想到作为前端开发者，本地常挂着多个前端项目的开发，非常吃内存，且有些服务需要时不时手动运行。

如果改用这个管理，是不是就不需要手动启动服务了？

想要用的时候自然可用，平时也不会一直占用本地开发机内存，导致居高不下。

于是想想做就做，很快啊，也实现了。

用起来也是非常棒的，以后调试项目时，我能直接通过dynapm面板点击进入，并具备类似 portless 的特性。

这样我就不需要再记端口号，只需记住服务名，直接浏览器打开 项目名.localhost 即可访问 🎉

此致，敬礼

此致，敬礼

这样我就不需要再记端口号，只需记住服务名，直接浏览器打开 项目名.localhost 即可访问 🎉

基于这个特性，我想到作为前端开发者，本地常挂着多个前端项目的开发，非常吃内存，且有些服务需要时不时手动运行。

用起来也是非常棒的，以后调试项目时，我能直接通过dynapm面板点击进入，并具备类似 portless 的特性。

于是想想做就做，很快啊，也实现了。

想要用的时候自然可用，平时也不会一直占用本地开发机内存，导致居高不下。

如果改用这个管理，是不是就不需要手动启动服务了？

代价就是我访问服务的冷启动时间平均会延迟到 2 秒左右，这个主要看服务自身启动速度。我有一些 Rust 服务延迟是在 200 毫秒左右，基本上是用户无感知的。

代价就是我访问服务的冷启动时间平均会延迟到 2 秒左右，这个主要看服务自身启动速度。我有一些 Rust 服务延迟是在 200 毫秒左右，基本上是用户无感知的。

像我这种开发者，我的服务可能并不是同时有那么多人访问，他们可能都是分散着时间段去访问不同的服务。也就是真正同时需要启动的服务可能是很少的

下面是我服务器过去24小时的一个实机运行的数据

​ ​

从图中可以看到，大部分情况下同一时刻需要维持的服务可能只有两三个而已，使用 DynaPM 之后，我服务器的常态内存占用从 1G 多降低到了 550 兆,并且 CPU 的负载也降低了许多，之前可能常态在 5% 上下波动，现在能够降到 3%

​ ​

从图中可以看到，大部分情况下同一时刻需要维持的服务可能只有两三个而已，使用 DynaPM 之后，我服务器的常态内存占用从 1G 多降低到了 550 兆,并且 CPU 的负载也降低了许多，之前可能常态在 5% 上下波动，现在能够降到 3%

​ ​

​ ​

下面是我服务器过去24小时的一个实机运行的数据

像我这种开发者，我的服务可能并不是同时有那么多人访问，他们可能都是分散着时间段去访问不同的服务。也就是真正同时需要启动的服务可能是很少的

服务的冷启动时间只取决于服务本身，网关增加的耗时应该在只在几个毫秒

众所周知提供一个网站服务一般来说得先运行服务然后等用户访问

当我有一百个这样的服务都需要随时能让人可以访问，然后我的服务器内存也不足以容纳下这一百个服务同时运行，有什么办法可以在不增加服务器资源的情况下实现吗？

有的，兄弟有的，可以通过一层中间件来将先运行服务然后等用户访问反转变成用户来访问了再运行服务。

这种思路在程序中很常见，比如 lazy call 的懒加载思想/依赖反转。

核心思路很简单，其实就是做一个类似于网关的东西，用于动态启停实际运行的服务

由 DynaPM 监听对应端口，当请求到来时，根据 host 域名等查询配置表，判断属于哪个服务，再执行对应的服务拉起命令，等服务启动成功后，再将网络请求转发过去。

等闲置一段时间之后，再将服务 kill 掉。

所有服务启动跟关停的命令都是可自定义的，所以的话甚至于说可以用它来管理 Docker 服务，也就是任意的服务都可以使用它来进行管理

服务的冷启动时间只取决于服务本身，网关增加的耗时应该在只在几个毫秒

众所周知提供一个网站服务一般来说得先运行服务然后等用户访问

当我有一百个这样的服务都需要随时能让人可以访问，然后我的服务器内存也不足以容纳下这一百个服务同时运行，有什么办法可以在不增加服务器资源的情况下实现吗？

有的，兄弟有的，可以通过一层中间件来将先运行服务然后等用户访问反转变成用户来访问了再运行服务。

这种思路在程序中很常见，比如 lazy call 的懒加载思想/依赖反转。

所有服务启动跟关停的命令都是可自定义的，所以的话甚至于说可以用它来管理 Docker 服务，也就是任意的服务都可以使用它来进行管理

等闲置一段时间之后，再将服务 kill 掉。

由 DynaPM 监听对应端口，当请求到来时，根据 host 域名等查询配置表，判断属于哪个服务，再执行对应的服务拉起命令，等服务启动成功后，再将网络请求转发过去。

核心思路很简单，其实就是做一个类似于网关的东西，用于动态启停实际运行的服务

直到最近，我终于用AI使用RUST实现了一版

于是这期间，我断断续续尝试去做这个东西。一开始是用 Node 实现的，但发现性能不是特别好，而且对于一些 socket 层面的转发，用 Node 不是很好实现。

2g 的内存只够支撑十来个服务，更别说其中有些服务，它内存占用峰值会到六七百兆，这更加限制了我的发挥，我只能时常清理掉之前萌发想法时部署的服务

这里有一个难题，就是内存不够，我大多使用 Node 构建应用程序，一般而言一个服务的内存占用可能在 100MB 到 200MB 之间

在今年3月20号的时候，我有了一个设想：在我的那台小小的2c2g云服务器上跑我的所有设想，以后我分享的每篇文章，其中可能配套的一些网站服务，我的读者都可以随时去访问。

更多的服务全天候可用，更少的内存与cpu占用

windows hyperV 外部交换机慢网速修复

claude code vscode扩展使用glm视觉mcp

​note​ https://z2h.cn/hanzi 字帖生成网站，田字格

​note​ 仿苹果液态玻璃效果

​note​ amd 利用 npu 的办法：https://ryzenai.docs.amd.com/en/latest/inst.html https://lemonade-server.ai/ https://github.com/amd/gaia?tab=readme-ov-file 主要还是 lemonade-server ，gaia 也是连接的 gaia （直接安装 gaia 会自动安装 lemonade-server

​好文推荐​ https://vue-bits.dev/ 非常绚酷的 vue 动画库

​好文推荐​ 浏览器插件开发最佳实践 https://wxt.dev/guide/installation.html

​好文推荐​ 前端开发的瓶颈与未来之路

用户不再需要了解什么是服务器，域名，大模型调用 等等概念，就可以构建出专属的应用，还能使用kimi的模型做一些ai应用功能，例如知识库问答，图片生成等

或许我可以做一个开源的这种docker应用？正好方便使用我的那个网关的能力

后来我接触到了 kimi 的 构建应用 这个功能，他很好的解决了一般用户不太懂编程的情况下如何构建自己的随时可用的专属应用和如何方便其他人使用的问题

我在今年也进行过这个方向的尝试，随着大模型的能力还在逐渐提升，这个未来不会太远了

ai 时代都在说以后可能是每个人都开发专属软件来解决自己的问题

​ ​ ​

​ ​

接入了 chrome devtools,尽可能获得和在chrome 中开发一致的debug体验

所以我让 AI 给我稍微出了一版 demo，这个也是几个月之前的事情了：https://2234839.github.io/eri-spec/

在这里演示了一下，怎么去嵌入一个三方应用去给 agent 去使用。

​ ​

我认为这也是一个以后可能的开发场景。

就是以后大家可能不是直接去访问某一个网站，而是在 AI 的对话中去访问这个网站所提供的一个组件（对应的 iframe）。

所以web前端永不死，整个 WEB 生态在 AI 时代会更加蓬勃发展

​ ​

前端永恒的话题 --- 低代码与高代码之战！