面试官：如何判断一个服务是否可用？

  • 看你简历很擅长处理分布式高可用呀
  • 请问在分布式环境下如何判断一个服务是否可用？

我： 先排除一个错误答案，下面跟业务代码没有关系

根据答题游戏规则，当别抛给你一个模糊，抽象概念，

老虎吃天不知从哪儿下口，咱就就是普通开发工程师，完全超出自己认知，

可用 你能想到 高可用 和负载均衡，分布式系统经常 被动 主动或者被动发送心跳包方式解决 也许从网上听到过或者公司PPT看到过

web请求为例子

1. 接入层的 四层，7层负载均衡

  • 银行，电信,金融 采用的F5硬负载均衡器，故障切换秒级完成，无单点风险
  • 腾讯、淘宝、新浪等大型门户及商业网站使用的是软负载均衡器Nginx，7层负
  • 传统企业办公利用​​高可用（HA）组件​​ Keepalived（LVS：Linux Virtual Server）提供虚拟IP，防止单点故障，实现自动切换 针对机器负载均衡,四层，若主节点故障，备用节点接管VIP（切换时间1-3秒） 特点：第三方，与业务软件无关。
维度​​ ​​F5 BIG-IP（商业硬件/软件）​​ ​​Keepalived（开源软件）​​
​​核心定位​​ ​​全栈负载均衡器​​（L4/L7），集成安全、加速、高可用 ​​高可用（HA）组件​​，依赖其他工具（如LVS/Nginx）实现负载均衡
​​工作层级​​ L4（TCP/UDP）和L7（HTTP/HTTPS等） 网络层（L3）和传输层（L4），基于VRRP协议
​​关键功能​​ 负载均衡、WAF、DDoS防护、SSL卸载、智能路由 VIP漂移、健康检查（端口/脚本）、故障切换
​​性能能力​​ 硬件加速，支持百万级并发 依赖服务器性能，需配合LVS实现高性能负载均衡（十万级并发）
​​高可用机制​​ 内置硬件冗余集群 主备切换（VRRP协议），资源利用率仅50%
​​扩展性​​ 通过设备集群水平扩展 需配合LVS/Nginx扩展负载能力
​​成本​​ 商业授权（单设备数十万元） 开源免费
​​典型应用场景​​ 金融/政府核心业务、全栈流量治理 Web/数据库主备切换、轻量级高可用架构
​ ​​Nginx​​ ​​F5 BIG-IP​​
​​类型​​ 开源软件负载均衡器（七层为主） 商业硬件负载均衡设备（四层+七层）
​​工作层级​​ 应用层（HTTP/HTTPS） 传输层（TCP/UDP）和应用层（HTTP等）
​​成本​​ 免费（开源） 高昂（单设备数十万元）
​​部署方式​​ 软件安装于服务器 专用硬件设备独立部署

2. 业务层 服务网格（Service Mesh）

  • 企业级云原生架构中，K8s 与 Istio 的协同已成主流方案，尤其在金融、电商等高要求场景

Envoy

  • Envoy成为Kubernetes与Prometheus之后在CNCF毕业第三个毕业的项目

  • Envoy 是由 Lyft 开源的一个高性能 C++11 编写的代理服务器，它主要作为服务网格的数据平面，通过以平台无关的方式提供通用功能来抽象网络

  • 处于其中的应用只需要简单的与本地的 Envoy 进行收发信息，并不需要关注整个网络拓扑

  • 在Envoy看来，网络对应用程序应该是透明的；而当网络和应用程序出现故障时，运维人员应该能够很容易地确定问题根源

  • Kubernetes 是一个开源的容器编排平台，服务发现：Kubernetes 提供了 DNS 服务发现和 LoadBalancer 服务，允许容器服务之间进行通信。负载均衡：通过 Service 资源实现负载均衡，支持多种类型的负载均衡器 外部架构

维度​​ ​​Kubernetes (K8s)​​ ​​Istio​​
​​核心目标​​ 容器编排与管理（部署、扩缩容、自愈） 微服务通信治理（流量管理、安全、可观测性）
​​功能层级​​ 基础设施层（容器生命周期） 服务网格层（服务间通信）
​​依赖关系​​ 独立运行 依赖 K8s 作为运行基座（如 Pod 部署 Sidecar

中间件

  • 无论分布式数据库，还是分布式存储还是分布式缓存。

这些都是独立业务的。作为一个普通开发工程师，是不清楚这些问题的。

因此缩小访问，通过端口判断一个服务是否正常

我：通过端口判断一个服务是否正常

首先区分故障类型

网络故障，节点故障，服务故障 和服务繁忙

层级 (OSI / TCP‑IP) 检测内容 推荐工具 优点 缺点
L3 / 网络层 主机是否可达 ping, traceroute 快速判断 IP 是否在线；识别路由路径；命令简单易用 若 ICMP 被屏蔽会失败；无法检查端口或服务状态
L4 / 传输层（TCP/UDP） 端口是否开放（是否有监听） nc -zv, telnet, nmap 简单检测端口监听；nmap 支持高并发、批量扫描； telnet 和 nc 无法区分服务层逻辑是否正常；nmap 扫描可能被 IDS/防火墙检测到；部分扫描（如 SYN）
L7 / 应用层 服务协议与逻辑的真实响应 curl, Envoy 健康探测, K8s probes 高精度判断服务是否真正可用；可定制业务级检查；支持报警和仪表盘集成 需要服务提供健康接口（如 /health）；配置复杂；依赖协议兼容性
综合监控平台 多层级服务可用性与指标监控 Zabbix, Prometheus 等 提供图形展示、告警策略、历史记录和 SLA 分析；支持插件或脚本扩展 初期部署复杂；资源开销大；需持续维护
​ ​​检测目标​​ ​​关键检测方法​​ ​​常用工具/命令​​ ​​异常标志/典型问题​​
​​物理层​​ 物理介质连通性 检查网线/光纤连接、设备指示灯状态；测试信号衰减与误码率 网线测试仪、光功率计、ip link show 网卡状态 DOWN、指示灯不亮、信号衰减超阈值
​​数据链路层​​ MAC地址通信与帧传输 验证ARP表项；检测以太网帧封装一致性（如VLAN匹配）；检查交换机端口状态与MAC学习情况 arp -a、display mac-address（交换机）、Wireshark抓包 ARP表无目标IP记录、VLAN隔离导致不通、端口被禁用
​​网络层​​ IP路由与防火墙策略 测试ICMP连通性（ping）；追踪路由路径；检查防火墙规则是否放行目标端口 ping、traceroute、iptables -L ping超时但端口检测通（策略拦截）、路由环路或黑洞
​​传输层​​ TCP/UDP端口监听状态 测试TCP三次握手（Telnet/nc）；扫描UDP端口响应；检查本地端口监听状态 telnet <IP> <端口>、nc -zv <IP> <端口>、netstat -tuln Connection refused（无监听）、UDP无响应（可能被过滤）
​​应用层​​ 服务逻辑与协议交互 发送协议合规请求（如HTTP GET）；验证业务响应（如数据库查询）；检查日志错误与资源负载 curl -I、mysql -e "SELECT 1"、应用日志 HTTP 50x错误、SQL查询超时、CPU/内存过载导致服务不可用

🔍 各层检测说明与案例

✅ L3 层（网络连通性）

  • ping：发送 ICMP echo 请求判断主机是否存在，并测量往返时延；

  • traceroute：追踪 IP 包经过的网络路径，定位中间跳数的问题。

  • 局限：如果目标主机或网络设备屏蔽 ICMP，可能导致误判主机不可达。

✅ L4 层（端口连通性）

  • nc/telnet：尝试建立 TCP 连接；成功即表示有服务在监听该端口；

  • nmap：支持各种扫描方式（connect scan、SYN scan、UDP scan 等），并可识别端口状态、服务类型、版本、操作系统指纹等Cyberly。

  • 注意：telnet 更适合手动测试；nc 适合脚本化、单端口快速检测；nmap 适合高级扫描、批量探测，但扫描行为容易被防火墙或 IDS 识别。

✅ L7 层（应用协议状态）

  • curl / httpie：发 HTTP 请求至指定接口，如 /health，判断 HTTP 状态码；

  • Envoy / HAProxy 健康检查：主动探测 upstream 服务，判断是否返回 200×、gRPC OK 等；

  • Kubernetes readinessProbe / livenessProbe：评估 Pod 是否准备就绪或存活；

  • 优势：能够判断服务逻辑、接口是否正常工作；也可以在负载均衡或服务网格中自动剔除异常节点；

  • 缺点：要求服务暴露健康检测接口；配置略为复杂。

✅ 综合监控平台

  • 例如 Zabbix、Prometheus + Alertmanager、Nagios 等监控系统，通常采用：

    • 调用脚本（如 nc、curl）采集指标；

    • 聚合趋势数据，展示可视化图表；

    • 支持阈值告警、通知集成、历史审计日志；

  • 优点：覆盖全栈（网络 → 端口 → 接口）；支持自动化巡检、报警、合规审计；

  • 缺点：需部署维护；对运维成本要求高。

参考资料

  • Envoy 在轻舟微服务中落地实践-王佰平-云原生社区 meetup 第三期杭州站
  • 《Istio 大咖说》第 6 期：Envoy Proxy 在线答疑
  • 《Istio 大咖说》第1期：Istio 开源四周年回顾与展望
  • https://jimmysong.io/about/
  • 揭秘：Istio与K8s核心差异，企业级微服务架构新选择！