同一个账号体系下跑多个实例，是最容易乱的地方。每个实例都有自己的会话、缓存和连接池，分不清谁是谁的时候，地址一乱，排查就没了抓手。代理IP的分配要先于业务启动，等业务跑起来再补，多半补不过来。分组的方式不复杂，但要一开始就定下来，后期改的成本比想象中高。
分组定得早，后面少一半麻烦。
按实例分组的前提
一个实例一条线路，乱了能一眼看出是哪条出的问题。
前提是把实例编上号。编号不必复杂，能对应到具体任务就行，比如按业务线加序号。编号定下来之后，地址、账号、日志都对得上号。没有编号的时候，十条代理IP线路里出问题的那一条，只能靠猜，猜错的代价是整批任务重跑。
实例多了，地址能复用吗
能，但要错开时间。两个实例共用一条线路的前提是它们不在同一时间跑同类操作。时间重叠的话，复用的地址在目标侧看来就是同一个来源在做两件事，处理结果往往不理想。要复用就先错开时段，或者按业务类型分开。
编号怎么落到配置里
编号要落到配置文件名和日志前缀里，不能只记在人脑子里。配置文件的命名带上编号，日志每行带上编号，出问题时用编号一搜，这个实例用过的所有线路就都出来了。这一步花不了几分钟，省的是后面每一次排查的时间。
分组的三种做法
第一种是按业务线分，一条业务线用一组线路，业务之间互不干扰。第二种是按时间分，白天用一批，夜间用一批，适合用量有明显起伏的团队。第三种是按重要程度分，核心任务单独一组，边缘任务共享一组。三种做法可以叠着用，前提是分组规则只定一套，两套规则并行等于没有规则。
叠用时先定主规则
叠用的时候要先定哪一条是主规则。以业务线为主，时间只作补充；或者以重要程度为主，业务线作补充。主规则决定一个实例最终落在哪一组，补充规则只在边界上起作用。主次不分，同一个实例会被两套规则分到不同的组，配置就跟着乱。
什么时候该拆组
一组代理IP线路跑到七八成占用，就该考虑拆。拆的时机看两个数：一组内同时在线实例数、一组的失败率。实例数逼近并发上限，拆；失败率明显高于其他组，拆。拆之前把新组的编号规则一起定好，不然拆完又多一套编号。
分组不是为了整齐，是为了出问题时能少查一半。
实例分组这件事，做完之后平时看不出价值，出问题时价值全在。一次能定位到具体是哪条线路，比十条线路一起换要省太多。