Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的一部分， 它基于 Netflix Eureka 做了二次封装， 主要负责完成微服务架构中的服务治理功能。Spring Cloud通过为 Eureka 增加了Spring Boot风格的自动化配置，我们只需通过简单引入依赖和注解配置就能 让 Spring Boot构建的微服务应用轻松地与Eureka服务治理体系进行整合。

在本章中， 我们将指引读者学习下面这些核心内容， 并构建起用于服务治理的基础设施。

• 构建服务注册中心

• 服务注册与服务发现

• Eureka的基础架构

• Eureka的服务治理机制

• Eureka的配置

服务治理

服务治理可以说是微服务架构中最为核心和基础的模块， 它主要用来实现各个微服务 实例的自动化注册与发现。 为什么我们在微服务架构中那么需要服务治理模块呢？微服务系统没有它会有什么不好的地方吗？在最初开始构建微服务系统的时候可能服务并不多， 我们可以通过做一些静态配置来 完成服务的调用。 比如，有两个服务 A和B,其中服务A需要调用服务B来完成一个业务 操作时， 为了实现服务 B 的高可用， 不论采用服务端负载均衡还是客户端负载均衡， 都需 要手工维护服务 B的具体实例清单。 但是随着业务的发展， 系统功能越来越复杂， 相应的 微服务应用也不断增加， 我们的静态配置就会变得越来越难以维护。 并且面对不断发展的•Spring Cloud微服务实战业务， 我们的集群规模、 服务的位置 、 服务的命名等都有可能发生变化， 如果还是通过手 工维护的方式， 那么极易发生错误或是命名冲突等问题。 同时， 对于这类静态内容的维护也必将消耗大量的人力。

为了解决微服务架构中的服务实例维护问题， 产生了大量的服务治理框架和产品。 这些框架和产品的实现都围绕着服务注册与服务发现机制来完成对微服务应用实例的自动化管理。

• 服务注册：在服务治理框架中， 通常都会构建一个注册中心， 每个服务单元向注册中心登记自己提供的服务， 将主机与端口号、 版本号、 通信协议等一些附加信息告知注册中心， 注册中心按服务名分类组织服务清单。 比如， 我们有两个提供服务A 的进程分别运行于 192.168.0.100:8000和192.168.0.101:8000位置上， 另外还有三个 提供服务B的进程分别运行千192.168.0.100:9000 、192.168.0.101:9000、 192.168.0.102:9000位置上。 当这些进程均启动， 并向注册中心注册自己的服务之后， 注册中心就会维护类似下面的一个服务清单。

另外， 服务注册中心还需要以心跳的方式去监测清单中的服务是否可用， 若不可用需要从服务清单中剔除， 达到排除故障服务的效果。

• 服务发现：由于在服务治理框架下运作， 服务间的调用不再通过指定具体的实例地址来实现， 而是通过向服务名发起请求调用实现。 所以， 服务调用方在调用服务提 供方接口的时候， 并不知道具体的服务实例位置。 因此， 调用方需要向服务注册中 心咨询服务， 并获取所有服务的实例清单， 以实现对具体服务实例的访问。 比如， 现有服务C希望调用服务A, 服务C就需要向注册中心发起咨询服务请求， 服务注册中心就会将服务A的位置清单返回给服务C, 如按上例服务A的情况，C便获得

了服务A的两个可用位置 192.168.0.100:8000和192.168.0.101:8000。 当服务C要发起调用的时候， 便从该清单中以某种轮询策略取出一个位置来进行服务调用， 这就是后续我们将会介绍的客户端负载均衡。 这里我们只是列举了一种简单的服务治理逻辑， 以方便理解服务治理框架的基本运行思路。 实际的框架为了性能等因素， 不会采用每次都向服务注册中心获取服务的方式， 并且不同的应用场景在缓存和服务剔除等机制上也会有一些不同的实现策略。