分了环境却没分开，原因往往在于绑的位置不对。规则绑在整机上，同一台机器开几个实例都是同一条线；绑在浏览器上，换个程序就走回原来的路。要让分开真正生效，绑定的位置得落到单个实例上，让每个实例各自带着自己的IP参数出去，谁也影响不到谁。
绑得越靠近实例，效果越稳，出了问题也更容易定位到具体哪一个。
- 整机绑定
- 一次配置全机生效，实例之间没有区别
- 程序绑定
- 跟着进程走，换个程序就失效
- 实例绑定
- 一个实例一套参数，粒度最细
实例绑定操作起来麻烦吗？
比整机绑定多几步，但可以模板化。把常用的一组参数存成模板，新实例直接套用，改的时候也只改模板，实际工作量并不大。
粒度和维护成本是反向的。粒度越细，配一次越麻烦，出问题时影响面越小。多数项目取中间那一档，既能分开，又不用一台台手工配。判断方式是把最坏情况想一遍：一个实例出问题，会不会牵动其余的。
怎么确认绑到了实例
同时开两个实例，各查一次IP地址。两个不同，说明绑到了实例层；两个相同，说明还停在整机层。这一步不花钱，但能省掉后面大量排查。改完配置就验一次，养成习惯之后花不了两分钟，比事后翻日志快得多。
IP不同也只是第一关，还要看参数有没有跟着走。协议类型、认证信息、超时设置，这些都是跟着实例走的，如果查出来的地址变了、认证还是旧的，说明只改了对外地址，参数没跟上，用起来照样出问题。
模板化能减少重复劳动。把一组参数存成模板，新实例套用，改的时候改模板再推一遍。十个实例手工改一遍要半小时，模板改一遍五分钟，规模越大差别越明显。模板要写备注，不然过两个月自己也看不懂当初为什么这么设。
什么时候该往上加一层
当实例之间开始互相影响，就该往上加一层。表现为一个实例掉线连带其他实例变慢，这时候要么加设备，要么把IP来源彻底分开。判断标准是影响面，影响面超过一半就该动手了，拖下去只会越来越难分。
绑定的位置决定了隔离的上限，后面再怎么调参数，也超不过这个上限。想往上走只能换方式，不能靠改数值。
先把绑定的位置放对，再考虑调参数，这个顺序换不得，省一步后面要补三步。
