修改符号链接指向目录对运行中应用的影响及部署架构咨询

背景 #

我每周执行常规部署，现有目录结构如下：

folder1/myApp_tps_20240928_DEV/<app_code_here>
folder1/myApp_otherProcs_20240928_DEV/<app_code_here>
folder1/myApp_otherProcs_20241005_DEV/<app_code_here>

其中myApp_tps_20240928_DEV与myApp_otherProcs_20241005_DEV基础代码一致，后者包含本周新增的少量代码变更。

Tickerplant（tp）层无需每周重启（影响tickerplant的代码极少变更），其他进程代码变更频繁，需定期重启。我希望按日期区分版本，方便出现问题时切换符号链接回滚至旧版本，初步计划采用以下目录结构：

folder1/myApp_20240928_DEV/<app_code_here>
folder1/myApp_20241005_DEV/<app_code_here>
folder1/myApp -> myApp_20241005_DEV (symlink)

此结构下，tp层仍运行myApp_20240928_DEV的代码，其他进程运行myApp_20241005_DEV的代码；重启tp层时将加载新版本代码，若有schema变更可手动重启tp层加载新schema。

问题 #

1. 若删除仍被运行中tp层引用的myApp_20240928_DEV目录，会产生什么后果？
2. 采用如下目录结构是否更合理？

folder1/myApp_20240928_DEV/<app_code_here>
folder1/myApp_20241005_DEV/<app_code_here>
folder1/tpLayer -> myApp_20240928_DEV 
folder1/nonTpLayer -> myApp_20241005_DEV 

另外我考虑过新增normalizers/feeds层实现无影响重启应用，但开发成本较高，希望尽量避免。

解答 #

问题1的答案 #

• 如果tp进程已将所需代码文件加载至内存，删除目录后短期内tp可能仍正常运行——操作系统会保留已打开文件的句柄，直到进程关闭这些文件。
• 但如果tp后续需要读取该目录下的新文件（比如动态加载配置、模块，或向该目录下的文件写入日志），会触发文件/目录不存在的错误，导致tp进程异常甚至崩溃。
• 部分操作系统中，删除被进程引用的目录后，该目录占用的磁盘空间不会立即释放，直到引用它的进程退出，会造成磁盘空间浪费。
• 最稳妥的做法是等tp进程停止后再删除旧版本目录，若必须清理，需先确认tp没有未关闭的文件句柄指向该目录下的文件。

问题2的答案 #

这个结构比之前的更合理，原因如下：

• 明确区分tp层与非tp层的符号链接，避免混淆：每个层级的版本指向清晰，不会出现“tp直接引用旧版本目录，其他进程通过通用链接引用新版本”的模糊情况。
• 回滚操作更直观：非tp层需要回滚时，直接修改nonTpLayer的符号链接即可；tp层需要更新时，修改tpLayer的链接后重启tp，逻辑清晰，不易出错。
• 扩展性更好：未来若有其他独立进程组需要单独管理版本，可新增类似符号链接（如analyticsLayer），不会影响现有结构。

需注意：每次部署新版本后，要根据需求更新对应符号链接，比如非tp层更新到myApp_20241005_DEV时，直接修改nonTpLayer指向新版本，重启非tp进程即可加载新代码。

内容的提问来源于stack exchange，提问作者flavio