4、Eureka深度解析（上）：Eureka架构、Region与Zone、Eureka Server集群搭建
好，咱们今天正式进入Eureka的深度解析。说实话，Eureka虽然现在处于维护状态，但它的设计思想非常经典。很多公司内部的服务发现框架，或多或少都借鉴了它的思路。我个人觉得，搞懂Eureka，再去看Consul、Nacos这些，会轻松很多。
4.1 Eureka的整体架构
先看一张宏观的图（嗯，我这里用文字描述一下）。Eureka的架构其实就三个角色：Eureka Server、Eureka Client，以及服务实例本身。
- Eureka Server：注册中心，负责存储服务信息。它本身也是一个服务，可以集群部署。
- Eureka Client：一个Java客户端，集成在微服务中。它负责向Server注册自己，并拉取其他服务的地址。
- 服务实例：就是你写的业务服务，比如订单服务、用户服务。
说白了，整个流程就是：服务启动时，Client告诉Server“我来了，我叫什么名字，我在哪个IP哪个端口”。然后其他服务通过Client问Server“那个订单服务在哪？给我地址”。
核心要点：Eureka的设计哲学是“AP优先”，也就是可用性和分区容错性优先，一致性可以稍弱。这在微服务场景下非常实用——你想想看，如果注册中心挂了，服务之间还能通过本地缓存继续调用，而不是整个系统瘫痪。
4.2 Region与Zone：Eureka的“地理”概念
这里有个容易混淆的点：Region和Zone。我在项目中遇到过不少同事，上来就问“Region和Zone到底有啥区别？”
其实很简单：
- Region：可以理解为地理区域，比如华北、华东、美东、美西。一个Region内可以有多个Zone。
- Zone：可以理解为机房或者可用区。比如华北Region下，有北京机房、天津机房。
Eureka为什么要搞这套？说白了就是为了就近访问和容灾。你想想看，如果所有服务都跨Region调用，延迟会很高。Eureka允许你配置：同一个Zone内的服务优先互相调用，跨Zone是备选方案。
我的经验：我曾经在部署跨机房项目时，因为没有正确配置Zone，导致所有请求都打到了另一个城市的机房，延迟从2ms飙升到30ms。后来加上Zone的亲和性配置，问题就解决了。所以，Region和Zone不是摆设，一定要用起来。
4.3 Eureka Server集群搭建
好，理论说完了，咱们动手。搭建Eureka Server集群，核心就一句话：互相注册。
什么意思？就是每个Eureka Server节点，把自己注册到其他节点上。这样它们之间就能同步服务信息了。
4.3.1 基础配置
假设我们搭建一个双节点集群：peer1和peer2。
peer1的application.yml：
server:
port: 8761
eureka:
instance:
hostname: peer1
client:
register-with-eureka: true
fetch-registry: true
service-url:
defaultZone: http://peer2:8762/eureka/
peer2的application.yml：
server:
port: 8762
eureka:
instance:
hostname: peer2
client:
register-with-eureka: true
fetch-registry: true
service-url:
defaultZone: http://peer1:8761/eureka/
看到了吗？peer1的defaultZone指向peer2，peer2的defaultZone指向peer1。这就是互相注册。
注意：这里有个坑。如果你在本地测试，需要配置hosts文件，把peer1和peer2映射到127.0.0.1。否则Eureka无法解析主机名。我曾经因为这个折腾了半天，最后发现是hosts没配。
4.3.2 启动与验证
启动两个服务后，访问任何一个节点的Eureka控制台，你都会看到DS Replicas区域列出了另一个节点。这说明集群已经搭建成功。
你还可以看到每个服务的replica count，正常情况下应该是2（两个节点各有一份）。
4.3.3 生产环境建议
我个人习惯在生产环境至少部署3个Eureka Server节点。为什么是3个？因为Eureka的自我保护机制需要多数节点存活才能正常工作。2个节点的话，挂一个就只剩50%了，容易触发自我保护。
| 节点数 | 容错能力 | 推荐场景 |
|---|---|---|
| 2 | 可挂1个 | 开发/测试环境 |
| 3 | 可挂1个 | 小型生产环境 |
| 5+ | 可挂2个以上 | 大型生产环境 |
避坑指南：我曾经在生产环境只部署了2个Eureka节点，结果其中一个因为网络抖动挂了，另一个立刻进入自我保护模式，不再剔除任何服务实例。导致一些已经宕机的服务还在注册表中，调用方一直报错。所以，至少3个节点，这是血的教训。
4.4 小结
这一章我们聊了Eureka的架构、Region与Zone的概念，以及如何搭建集群。说白了，Eureka的设计非常务实——它不强求强一致性，而是保证最终一致性，这在分布式系统中往往更实用。
下一章我们会深入Eureka的源码，看看它到底是怎么实现注册、心跳、剔除这些核心功能的。嗯，到时候你会发现，很多设计模式在源码里都能找到影子。