说起来，距离简书小工具集的上一次更新，已经有三个多月了。

这段时间，我一直在思考，应该增加什么新功能，才能最大程度满足大家的需要。

但前几天我偶然查看服务器状态时，发现这个服务占用的内存有点不符合它的体量。

作为一个无状态、仅仅提供几个网页服务的应用，它的内存占用甚至超过了风语。

要知道，风语是一个涵盖网页服务、数据采集、数据分析、任务调度、服务监控的应用，而且由于开发时间不充裕，并没有针对资源用量做优化。

看来，要对这个服务进行一些优化了，但在阐述优化思路之前，还是先看看这个版本有什么变动吧。

哦对，点击链接访问“简书小工具集”：http://120.27.239.120:8602

画图库更改为 Pyecharts

在 v1.3.0 之前，简书小工具集中的图表使用的是一个叫做 Plotly 的库，这个库的资源文件地址在国内不太稳定，导致经常有用户反映看不到图表。

另外，这个库对客户端的内存占用量也比较大，等到越来越多的服务模块加入，有大量数据展示的需求时，这个库就不太够用了。

经过一番探索，我们选择了 Pyecharts 作为替代方案。

现在，用户资产查询工具的图表是这样的：

[图片上传失败...(image-196eec-1653061439984)]

也许你已经发现了，鼠标悬浮在图表上方可以查看对应类别的详细信息。

性能优化

其实每个版本或多或少都会有性能优化，但这个版本的优化是大家能明显感觉到的。

给大家看一眼提交记录（红色删除，绿色增加，单位是代码行数）：

[图片上传失败...(image-308284-1653061439984)]

其实几乎每个模块我们都做了优化。

这次优化中，性能提升最大的是消零派辅助工具，100 条记录的情况下，数据获取时间从原先的近 10 秒提升到 4 秒。

这一模块最耗时的部分是数据获取，以前的流程大概是这样的：

• 从每个选择的专题中获取一定量数据
• 进行数据格式转化，使其便于处理
• 对数据应用筛选条件（点赞量、评论量等）
• 取前 n 条数据（n 为设置的结果数量）
• 返回数据，进入展示阶段

现在的逻辑是这样的：

• 从每个选择的专题中获取一定量数据，在获取数据的过程中
  • 进行筛选，如果满足所有条件，则将这条数据加入展示列表
  • 对展示列表长度进行判断，如果已达到结果数量，则停止数据获取
• 返回数据，进入展示阶段

很明显，优化后的逻辑大大减少了网络请求的次数，同时也在一定程度上降低了这一模块的内存占用。

稳定性优化

同样的，每个版本都或多或少有稳定性优化，但这个版本的稳定性可以说得到了非常大的提升，因为我们使用了容器部署。

这也是我们所有项目中，第一个使用容器部署的服务。

如果你没做过开发（或者是前端），可能不知道什么是容器，简单来说，容器就是一个虚拟机，其中运行着完整的操作系统，当然，我们也可以在上面运行程序。

那为什么容器部署提升了稳定性呢？

首先，它大大降低了由于依赖环境导致的问题，本地和服务器上的环境可以完全一致。

其次，容器是可以集中管理的，可以设置在崩溃后自动重启，或者指定它能占用的资源上限，避免一个服务出现问题影响到其它服务。

最后，容器环境与外部是隔离的，即使我在容器内执行了 sudo rm -rf /*，容器外也是平安无事，只需重新创建一个容器，服务就会恢复。

面向开发者的变动

这些是简书小工具集背后的变动，用户感知不强。

• 服务端口现在可以在配置文件中设置
• 依赖管理工具由 Pipenv 更换为 Poetry
• 使用 JRT 的面向对象封装重写部分逻辑
• 将服务列表抽取为常量
• 移除了 Pandas、Plotly 和 WordCloud 三个依赖

一些技术思路

为什么要选择 Pyecharts 作为替代品

Plotly 曾是我做数据分析时很常用的画图工具，当数据量达到几万时，绘制几张简单的图表后，VS Code 的内存占用就达到了 2.5GB 甚至更高。

当然，基于 Election 的软件本质上是网页，内存占用比较大是正常的，但当我写下这篇文章时，我的 VS Code 同时打开了创作文件夹和简书小工具集的项目文件夹，内存占用是这样的：

[图片上传失败...(image-b2ca07-1653061439984)]

使用过 VS Code 的小伙伴知道，VS Code 强大的功能很大程度上依赖于插件实现，而在简书小工具集的项目文件夹中，我启用了这些插件：

[图片上传失败...(image-48e7a9-1653061439984)]

所以，Plotly 真就一张图顶五个插件的内存占用。

为什么用 Poetry 替代 Pipenv

首先，Pipfile 过时了，pyproject.toml 是现在推荐的依赖管理文件。

其次，Pipenv 的依赖安装实在太慢了，每次添加依赖都要运行一次 lock 生成哈希值，而且不知道是不是我的配置问题，我执行 pipenv shell 后进入的终端环境不能通过上下键查看历史命令。

最后，Poetry 同时支持项目管理、依赖管理、打包发布，不需要我手动 build，一行命令就可以生成 .whl 文件并上传到 Pypi。虽然这个项目用不到，但只用一个工具解决三个痛点绝对值得。

我推荐大家去尝试一下 Poetry。

为什么用这个项目作为容器部署的尝试

这个项目的访问量不算很大，一旦出现问题，可以立刻切换到原先的版本，毕竟我接触容器部署的时间不长，不敢保证第一次部署就能成功。

另外，这是一个无状态的服务，不需要挂载目录，依赖也比较简单，其实我干掉 Pandas 和 Plotly 这两个大头，有一部分考虑就是缩减镜像体积。

不过部署之后发现服务完全正常，内存占用也没有超出限制，我直接删掉了原先版本的目录，然后看了一会 podman stats，就放心做其它事去了。

至于为什么不用 Docker，首先，Podman 没有守护进程，资源占用也比 Docker 少一点、，再加上两者的镜像和大部分命令可以通用，并且有些 Linux 发行版已经默认安装了 Podman，我认为这是一种趋势。

关于这个系列

每当有服务发布新的功能版本时，我都会发一篇更新日志，讲讲新版本的变化，以及我的实现思路。

还是老样子，技术人去 GitHub Repo 开 Issue，非技术人发评论，其乐融融。