说起来，距离简书小工具集的上一次更新，已经有三个多月了。
这段时间，我一直在思考，应该增加什么新功能，才能最大程度满足大家的需要。
但前几天我偶然查看服务器状态时，发现这个服务占用的内存有点不符合它的体量。
作为一个无状态、仅仅提供几个网页服务的应用，它的内存占用甚至超过了风语。
要知道，风语是一个涵盖网页服务、数据采集、数据分析、任务调度、服务监控的应用，而且由于开发时间不充裕，并没有针对资源用量做优化。
看来，要对这个服务进行一些优化了，但在阐述优化思路之前，还是先看看这个版本有什么变动吧。
哦对，点击链接访问“简书小工具集”：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，非技术人发评论，其乐融融。
