一次迫不得已的服务器搬家
2026年的6月，北京的夏天来得格外早。坐在中关村一间没有窗户的机房里，看着监控面板上跳动的红色警报，我知道，再不动手就晚了。网站连着三天出现间歇性宕机，用户投诉邮件堆满了收件箱。老板在晨会上拍着桌子问：就不能一次性搞定吗？
答案是，不能，至少不是那种下单付款、隔天就行的简单事。我们用的不是市面上主流的云服务商，而是老旧的Domino服务器。对，就是那个IBM Lotus Domino，很多95后可能都没听说过。但在一部分金融和大型制造业客户里，它依然是核心系统。要把整套Domino环境迁出去，放到服务器托管北京机房，中间还要处理远程Linux服务器装Tomcat做前端分流——这种组合拳，市面上几乎没有现成方案。
Domino服务器：老将的倔强与麻烦
先说Domino。很多人觉得“不就是换个服务器嘛，数据备份、恢复、IP改一下就行”。现实是，Domino的架构设计本身就比较封闭，它的邮件、文档库和应用程序高度耦合。从老旧的Power服务器迁到标准的x86 Linux主机，光Lotus Notes的邮件路由配置就折腾了两个通宵。
而且，Domino对网络延迟非常敏感。我们的业务有一块是面向保险公司的理赔流程，前后台交互全靠Domino的RPC协议。如果服务器托管在北京的机房但用户分布在广州、深圳，DNS解析和路由优化稍有闪失，客户端连接直接超时。曾有一次，只是把一条路由策略从BGP改成静态，结果整个华南区的代理报单系统卡了半小时。
为什么选择服务器托管北京？
这个问题其实纠结了很久。一开始想过继续用某大厂的公有云，但合规部门和客户那边不松口，坚持要物理机。理由也很直白：金融监管要求数据物理隔离，而且Domino的某些版本在虚拟化环境下行为异常。
北京作为北方最大的网络交换中心，到华北、东北、西北的延迟都在可接受范围内。而且，北京的机房对BGP带宽和IP资源管理相对规范，不像某些二线城市，给的IP段经常被墙或者路由混乱。我们最后选了酒仙桥一带的一个老牌机房，据说跟中国联通的总部直连，延迟能控制在2毫秒以内。
但物理托管的问题也不少。进机房要提前预约、穿防静电服、做登记，遇到故障排查，人在办公室远程操作，偶尔还会因为机房空调故障导致高温警告。记得2025年冬天有一次，机房空调检修，温度飙到32度，硬盘直接报错，吓得我们连夜开车过去处理。
远程Linux服务器装Tomcat的修罗场
这次迁移里最头疼的不是Domino本身，而是中间层的重构。原来的架构是Domino直接对外，安全性和扩展性都很差。新方案里，我们决定在Domino前面加一层Tomcat做反向代理和负载均衡。
远程Linux服务器装Tomcat，听起来很常规的操作，但一旦涉及生产环境，坑就一个接一个。我们采购的都是Dell R750，预装的系统是CentOS Stream 9。Tomcat 10版本对JDK要求高，必须用JDK 11以上，但CentOS的默认源里只有JDK 8，自己编译安装JDK 17时，因为缺少一些库文件，编译了三次才通过。
更要命的是，Domino和Tomcat之间的集成。Domino的HTTP栈跟标准Apache不太一样，它用的SSL证书格式是KYR，而Java这边通用的是JKS。为了把证书从Domino导出再转换成Tomcat能识别的格式，我翻遍了IBM的旧文档，终于找到一个2018年的社区帖子，里面提到了一个叫kyr2jks的脚本，很老但还能用。改完证书之后，Tomcat又频频报错SSL握手失败，折腾了一天发现是Domino的TLS版本只支持1.2，而Tomcat默认优先1.3，在server.xml里强制限定一下才稳定下来。
我的世界服务器区：一个意外的发现
在机房调试期间，隔壁机架上的一群年轻人引起了我的注意。他们摆了好几台机器，上面贴着“我的世界服务器区”的标签。当时觉得挺新鲜，还有专门为游戏玩家分区托管服务器的。聊了几句才知道，对方是一个大型MC联机社区的运维团队，他们在全国租了十几个托管空间，这里只是北方节点。
我们笑称，技术栈完全不同，但遇到的麻烦很相似：延迟优化、反作弊插件兼容性、DDoS防御。我们的Domino用户抱怨页面加载慢，他们的MC玩家吐槽“开盲盒”延迟飙升。有一回，他们的Mohist服务端因为升级了一个插件，导致区块加载崩溃，回退了五个版本才恢复——这种体验我们太熟了。
这也让我意识到，其实无论企业级应用还是游戏社区，底层都是服务器托管和系统维护的问题。只是我们的世界里，没有可以随时回档的备份，每一次改动都必须万无一失。