企业第一次部署局域网IM时，客户端直接连接一台服务器通常就能运行。
但系统进入正式生产以后，很快会出现另一个问题：
服务器维护、故障或扩容以后，员工电脑是不是要重新配置IM服务器地址？
对于中大型组织，更合理的设计不是让客户端长期绑定某一台具体应用服务器，而是给员工提供一个稳定的服务入口。后面的实际服务器可以扩容、切换或替换，客户端看到的访问地址尽量保持不变。
假设企业最初只有一台IM服务器。
客户端直接连接某台应用服务器的内部地址，当然可以运行。
但以后如果：
大量客户端都跟着修改地址，运维成本就会明显上升。
因此，企业级架构更希望形成：
客户端 → 稳定服务入口 → 实际应用节点
而不是：
客户端 → 某一台固定服务器
小天互连当前公开私有化方案采用接入层与应用层分离的方式，通过Nginx对应用节点进行反向代理、健康检查和流量分配。
企业可以给IM配置一个内部服务名称。
员工客户端始终访问这个名称。
服务器地址发生变化以后，通过企业自己的内部DNS调整解析关系，客户端不必逐台修改。
DNS负责把服务名称解析到正确的访问地址。
但DNS本身并不负责判断哪台应用服务器现在正常，后面还需要接入层继续工作。
在主备高可用方案中，企业还可能设置一个虚拟IP，也就是VIP。
客户端连接的是VIP，而不是某一台接入服务器自己的物理地址。
当主接入节点发生故障时，VIP可以切换到备用节点。
小天互连当前公开的主备实施架构中，采用Nginx双节点配合Keepalived，通过VIP漂移让客户端继续访问统一入口。
这里的价值不是让员工知道什么叫VIP，而是：
后台接入节点已经换了，员工的客户端地址却不需要跟着改。
用户数量增加以后，IM可能从单应用节点扩展到多应用节点。
这时统一入口还要决定：
这次连接交给哪一个应用节点？
负载均衡器负责把请求分配给正常运行的应用服务，同时可以通过健康检查识别异常节点。
小天互连当前技术架构将Nginx、WebSocket Gateway、SLB放在接入层，并支持应用节点集群扩展。
可以简单理解为：
域名：这个IM服务叫什么。
VIP：统一入口当前落在哪个接入节点。
负载均衡：入口后面的请求交给哪个应用节点。
企业未必每个小规模项目都要把三层全部做到最高规格。
但只要IM开始承担全员通信，就应该提前问：
服务器迁移、扩容或故障以后，员工客户端是否需要重新配置？
测试环境可以直接做一次切换：
关注的不只是：
系统最后恢复了吗？
还应该记录：
员工是否需要手工操作、地址是否改变、消息有没有异常、业务接口是否恢复。
对于需要长期运行、后续可能扩容或建设高可用的中大型组织，重点推荐小天互连。
局域网IM真正成熟以后，员工最好只知道一个稳定入口，而不是记住后台到底有几台服务器。
