上线前验收必须把依赖服务连通性测全，否则功能测试再完善，连接一旦断开，线上事故依然防不胜防。 很多团队在上线前把精力全压在业务功能上，忽略了服务之间的网络通路，结果就像电梯修好了但电源没插，用户按了按钮根本没反应，依赖服务的连通性，是线上运行的底层命脉，验收时漏掉它，等于把安全绳系在纸带上。
为什么依赖服务连通性测试是上线前验收的命门
从一次线上事故说起
去年我参与一个电商项目,上线前所有业务用例都跑通了，下单、支付、退款，样样正常，结果上线后用户反馈一直转圈，后台日志显示连接Redis超时，原来验收环境里Redis连的是测试集群，线上配置指向了另一个集群，但网络策略没放开，功能测试压根没发现，因为测试环境一切正常，这就是典型的连通性盲区功能跑通不代表网络通路安全。
连通性测试与功能测试的差异
功能测试验证的是“请求-响应”是否符合预期，比如下单接口返回成功，而连通性测试验证的是“服务A能否到达服务B”，以及到达后能否正常交换数据，两者是不同维度的保障。功能测试通过，只能说明逻辑正确；连通性测试通过，才能说明服务真的能协同工作。 行业共识认为，上线前验收中连通性测试的遗漏，是导致线上P0级故障的前三大原因之一。
上线前验收怎么做：连通性测试策略全解析
梳理依赖拓扑，明确测试范围
第一步,画出当前服务依赖的所有上下游，包括数据库、缓存、消息队列、外部API、配置中心、注册中心等，不要只列名字，还要记录端口、协议、超时设置、重试机制。建议用表格整理，
| 依赖服务 | 类型 | 地址/端口 | 验证方式 |
|---|---|---|---|
| MySQL主库 | 数据库 | 168.1.10:3306 | 建立连接并执行简单查询 |
| Redis集群 |
缓存 |
168.1.20:6379 | PING命令 |
| 支付网关 | 外部API | https://pay.example.com | 发送健康检查请求 |
每个依赖需明确验收标准,比如连接建立时间小于1秒，失败重试次数不超过3次。
设计连通性测试用例，覆盖正常与异常
测试用例不能只测“能连上”的快乐路径，你必须覆盖这些场景：
- 正常连通：服务能建立连接并完成一次基本交互（如数据库执行SELECT 1）。
- 超时处理：模拟网络延迟，验证服务是否按预期超时与重试。
- 连接拒绝：故意关闭目标端口，验证服务是否优雅降级或报错明确。
- DNS解析失败：依赖域名时，验证能否正确解析，以及解析失败后是否触发备用逻辑。
- 证书与认证：涉及HTTPS或TLS的，验证证书有效性、双向认证是否通过。
核心原则：每个依赖服务至少准备一条正常用例和一条异常用例。 异常用例不必全部自动化，但必须手动验证过一次。
选择合适的工具，自动化执行
工具选型取决于你的技术栈,常见方案：
- 网络层：telnet、nc（netcat）、curl，用于快速验证端口可达。
- 应用层：针对数据库、消息队列等，使用对应客户端SDK写测试脚本，比如用Python的pymysql连接MySQL，用redis-py执行PING。
- 测试框架：集成到CI/CD流程中，比如用Jenkins或GitLab CI跑一段连通性检查脚本，失败则阻止上线。
- 开源工具：consul health check、goss（基于YAML的服务器测试工具），可以批量验证依赖服务状态。
实操建议：在验收环境中部署一个独立的连通性测试容器，启动时自动执行所有依赖检查，输出JSON报告。 这样每次上线前只需一键触发，就能看到全局连通性状态。
依赖服务连通性测试方法：工具与实操
数据库连接验证
数据库是绝大多数应用的依赖核心,验证方法很简单：使用数据库客户端建立连接，执行一条轻量级查询，例如MySQL用SELECT 1，Redis用PING，MongoDB用db.adminCommand('ping')，关键点在于验证连接池配置是否生效，比如最大连接数、空闲超时，业内数据显示，相当一部分线上故障是因为连接池耗尽导致新请求排队超时，而不是数据库本身宕机，所以验收时要模拟高并发连接，确认连接池能正常扩缩。
消息队列连通性
消息队列（如Kafka、RabbitMQ、RocketMQ）的连通性测试比数据库更复杂，因为涉及生产者和消费者两端的协作，具体做法：
- 生产者能力：测试服务能否正常发送消息到指定Topic，并确认没有发送失败或超时。
- 消费者能力：测试服务能否订阅Topic并消费消息，确认消息不丢失、不重复。
- 集群连通性：如果消息队列是集群架构，验证服务能否随机连接到任一节点，并在节点故障时自动切换。
建议编写一个专门的连通性测试脚本，在验收环境中跑一次完整的“生产-消费”闭环，确认消息成功流转。 很多团队在生产环境遇到过这样的问题：配置正确，但网络防火墙禁止了Kafka的9092端口，导致消息一直发送失败，验收时跑一遍脚本就能立刻暴露这类问题。
外部API网关可达性
依赖外部服务时（如支付、短信、地图），连通性测试需关注网络策略、域名解析、证书有效期，实操步骤：
- 使用
curl -v或requests库发送一次健康检查请求，观察HTTP状态码和响应时间。 - 验证请求是否被防火墙或WAF拦截,比如返回403或502。
- 检查证书是否即将过期,用
openssl s_client -connect命令查看证书有效期。 - 如果API有认证要求（如API Key、OAuth Token），测试时需携带正确凭证，并验证凭证过期后是否自动刷新。
建议在验收环境中单独划出一台机器，配置与生产环境一模一样的网络策略，然后运行所有外部API的连通性测试。 这样能最大程度复现生产路径。
上线前验收连通性测试常见问题（Q&A）
上线前验收连通性测试需要覆盖所有依赖服务吗？
是的,必须覆盖全量依赖，一个典型的后端服务可能依赖数据库、缓存、消息队列、注册中心、配置中心、日志服务、监控服务以及外部API，漏掉任何一个，都可能成为线上瓶颈，但覆盖并不意味着每条都要自动化，对于低频或静态依赖（如配置中心），手动验证一次即可。关键在于要有清单，并逐项打勾确认。
连通性测试失败后应该怎么处理？
首先判断失败原因：是网络策略问题（如防火墙、安全组）、配置问题（如连接地址、端口写错），还是服务本身未启动，根据优先级处理：阻塞性依赖（如数据库、注册中心）必须修复后才能上线；非阻塞性依赖（如部分外部API）可先降级，但需记录并跟踪，处理完成后，重新跑一遍连通性测试，直到全部通过。
连通性测试应该放在验收流程的哪个阶段？
放在功能测试完成之后、上线批准之前，原因是功能测试可能依赖某些服务，如果先跑连通性测试，部分服务可能还未就绪，反而浪费精力。正确的顺序是：功能测试→连通性测试→上线审批。 连通性测试通过后，意味着网络层面的障碍已消除，功能测试结果才能真实反映线上表现。
最后再强调一次：上线前验收把依赖服务连通性测全，不是选择题，而是必答题。 功能测试决定了业务是否跑得通，连通性测试决定了服务是否站得稳，两者缺一不可，而后者往往被忽视，却最容易在线上引发雪崩，把这张网织密了，上线才能睡得安稳。