单机容量达到上限之后，增加服务器只是第一步。请求是否可以均匀地分配到各个节点上，这取决于负载均衡的设置是否合理。
调度算法根据业务特点来选择。轮询适用于配置相同、请求时间相近的情况；加权分配用于新旧机器性能不同的过渡期；最少连接数在请求时间差异较大时更加公平。长连接业务要注意连接数和请求数不等价，按请求分配可能会使某台服务器过载。
健康检查决定了故障响应的时间。检查间隔和超时时间不宜太长，否则故障节点会一直收到流量；判定条件建议连续失败多次后才摘除，防止瞬时抖动导致误摘。探测路径要包含真实的依赖关系，只检查端口是否存活不能发现应用层的异常。
会话保持要权衡。根据来源地址来设置保持比较简单，但是同一个出口的请求就会集中起来；根据会话标识来进行保持的话就需要用到共享存储，在节点发生故障之后仍然可以继续进行。完成无状态化改造之后就可以关闭保持功能了，扩容和故障转移都会更加顺畅。
入口层细节也会影响到稳定性。静态资源、接口按照路径分流到不同的后端组中，防止图片请求挤占应用节点；慢请求设置独立的超时时间和队列上限，防止单个接口拖垮整个组；后端节点的最大连接数和系统的文件描述符上限要一起核对，配置过小会成为新的瓶颈。
上线之后查看各个节点上的请求量和响应时间的分布情况，如果偏差超过10%的话就需要重新调整权重和算法。