前言

  最近学习SpringCloud，对其中的知识点进行梳理，故写下博客记录自己的学习笔记，方便日后回顾。

一、微服务

1.什么是微服务

  官方定义：微服务就是由一系列围绕自己业务开发的微小服务构成,它们独立部署运行在自己的进程里,基于分布式的管理。

  通俗定义：微服务是一种架构，这种架构是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露的API来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

2.单体架构和微服务架构

2.1.单体架构

1.优点:
  单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。

2.缺点:
  应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。 久而久之，开发效率低，代码维护困难,还有一个如果想整体应用采用新的技术，新的框架或者语言，那也是极其困难的。同时任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性。

2.2.微服务架构

1.优点：

• 将服务拆分成多个单一职责的小的服务，进行单独部署，服务之间通过网络进行通信。
• 每个服务应该有自己单独的管理团队，高度自治。
• 服务各自有自己单独的职责，服务之间松耦合，避免因一个模块的问题导致服务崩溃。

2.缺点：

• 开发人员要处理分布式系统的复杂性。
• 多服务运维难度，随着服务的增加，运维的压力也在增大。
• 服务治理和服务监控同样是关键。

二、服务注册中心

1.服务注册中心简介

  服务注册中心：服务注册中心就是在整个的微服务架构中单独提出一个服务，这个服务不完成系统的任何的业务功能，仅仅用来完成对整个微服务系统的服务注册和服务发现，以及对服务健康状态的监控和管理功能。

服务注册中心

• 可以对所有的微服务的信息进行存储，如微服务的名称、IP、端口等
• 可以在进行服务调用时通过服务发现查询可用的微服务列表及网络地址进行服务调用
• 可以对所有的微服务进行心跳检测，如发现某实例长时间无法访问，就会从服务注册表移除该实例

  目前常用的服务注册中心有Eureka，Consul、Zookeeper、以及阿里巴巴推出Nacos，这些注册中心SpringCloud都支持，并且在本质上都是用来管理服务的注册和发现以及服务状态的检查的。而我们这里只对Eureka和Nacos两种服务注册中心进行介绍。

2.Eureka服务注册中心

  Eureka官网地址：https://github.com/Netflix/eureka/wiki
  Eureka是Netflix开发的服务发现框架，本身也是一个基于Rest的服务，SpringCloud将它集成在其子项目springcloud-cloud-netflix中，实现SpringCloud的服务注册和发现功能。其包含两个组件：Eureka Server 和 Eureka Client。更加通俗理解，Eureka Server可以理为Eureka服务注册中心，而Eureka Client则是指各个微服务。

2.1.Eureka Server开发

  1.创建项目并引入依赖

        <!--springboot web依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!--eureka server 依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
        </dependency>

  2.编写配置文件application.yml

server:
  port: 8080 #服务端口

spring:
  application:
    name: EUREKASERVER  #服务名称 唯一标识

eureka:
  client:
    service-url:
      defaultZone: http://loalhost:8761/eureka #指定服务注册中心的地址
    fetch-registry: false #关闭eureka client的立即注册
    register-with-eureka: false #当前应用仅作为服务端，不再作为客户端进行注册

  3.入口类加入注解开启Eureka Server

@SpringBootApplication
@EnableEurekaServer //开启当前应用为服务注册中心
public class EurekaServerApplication {
    public static void main(String[] args){
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

  完成以上操作后启动该服务，进入浏览器访问Eureka的服务注册页面http://localhost:8761，即可看到如下图界面，我们也可以观察到，此时服务注册中心中是没有服务注册上去的，显示的是
No instances available。

2.2 Eureka Client开发

  1.创建项目并引入依赖

        <!--springboot web依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>

        <!--eureka client 依赖-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

  2.编写配置文件application.yml

server:
  port: 8888

spring:
  application:
    name: EUREKACLIENT

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka #指定服务注册中心的地址

  3.入口类加入注解开启Eureka Client

@SpringBootApplication
@EnableEurekaClient //开启eureka客户端
public class EurekaClientApplication {
    public static void main(String[] args){
        SpringApplication.run(EurekaClientApplication.class, args);
    }
}

  同理，在完成上述操作后启动该服务，但是值得注意的是，我们需要先启动之前的Eureka服务注册中心，再启动本服务，即可服务注册中心的注册情况，如下图所示，EUREKACLIENT服务已经注册到服务中心当中。

3.Eureka的自我保护机制

  官方文档地址：https://github.com/Netflix/eureka/wiki/Server-Self-Preservation-Mode

3.1.Eureka自我保护机制简介

  当我们启动服务注册中心，同时对应客户端服务也已经注册到服务注册中心，但是某个时间点该客户端服务突然宕机，对服务注册中心进行多次刷新该服务依然存在于注册中心，同时Eureka服务注册中心出现如下界面：

• EMERGENCY! EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT. RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEING EXPIRED JUST TO BE SAFE.
  紧急！EUREKA 可能错误地声称实例已启动，而实际上它们没有启动。 续订小于阈值，因此实例不会过期只是为了安全起见

而这也是Eureka触发了自我保护机制的现象。
  在官方文档中对Eureka的自我保护有这样的定义：

默认情况下，如果Eureka Server在一定时间内（默认90秒）没有接收到某个微服务实例的心跳，Eureka Server将会移除该实例。但是当网络分区故障发生时（比如网络延迟），微服务与Eureka Server之间无法正常通信，而微服务本身是正常运行的，此时不应该移除这个微服务，所以引入了自我保护机制。Eureka Server在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 会将这些实例保护起来，让这些实例不会过期。这种设计的哲学原理就是"宁可信其有不可信其无!"。自我保护模式正是一种针对网络异常波动的安全保护措施，使用自我保护模式能使Eureka集群更加的健壮、稳定的运行。

所以我们也可以知道，引入自我保护机制，其实也是为了确保这种灾难性的网络事件不会清除掉Eureka中的注册数据，并将其传播到其他的客户端。

3.2.Eureka自我保护机制的停止

  自我保护机制的开启时间并不是没有限制的，在官方文档中也提到，当该服务的心跳次数高于预期阈值，或者自我保护机制被禁用，那么该服务则会从服务注册中心中移除。虽然这两个条件是或者关系，但是实现起来需要两者的配合使用。

3.2.1.客户端心跳高于预期阈值的实现

  在客户端配置文件application.yml中加入如下配置：

eureka:
  instance:
    lease-expiration-duration-in-seconds: 10 #修改eureka server默认接受心跳的最大时间 默认是90s
    lease-renewal-interval-in-seconds: 5 #指定客户端多久向eureka server发送一次心跳 默认是30s

在默认的配置当中，90s的时间内，每隔30s向服务端发送一次心跳，则每个单元就发送了3次心跳；而在15分钟这个总的周期当中，总共会发送30次心跳，在这30次心跳中要有超过85%的失败心跳，则不会启动自我保护机制，等待超时时间之后将清除该服务。我们在配置中更改了默认数据，则每个单元内发送2个心跳，倘若两个心跳都失败，则会加快清除的速度。

3.2.2.服务端自我保护机制禁用的实现

  在服务端配置文件application.yml中加入如下配置：

eureka:
  server:
    enable-self-preservation: false #关闭自我保护
    eviction-interval-timer-in-ms: 3000 #超时3s自动清除 默认一分钟

这里需要注意，即使关闭了自我保护机制，当注册中心检测到两者之间的失败心跳频率低于预定频率，也不会立刻清除该服务，而是等待超时时间过后再清除。当然官方并不推荐关闭自我保护机制这种方式。