Spring Boot 微服务上容器平台的最佳实践 - 9 - Ribbon和负载均衡

前言

今天开始第九篇, 主要介绍 Ribbon和负载均衡.

Flights服务的结构与Airports服务类似，但依赖并调用Airports服务。因此，它利用Ribbon和生成的OpenShift Service实现高可用性。

Ribbon 和 负载均衡

RestTemplate 和 Ribbon

要快速且轻松地声明使用Ribbon所需的依赖项，请将以下构件(artifact)添加为Maven依赖项:

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-ribbon</artifactId>
</dependency>

该应用程序还利用Jackson JSR 310库正确地序列化和反序列化Java 8日期对象(date objects):

<dependency>
    <groupId>com.fasterxml.jackson.datatype</groupId>
    <artifactId>jackson-datatype-jsr310</artifactId>
    <version>2.8.8</version>
</dependency>

声明一个负载均衡的RestTemplate并使用注入将其分配给一个字段(field):

@LoadBalanced
@Bean
RestTemplate restTemplate()
{
 return new RestTemplate();
}

@Autowired
private RestTemplate restTemplate;

对于传出调用，只需使用restTemplate字段:

Airport[] airportArray = restTemplate.getForObject( "http://zuul/airports/airports", Airport[].class );

作为URL的主机部分提供的服务地址是通过Ribbon根据应用程序属性中提供的值解析的: (http://zuul中的zuul会被解析为: http://zuul:8080)

zuul:
  ribbon:
    listOfServers: zuul:8080

在本例中，Ribbon需要一个静态定义的服务地址列表，但是只有一个服务地址是用zuul:8080提供。Zuul使用地址的第二部分，即根web上下文(如上文的/airports/)，通过静态或动态路由重定向请求，本文档后面将对此进行解释。

提供的zuul主机名其实是OpenShift的Service 名(这个Service名在OpenShift集群内是可以作为域名使用的)，并解析为Service的Cluster IP地址，然后路由到内部的OpenShift负载均衡器。OpenShift Service名称是在使用oc工具创建Service时确定的，或者在使用fabric8 Maven插件部署镜像时确定的，它在service yaml文件中声明。

apiVersion: v1
kind: Service
metadata:
  name: zuul
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: ClusterIP

再解释下, 可以这么理解, OpenShift的Service类似于硬件Load Balancer(如F5), 这个Service的Cluster IP类似于F5的VIP. 它后面会有1个或多个zuul服务. 网络流: rest请求 -> zuul -> 1个OpenShift Service -> 1个或多个zuul实例.

实际上，Ribbon并不负责负载均衡请求，而是将它们发送到OpenShift内部负载均衡器，该负载均衡器知道服务实例的副本数和失败情况，可以正确地重定向请求(对于Ribbon来说, 就是1个地址; 服务的注册和发现其实是由OpenShift的Service来实现了)。

小结

这一次, Spring 微服务的负载均衡是通过: Ribbon 和 OpenShift(或K8S)的Service来做的.

1. Ribbon仅负责反向代理; (不负责负载均衡)
2. OpenShift Service 负责负载均衡, 以及服务的注册和发现.
   1. 具体某一个服务的失败与否是通过K8S的Health Probe来探测的.