微服务服务发现架构

Architecture

服务发现架构图，展示 Consul 或 Eureka 注册中心、客户端负载均衡、健康检查心跳以及实例的自动注册和注销。该模板可视化微服务如何在没有硬编码端点的情况下动态定位彼此，实现弹性扩展和自愈基础设施。对于构建弹性服务间通信的平台团队至关重要。

下载 .fz 文件

完整 FlowZap 代码

Client { # Client Service
n1: circle label:"Service Call Needed"
n2: rectangle label:"Query Service Registry"
n3: rectangle label:"Client-Side Load Balance"
n4: rectangle label:"Send Request to Instance"
n5: circle label:"Receive Response"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Registry.n6.handle(top) [label="Lookup"]
n3.handle(right) -> n4.handle(left)
n4.handle(bottom) -> Target.n12.handle(top) [label="HTTP/gRPC"]
}
Registry { # Service Registry (Consul/Eureka)
n6: rectangle label:"Receive Lookup Request"
n7: rectangle label:"Check Health Status"
n8: diamond label:"Healthy Instances?"
n9: rectangle label:"Return Instance List"
n10: rectangle label:"Return Service Unavailable"
n11: rectangle label:"Heartbeat Monitor"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="No"]
n9.handle(top) -> Client.n3.handle(bottom) [label="Endpoints"]
n10.handle(top) -> Client.n5.handle(bottom) [label="503"]
n11.handle(bottom) -> Target.n15.handle(top) [label="Ping"]
}
Target { # Target Service
n12: rectangle label:"Instance A (Primary)"
n13: rectangle label:"Instance B (Replica)"
n14: rectangle label:"Instance C (Replica)"
n15: rectangle label:"Register on Startup"
n16: rectangle label:"Deregister on Shutdown"
n12.handle(top) -> Client.n5.handle(bottom) [label="Response"]
n15.handle(top) -> Registry.n11.handle(bottom) [label="Heartbeat"]
n16.handle(top) -> Registry.n6.handle(bottom) [label="Remove"]
}

为什么需要这个工作流？

Hardcoding service endpoints in configuration files breaks when instances scale up, fail, or move across hosts. Service discovery enables dynamic endpoint resolution, allowing microservices to find each other automatically as instances are added, removed, or replaced—essential for elastic cloud deployments.

工作原理

Step 1: Each service instance registers itself with the service registry on startup.
Step 2: The registry maintains a list of healthy instances with their network addresses.
Step 3: Health check heartbeats verify instance availability at regular intervals.
Step 4: When a service needs to call another, it queries the registry for available instances.
Step 5: Client-side load balancing distributes requests across healthy instances.
Step 6: Instances deregister on graceful shutdown to prevent routing to terminated processes.

替代方案

DNS-based discovery is simpler but has TTL caching issues. Kubernetes built-in service discovery works within a cluster but not across clusters. Consul and Eureka provide cross-platform discovery. This template helps teams understand the discovery lifecycle.

Key Facts

Template Name	微服务服务发现架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)