技术债与风险

最高风险：Python C API 代际断裂

代码中大量使用以下 Python 2 C API：

• PyString_*
• PyInt_*
• Py_InitModule
• cPickle

这些接口在 Python 3 中要么被删除，要么语义发生变化。

风险结论：

• 这不是低成本兼容层问题。
• 需要系统替换为 PyUnicode_*、PyLong_*、模块初始化新机制等。

第二风险：解释器版本历史债叠加

仓库呈现出两个历史层次：

• third_party/python 内嵌的是 Python 2.7.x
• build/make/discover_python.sh 仍保留 Python 2.4 的兼容探测逻辑

这说明项目在不同年代逐步演化，部分脚本与工具链没有同步清理。

风险结论：

• 构建脚本可能含有过时假设。
• 文档与真实运行路径可能不一致。

第三风险：第三方 Python 包全部过旧

目前可见的关键 Python 附加依赖版本非常老：

• oursql 0.9.2
• SQLAlchemy 0.6.6
• Pympler 0.3.0
• pika 0.9.13

风险结论：

• 大概率无法直接运行在新版 Python 运行时。
• 某些包可能已经无人维护，需要替代方案。

第四风险：构建环境绑定 CentOS 7

Docker 构建和 README 都强烈绑定：

• CentOS 7
• 老版系统依赖
• 老版编译工具和兼容头文件

新版 Python 运行时和当前工具链往往会牵动编译器、OpenSSL 和系统库版本。

风险结论：

• Python 运行时迁移往往会连带触发 OS 基线升级。
• 若继续坚持 CentOS 7，会显著增加构建难度。

第五风险：客户端与工具链同样依赖 Python

不是只有服务端受影响。客户端和编辑器中同样存在大量：

• PyRun_SimpleString
• PyString_AsString
• PyInt_AsLong

风险结论：

• 迁移范围至少覆盖服务端、客户端和编辑器公共桥接层。
• 如果只改服务端，最终会形成双运行时割裂。

第六风险：文档与源码存在漂移

已经发现至少一个路径级漂移：

• 配置引用的 control_cluster.py 不在仓库中

风险结论：

• 在任何升级工作前，先做可构建、可运行、可部署的基线核查。
• 否则后续所有迁移评估都可能建立在错误前提上。

结论

当前技术债不是“某几个模块老旧”，而是：

• 构建系统老旧
• 平台假设老旧
• Python API 老旧
• 第三方包老旧
• 文档与工程状态部分漂移

因此最合理的策略不是直接硬切运行时版本，而是分层解耦、逐步迁移。