微服务中Heartbeat的含义及Eureka客户端心跳相关技术问题

嗨，我来帮你把这两个问题串起来讲得明明白白～

简单来说，心跳就是微服务架构里服务之间用来确认存活状态的周期性小请求——就像你每隔一会儿给同事发个表情，告诉对方“我还在线，能干活”，避免对方以为你掉线了。

在分布式系统里，服务分散在不同机器甚至不同机房，没法直接盯着彼此的运行状态，所以就靠这种固定间隔的“打招呼”来维持感知：如果某个服务长时间没发心跳，注册中心或者依赖它的服务就会判定它已经挂了，不再把业务请求派给它，避免出现调用失败的情况。

你提到的Eureka客户端每30秒发一次心跳，这是Eureka的默认配置（如果需要调整，可修改参数eureka.instance.lease-renewal-interval-in-seconds）。这里的心跳本质是客户端向Eureka Server发送的续约请求，核心目的就是告诉注册中心：“我还活着，别把我从可用服务列表里删掉”。

至于心跳里传输的信息，其实内容非常精简，主要包含这些：

• 客户端服务的唯一标识：比如instanceId，用来区分同一服务的不同部署实例（比如同一个订单服务开了3个节点，靠这个ID就能精准识别每个节点）
• 服务的基础元数据：服务名称（appName）、当前运行状态（通常是UP，表示正常可用）
• 续约相关的时间戳：让Eureka Server判断这个心跳是否在有效期内，及时更新实例的存活状态
• 可选的自定义元数据：如果客户端配置了额外的信息（比如服务版本号、部署环境标签），也会在心跳里同步给注册中心，方便其他服务做更精细化的调用决策

补充个小知识点：Eureka Server收到心跳后，会更新该实例的最后续约时间，如果超过默认90秒（可通过eureka.instance.lease-expiration-duration-in-seconds调整）没收到下一次心跳，就会把这个实例标记为“过期”，后续逐步从服务列表中移除，避免其他服务调用到已经挂掉的节点。

内容的提问来源于stack exchange，提问作者humbleCoder