微服务—Spring Cloud原理、实战

关键名词

服务发现(service discovery)

在许多分布式系统架构中，都需要去获取机器的物理地址（微服务实例部署的服务器地址及端口）。这一认知在分布式系统架构开始的时候就已经存在，而等到分布式计算出现的时候，被正式称为服务发现(service discovery)。
SpringCloud是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建。
SpringCloud的组件相当繁杂，拥有诸多子项目。重点关注Netflix。

服务ID

服务ID只是被服务发现代理用来给不同服务分组而已，即相同服务的不同实例，它们的服务ID是相同的。

SpringCloud经常用的5个组建：

服务发现——Netflix Eureka

https://www.jianshu.com/p/9e49ff250b4e

• 由两个组件组成：Eureka服务端和Eureka客户端。
• Eureka服务端用作服务注册中心。支持集群部署。
• Eureka客户端是一个java客户端，用来处理服务注册与发现。
• 在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性（默认30秒）的进行心跳交互，以更新服务租约和服务信息。各个服务内的Eureka Client组件，默认情况下，每隔30秒会发送一个请求到Eureka Server，来拉取最近有变化的服务信息

传统DNS+负载均衡在微服务中不足

• 单点故障。主次负载均衡器能实现高可用，但请求剧增时，会成为整体架构的性能瓶颈。
• 限制水平扩展能力。通过负载均衡器将服务集中到单个集群。
• 静态托管。不支持为服务快速注册/注销。
• 复杂。消费者必须通过它，导致架构多了一层。

服务发现架构

• 服务注册。
• 客户端获取服务地址
• 信息共享。服务发现代理集群间共享服务注册信息。
• 健康监控
  

基于云的微服务环境的服务发现其特征

• 高可用。其它节点实时接管。
• 所有节点对等。
• 负载均衡。动态地、均衡地分配，而非DNS静态分配。客户端负载均衡。
• 弹性。服务发现的客户端在本地缓存服务实例信息，服务端衰掉了还能依赖缓存运行。
• 容错。自动发现并处理不可用服务实例。

• 另外，当服务调用失败，客户端会让本地缓存失效，然后重新从服务发现代理获取新的服务注册信息。

部署高可用eureka server集群

部署三套eureka server，分别注册另两套。官方文档是改host文件…

实例1配置

server:
  port: 8761
#实例二  port: 8762
eureka:
  instance:
#生产环境不要用机器名
#    hostname: localhost
    prefer-ip-address: true
  client:
    register-with-eureka: false #表示是否注册Eureka服务器,因为自身作为服务注册中心，所以为false
    fetch-registry: false #是否从eureka上获取注册信息,表明自己是一个server
    service-url:
      defaultZone:http://${Server2IP}:${server2.port}/eureka/,http://${Server3IP}:${server3.port}/eureka/
spring:
  application:
    name: eurka-server

Eureka Server可以通过运行多个实例并相互注册的方式实现高可用部署，Eureka Server实例会彼此增量地同步信息，从而确保所有节点数据一致。事实上，节点之间相互注册是Eureka Server的默认行为。

两个项目的spring.application.name必须相同，eureka.instance.hostname必须不同，否则都会失败。
启动两个项目
分别访问 http://sc1.xxx.com:8761 和 http://sc2.xxx.com:8762 registered-replicas（已注册分片）都有另一个系统的url地址，并且都在available-replicase（可用分片）中

client端配置

eureka:
  client:
    service-url:
      defaultZone: http://peer1:8762/eureka/,http://peer2:8763/eureka

客服端负载均衡——Netflix Ribbon/Feign

Ribbon + restTemplate

加了注解@LoadBalanced后，代表在注入RestTemplate时，Ribbon会对其进行加工，加工后的RestTemplate的能力有：

• 在调用其他服务的接口时，会从访问的url中截取得到目标服务的application ID，然后根据该服务获取对应的实例，最后正常访问；
• 实现客户端负载均衡

一般都是用 Feign client，比较方便。

• Feign 采用的是基于接口的注解
• Feign 整合了ribbon，具有负载均衡的能力
• 整合了Hystrix，具有熔断的能力
  在程序的启动类XxxApplication ，加上@EnableFeignClients注解开启Feign的功能。其他注解： @SpringBootApplication @EnableEurekaClient @EnableDiscoveryClient

定义一个feign接口，通过@ FeignClient（“服务名”），来指定调用哪个服务。比如在代码中调用了service-hi服务的“/hi”接口，代码如下：

@FeignClient(value = "service-hi")
public interface SchedualServiceHi {
    @RequestMapping(value = "/hi",method = RequestMethod.GET)
    String sayHiFromClientOne(@RequestParam(value = "name") String name);
}

断路器——Netflix Hystrix

保护系统，控制故障范围。

如不及时采取断路措施，首先单个服务就会出现线程阻塞，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间存在依赖性，故障就会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。即可用避免连锁故障，fallback方法可以直接返回一个固定值。

Feign中使用断路器

在D版本的Spring Cloud之后，它没有默认打开。需要在配置文件中配置打开它，在配置文件加以下代码：

feign.hystrix.enabled=true

只需要在FeignClient的SchedualServiceHi接口的注解中加上fallback的指定类就行了：

@FeignClient(value = "service-hi",fallback = SchedualServiceHiHystric.class)
public interface SchedualServiceHi {
    @RequestMapping(value = "/hi",method = RequestMethod.GET)
    String sayHiFromClientOne(@RequestParam(value = "name") String name);
}

SchedualServiceHiHystric需要实现SchedualServiceHi 接口，并注入到Ioc容器中，代码如下：

@Component
public class SchedualServiceHiHystric implements SchedualServiceHi {
    @Override
    public String sayHiFromClientOne(String name) {
        return "sorry "+name;
    }
}

服务网关——Netflix Zuul

api网关，路由，负载均衡等多种作用

类似nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。

分布式配置——Spring Cloud Config

配置管理

简介：SpringCloud Config提供服务器端和客户端。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。
这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。

参考
https://www.jianshu.com/p/9e49ff250b4e
https://blog.csdn.net/forezp/column/info/15197 方志朋 专栏