云平台负载均衡器与实例组的协作方式，关键在于把“请求送到哪里”和“有多少实例可用”分开管理。负载均衡器负责接收流量、选择健康后端并转发请求；实例组负责维护实例集合，按设定策略增加或减少计算资源。两者配合后，应用才能在实例变化时持续接收请求。
先分清两者各自负责什么
负载均衡器通常有前端监听器、转发规则和后端池。请求到达监听器后，系统依据协议、端口或其他规则选择后端；健康检查失败的实例会暂时停止接收新请求。实例组则管理一批配置相近的虚拟机实例，可按期望数量维持规模，也可依据监控指标或计划调整数量。
以 Microsoft Azure 的 Azure Load Balancer 和虚拟机规模集为例，负载均衡规则可以把流量指向后端池，规模集管理其中的虚拟机成员。实际配置名称与能力会随云产品、负载均衡类型和区域而异，但基本分工相同：负载均衡器不负责创建算力，实例组也不负责替代请求转发。
请求如何从入口到达实例
- 用户发起请求：客户端访问应用的统一入口，负载均衡器依据监听器和转发规则接收流量。
- 检查后端状态：健康检查按配置探测实例上的服务端口或指定路径。探测成功的成员可接收新请求；失败的成员会被标记为不健康。
- 选择可用实例：负载均衡器按轮询、连接数或产品支持的其他策略，将请求分配给健康后端。算法可选项应以所用云平台为准。
- 实例组调整成员：当伸缩策略满足条件时，实例组启动新实例或移除实例，并更新后端成员关系。新实例需完成应用启动并通过健康检查，才适合承接流量。
配置时优先检查这四项
后端池与网络连通性
确认实例组成员已关联到正确的后端池，并核对子网、安全组或防火墙规则允许负载均衡器探测及转发所需的端口。若探测端口被拦截，实例即使能正常运行，也可能被判为不健康。
健康检查要对应真实服务
检查端口应是应用实际监听的端口；使用 HTTP 检查时，路径应返回可识别的成功状态。探测过于频繁可能增加无意义的检查，判定过慢则可能延迟摘除故障实例。可先按平台建议设置，再结合启动时间和故障恢复要求调整。
伸缩指标与容量边界
常见伸缩依据包括 CPU 利用率、请求量或队列积压。阈值需要结合应用负载测试确定；例如可把持续数分钟的 CPU 利用率约 60%—70%作为试调起点，而非通用标准。还要设置最小、最大实例数，并预留新实例启动时间，避免突发流量到来时扩容跟不上。
缩容前处理存量连接
实例组缩容时，先让待移除实例停止接收新连接，并按平台能力启用连接排空或优雅退出。对有会话状态的应用，还要评估会话保持、共享会话存储或无状态改造；否则实例被移除后，用户可能需要重新登录或重试操作。
按步骤完成联调
- 部署至少一个应用实例，确认服务端口可从负载均衡器所在网络访问。
- 创建或选择实例组，设置期望容量及最小、最大规模。
- 配置负载均衡监听器、转发规则和后端池，并将实例组接入后端。
- 配置健康检查，观察后端健康状态；先排除网络规则、端口和应用响应问题。
- 在测试环境产生可控负载，检查请求是否进入健康实例，再观察扩容、缩容及实例退出过程。
- 查看云平台监控与日志，核对错误率、响应时间、实例数量和健康状态，并据此调整策略。
如果团队正在选择云资源或需要梳理部署方案，可以向德讯电讯咨询适用的配置与服务范围；沟通时应明确业务流量特征、可用性要求及运维责任，再比较方案是否匹配，而不要只看单项资源价格。
常见问题
负载均衡器能自动扩容实例吗？
通常不能单独完成。它负责分发请求；扩容一般由实例组及其伸缩策略执行，两者需要正确关联。
实例已经启动，为什么仍收不到请求？
先检查健康检查结果、后端池关联、监听端口和网络访问规则。实例只有进入可用后端状态，才会按规则接收新请求。
最少需要多少个实例？
取决于应用的故障容忍要求、容量和成本。单实例可用于低风险测试；生产环境是否采用多个实例，应结合故障影响与可用性目标决定。
总结来说，云平台负载均衡器与实例组的协作方式，是用健康检查控制流量去向，用伸缩策略管理承载容量；把后端关联、扩缩容时序和连接排空一并验证，才能让两者真正配合。
