Question

服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现。为什么我们在微服务架构中那么需要服务治理模块呢？微服务系统没有它会有什么不好的地方吗？

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

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

- 服务注册： 在服务治理框架中，通常都会构建一个注册中心，每个服务单元向注册中心登记自己提供的服务，将主机与端口号、版本号、通信协议等一些附加信息告知注册中心，注册中心按服务名分类组织服务清单。比如，我们有两个提供服务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要发起调用的时候，便从该清单中以某种轮询策略取出一个位置来进行服务调用，这就是后续我们将会介绍的客户端负载均衡。这里我们只是列举了一种简单的服务治理逻辑，以方便理解服务治理框架的基本运行思路。实际的框架为了性能等因素，不会采用每次都向服务注册中心获取服务的方式，并且不同的应用场景在缓存和服务剔除等机制上也会有一些不同的实现策略。

Netflix Eureka

Spring Cloud Eureka，使用Netflix Eureka来实现服务注册与发现，它既包含了服务端组件，也包含了客户端组件，并且服务端与客户端均采用Java编写，所以Eureka主要适用于通过Java实现的分布式系统，或是与JVM兼容语言构建的系统。但是，由于Eureka服务端的服务治理机制提供了完备的RESTful API，所以它也支持将非Java语言构建的微服务应用纳入Eureka的服务治理体系中来。只是在使用其他语言平台的时候，需要自己来实现Eureka的客户端程序。不过庆幸的是，在目前几个较为流行的开发平台上，都已经有了一些针对 Eureka 注册中心的客户端实现框架，比如.NET 平台的 Steeltoe、Node.js 的eureka-js-client等。

Eureka服务端，我们也称为服务注册中心。它同其他服务注册中心一样，支持高可用配置。它依托于强一致性提供良好的服务实例可用性，可以应对多种不同的故障场景。如果 Eureka 以集群模式部署，当集群中有分片出现故障时，那么 Eureka 就转入自我保护模式。它允许在分片故障期间继续提供服务的发现和注册，当故障分片恢复运行时，集群中的其他分片会把它们的状态再次同步回来。以在 AWS 上的实践为例，Netflix 推荐每个可用的区域运行一个Eureka服务端，通过它来形成集群。不同可用区域的服务注册中心通过异步模式互相复制各自的状态，这意味着在任意给定的时间点每个实例关于所有服务的状态是有细微差别的。

Eureka客户端，主要处理服务的注册与发现。客户端服务通过注解和参数配置的方式，嵌入在客户端应用程序的代码中，在应用程序运行时，Eureka客户端向注册中心注册自身提供的服务并周期性地发送心跳来更新它的服务租约。同时，它也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期性地刷新服务状态。

下面我们来构建一些简单示例，学习如何使用Eureka构建注册中心以及进行注册与发现服务。

搭建服务注册中心

首先，创建一个基础的Spring Boot工程，命名为eureka-server，并在pom.xml中引入必要的依赖内容，代码如下：

<parent>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-parent</artifactId>

<version>1.3.7.RELEASE</version>

<relativePath/>

</parent>

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-eureka-server</artifactId>

</dependency>

</dependencies>

<dependencyManagement>

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-dependencies</artifactId>

<version>Brixton.SR5</version>

<type>pom</type>

<scope>import</scope>

</dependency>

</dependencies>

</dependencyManagement>

通过@EnableEurekaServer注解启动一个服务注册中心提供给其他应用进行对话。这一步非常简单，只需在一个普通的Spring Boot应用中添加这个注解就能开启此功能，比如下面的例子：

@EnableEurekaServer

@SpringBootApplication

public class Application {

public static void main（String[]args）{

new SpringApplicationBuilder（Application.class）.web（true）.run（args）;

}

}

在默认设置下，该服务注册中心也会将自己作为客户端来尝试注册它自己，所以我们需要禁用它的客户端注册行为，只需在application.properties中增加如下配置：

server.port=1111

eureka.instance.hostname=localhost

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

eureka.client.serviceUrl.defaultZone=http://${eureka.instance.hostname}:${serve r.port}/eureka/

由于后续内容也都会在本地运行，为了与后续要进行注册的服务区分，这里将服务注册中心的端口通过server.port属性设置为1111。

- eureka.client.register-with-eureka：由于该应用为注册中心，所以设置为false，代表不向注册中心注册自己。

- eureka.client.fetch-registry：由于注册中心的职责就是维护服务实例，它并不需要去检索服务，所以也设置为false。

在完成了上面的配置后，启动应用并访问http://localhost:1111/。可以看到如下图所示的Eureka信息面板，其中Instances currently registered with Eureka栏是空的，说明该注册中心还没有注册任何服务。

注册服务提供者

在完成了服务注册中心的搭建之后，接下来我们尝试将一个既有的Spring Boot应用加入Eureka的服务治理体系中去。

可以使用上一章中实现的快速入门工程来进行改造，将其作为一个微服务应用向服务注册中心发布自己。首先，修改pom.xml，增加Spring Cloud Eureka模块的依赖，具体代码如下所示：

<dependencies>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-web</artifactId>

</dependency>

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-test</artifactId>

<scope>test</scope>

</dependency>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-starter-eureka</artifactId>

</dependency>

</dependencies>

<dependencyManagement>

<dependencies>

<dependency>

<groupId>org.springframework.cloud</groupId>

<artifactId>spring-cloud-dependencies</artifactId>

<version>Brixton.SR5</version>

<type>pom</type>

<scope>import</scope>

</dependency>

</dependencies>

</dependencyManagement>

接着，改造/hello请求处理接口，通过注入DiscoveryClient对象，在日志中打印出服务的相关内容。

@RestController

public class HelloController {

private final Logger logger=Logger.getLogger（getClass（））;

@Autowired

private DiscoveryClient client;

@RequestMapping（value="/hello",method=RequestMethod.GET）

public String index（）{

ServiceInstance instance=client.getLocalServiceInstance（）;

logger.info（"/hello,host:"+instance.getHost（）+",service_id:"+instance.getServiceId（））;

return "Hello World";

}

}

然后，在主类中通过加上@EnableDiscoveryClient 注解，激活 Eureka 中的DiscoveryClient实现（自动化配置，创建DiscoveryClient接口针对Eureka客户端的EurekaDiscoveryClient实例），才能实现上述Controller中对服务信息的输出。

@EnableDiscoveryClient

@SpringBootApplication

public class HelloApplication {

public static void main（String[]args）{

SpringApplication.run（HelloApplication.class,args）;

}

}

最后，我们需要在 application.properties 配置文件中，通过 spring.application.name 属性来为服务命名，比如命名为hello-service。再通过eureka.client.serviceUrl.defaultZone 属性来指定服务注册中心的地址，这里我们指定为之前构建的服务注册中心地址，完整配置如下所示：

spring.application.name=hello-service

eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

下面我们分别启动服务注册中心以及这里改造后的 hello-service 服务。在hello-service服务控制台中，Tomcat启动之后，com.netflix.discovery.DiscoveryClient对象打印了该服务的注册信息，表示服务注册成功。

s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port（s）: 8080（http）

c.n.e.EurekaDiscoveryClientConfiguration : Updating port to 8080

com.didispace.HelloApplication　　　　　 : Started HelloApplication in 7.218

seconds（JVM running for 11.646）

com.netflix.discovery.DiscoveryClient　　: DiscoveryClient_HELLO-SERVICE/PC-

201602152056:hello-service-registration status: 204

而此时在服务注册中心的控制台中，可以看到类似下面的输出，名为hello-service的服务被注册成功了。

c.n.e.registry.AbstractInstanceRegistry : Registered instance

HELLO-SERVICE/PC-201602152056:hello-service with status UP（replication=true）

我们也可以通过访问Eureka的信息面板，在Instances currently registered with Eureka一栏中看到服务的注册信息。

通过访问http://localhost:8080/hello，直接向该服务发起请求，在控制台中可以看到如下输出：

com.didispace.web.HelloController　　　: /hello,host:PC-201602152056,

service_id:hello-service

这些输出内容就是之前我们在HelloController中注入的DiscoveryClient接口对象，从服务注册中心获取的服务相关信息。

高可用注册中心

在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。但是到本节为止，我们一直都在使用单节点的服务注册中心，这在生产环境中显然并不合适，我们需要构建高可用的服务注册中心以增强系统的可用性。

Eureka Server的设计一开始就考虑了高可用问题，在Eureka的服务治理设计中，所有节点即是服务提供方，也是服务消费方，服务注册中心也不例外。是否还记得在单节点的配置中，我们设置过下面这两个参数，让服务注册中心不注册自己：

eureka.client.register-with-eureka=false

eureka.client.fetch-registry=false

Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用的效果。下面我们就来尝试搭建高可用服务注册中心的集群。可以在本章第1节中实现的服务注册中心的基础之上进行扩展，构建一个双节点的服务注册中心集群。

- 创建 application-peer1.properties，作为peer1服务中心的配置，并将serviceUrl指向peer2：

spring.application.name=eureka-server

server.port=1111

eureka.instance.hostname=peer1

eureka.client.serviceUrl.defaultZone=http://peer2:1112/eureka/

- 创建 application-peer2.properties，作为peer2服务中心的配置，并将serviceUrl指向peer1：

spring.application.name=eureka-server

server.port=1112

eureka.instance.hostname=peer2

eureka.client.serviceUrl.defaultZone=http://peer1:1111/eureka/

- 在/etc/hosts 文件中添加对 peer1和 peer2的转换，让上面配置的 host 形式的serviceUrl 能在本地正确访问到；Windows 系统路径为C:\Windows\System32\drivers\etc\hosts。

127.0.0.1 peer1

127.0.0.1 peer2

- 通过spring.profiles.active属性来分别启动peer1和peer2：

java-jar eureka-server-1.0.0.jar--spring.profiles.active=peer1

java-jar eureka-server-1.0.0.jar--spring.profiles.active=peer2

此时访问peer1的注册中心http://localhost:1111/，如下图所示，我们可以看到，registered-replicas中已经有peer2节点的eureka-server了。同样的，我们访问peer2的注册中心http://localhost:1112/，也能看到registered-replicas中已经有peer1节点，并且这些节点在可用分片（available-replicase）之中。我们也可以尝试关闭 peer1，刷新http://localhost:1112/，可以看到 peer1的节点变为了不可用分片（unavailable-replicas）。

- 在设置了多节点的服务注册中心之后，服务提供方还需要做一些简单的配置才能将服务注册到 Eureka Server 集群中。我们以 hello-service 为例，修改application.properties配置文件，如下所示：

spring.application.name=hello-service

eureka.client.serviceUrl.defaultZone=http://peer1:1111/eureka/,http://peer2:111 2/eureka/

上面的配置主要对eureka.client.serviceUrl.defaultZone属性做了改动，将注册中心指向了之前我们搭建的peer1与peer2。

下面，我们启动该服务，通过访问http://localhost:1111/和http://localhost:1112/，可以观察到 hello-service 服务同时被注册到了 peer1和 peer2上。若此时断开peer1，由于compute-service同时也向peer2注册，因此在peer2上的其他服务依然能访问到hello-service，从而实现了服务注册中心的高可用。

如我们不想使用主机名来定义注册中心的地址，也可以使用IP地址的形式，但是需要在配置文件中增加配置参数eureka.instance.prefer-ip-address=true，该值默认为false。

服务发现与消费

通过上面的内容介绍与实践，我们已经搭建起微服务架构中的核心组件—服务注册中心（包括单节点模式和高可用模式）。同时，还对上一章中实现的Spring Boot入门程序做了改造。通过简单的配置，使该程序注册到Eureka注册中心上，成为该服务治理体系下的一个服务，命名为hello-service。现在我们已经有了服务注册中心和服务提供者，下面就来尝试构建一个服务消费者，它主要完成两个目标，发现服务以及消费服务。其中，服务发现的任务由Eureka的客户端完成，而服务消费的任务由Ribbon完成。Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。当 Ribbon 与 Eureka 联合使用时，Ribbon的服务实例清单 RibbonServerList 会被 DiscoveryEnabledNIWSServerList 重写，扩展成从 Eureka 注册中心中获取服务端列表。同时它也会用 NIWSDiscoveryPing来取代 IPing，它将职责委托给 Eureka 来确定服务端是否已经启动。在本章中，我们对Ribbon不做详细的介绍，读者只需要理解它在Eureka服务发现的基础上，实现了一套对服务实例的选择策略，从而实现对服务的消费。下一章我们会对Ribbon做详细的介绍和分析。

下面我们通过构建一个简单的示例，看看在Eureka的服务治理体系下如何实现服务的发现与消费。

- 首先，我们做一些准备工作。启动之前实现的服务注册中心eureka-server以及hello-service服务，为了实验Ribbon的客户端负载均衡功能，我们通过java-jar命令行的方式来启动两个不同端口的hello-service，具体如下：

java-jar hello-service-0.0.1-SNAPSHOT.jar--server.port=8081

java-jar hello-service-0.0.1-SNAPSHOT.jar--server.port=8082

- 在成功启动两个 hello-service 服务之后，如下图所示，从 Eureka 信息面板中可以看到名为HELLO-SERVICE的服务中出现了两个实例单元，分别是通过命令行启动的8081端口和8082端口的服务。

- 创建一个Spring Boot的基础工程来实现服务消费者，取名为ribbon-consumer，并在pom.xml中引入如下的依赖内容。较之前的hello-service，我们新增了Ribbon模块的依赖spring-cloud-starter-ribbon。

- 创建应用主类ConsumerApplication，通过@EnableDiscoveryClient注解让该应用注册为Eureka客户端应用，以获得服务发现的能力。同时，在该主类中创建RestTemplate的Spring Bean实例，并通过@LoadBalanced注解开启客户端负载均衡。

@EnableDiscoveryClient

@SpringBootApplication

public class ConsumerApplication {

@Bean

@LoadBalanced

RestTemplate restTemplate（）{

return new RestTemplate（）;

}

public static void main（String[]args）{

SpringApplication.run（ConsumerApplication.class,args）;

}

}

- 创建ConsumerController类并实现/ribbon-consumer接口。在该接口中，通过在上面创建的 RestTemplate 来实现对 HELLO-SERVICE 服务提供的/hello接口进行调用。可以看到这里访问的地址是服务名HELLO-SERVICE，而不是一个具体的地址，在服务治理框架中，这是一个非常重要的特性，也符合在本章一开始对服务治理的解释。

@RestController

public class ConsumerController {

@Autowired

RestTemplate restTemplate;

@RequestMapping（value="/ribbon-consumer",method=RequestMethod.GET）

public String helloConsumer（）{

return restTemplate.getForEntity（"http://HELLO-SERVICE/hello",String.class）.getBody（）;

}

}

- 在application.properties中配置Eureka服务注册中心的位置，需要与之前的HELLO-SERVICE一样，不然是发现不了该服务的，同时设置该消费者的端口为9000，不能与之前启动的应用端口冲突。

spring.application.name=ribbon-consumer

server.port=9000

eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/

- 启动ribbon-consumer应用后，我们可以在Eureka信息面板中看到，当前除了HELLO-SERVICE之外，还多了我们实现的RIBBON-CONSUMER服务。

- 通过向http://localhost:9000/ribbon-consumer发起GET请求，成功返回了“Hello World”。此时，我们可以在ribbon-consumer应用的控制台中看到如下信息，Ribbon输出了当前客户端维护的HELLO-SERVICE的服务列表情况。其中包含了各个实例的位置，Ribbon就是按照此信息进行轮询访问，以实现基于客户端的负载均衡。另外还输出了一些其他非常有用的信息，如对各个实例的请求总数量、第一次连接信息、上一次连接信息、总的请求失败数量等。

c.n.l.DynamicServerListLoadBalancer　　 : DynamicServerListLoadBalancer for client

HELLO-SERVICE initialized:

DynamicServerListLoadBalancer:{NFLoadBalancer:name=HELLO-SERVICE,current list of

Servers=[PC-201602152056:8082,PC-201602152056:8081],Load balancer stats=Zone stats:

{defaultzone=[Zone:defaultzone;　Instance count:2; Active connections count: 0;

Circuit breaker tripped count: 0; Active connections per server: 0.0;]

},Server stats:[[Server:PC-201602152056:8082;　Zone:defaultZone; Total Requests:0;

Successive connection failure:0;　Total blackout seconds:0;Last connection made:Thu Jan

01 08:00:00 CST 1970;　First connection made: Thu Jan 01 08:00:00 CST 1970;　Active

Connections:0; total failure count in last（1000）msecs:0; average resp time:0.0;　90

percentile resp time:0.0;　95 percentile resp time:0.0;　min resp time:0.0;　max resp

time:0.0;　stddev resp time:0.0]

,[Server:PC-201602152056:8081; Zone:defaultZone; Total Requests:0; Successive

connection failure:0;　Total blackout seconds:0;Last connection made:Thu Jan 01 08:00:00

CST 1970;　First connection made: Thu Jan 01 08:00:00 CST 1970;　Active Connections:0;

total failure count in last（1000）msecs:0; average resp time:0.0;　90 percentile resp

time:0.0;　95 percentile resp time:0.0;　min resp time:0.0;　max resp time:0.0;　stddev

resp time:0.0]

]}ServerList:org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServer

List@cc7240

再尝试发送几次请求，并观察启动的两个 HELLO-SERVICE 的控制台，可以看到两个控制台会交替打印下面的日志，这是我们之前在HelloController中实现的对服务信息的输出，可以用来判断当前ribbon-consumer对HELLO-SERVICE的调用是否是负载均衡的。

com.didispace.web.HelloController　　　: /hello,host:PC-201602152056,

service_id:hello-service