SpringCloud-Netflix

1. 微服务概述

1.1 什么是微服务

原文: https://martinfowler.com/articles/microservices.html

可能有的人觉得官方的话太过生涩，我们从技术维度来理解下:

• 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务,彻底地去耦合,每一个微服务提供单个业务功能的服务，一个服务做一件事情，从技术角度看就是一种小而独立的处理过程， 类似进程的概念，能够自行单独启动或销毁,拥有自己独立的数据库。

1.2 一般网站的架构图

1.3 微服务与微服务架构

1.4 微服务优缺点

1.5 微服务的技术栈

1.6 微服务框架对比

2. SpringCloud概述

2.1 什么是SpringCloud?

2.2 SpringBoot 和 SpringCloud 的关系[面试高频]

• SpringBoot专注于快速方便的开发单个个体微服务。
• SpringCloud是关注全 局的微服务协调整理治理框架，它将SpringBoot开发的一 一个个单体微服务整合并管理起来,为各个微服务之间提供:配置管理，服务发现，断路器，路由，微代理，事件总线，全局锁,决策竞选,分布式会话等等集成服务。
• SpringBoot可以离开SpringClooud独立使用，开发项目,但是SpringCloud离不开SpringBoot, 属于依赖关系
• SpringBoot专注于快速、方便的开发单个个体微服务, SpringCloud关注全局的服务治理框架

2.3 Dobbo 和 SpringCloud 技术选型

2.3.1 分布式+服务治理Dubbo

目前成熟的互联网架构: 应用服务化拆分+消息中间件

2.3.2 Dubbo 和 SpringCloud对比

最大区别: SpringCloud 抛弃了 Dubbo的RPC通信,采用的是基于HTTP的REST方式。
严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了.上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约, 不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。

2.3.3 SpringCloud下载地址

官网: https://spring.io/projects/spring-cloud#overview

学习参考书:

• https://springcloud.cc/spring-cloud-netflix.html
• 中文API文档: https://springcloud.cc/spring-cloud-dalston.html
• SpringCloud中国社区 http://springcloud.cn/
• SpringCloud中文网 https://springcloud.cc

3. 快速上手

3.1 总体介绍

3.2 SpringCloud 版本选择

大版本对应

Spring Boot	Spring Cloud
1.2.x	Angel版本
1.3.x	Brixton版本
1.4.x stripes	Camden版本
1.5.x	Dalston版本、Edgware版本
2.0.x	Finchley版本
2.1.x	Greenwich.SR2

在实际开发过程中，我们需要更详细的版本对应(部分)

SpringCloud版本	SpringBoot版本
2021.0.1-SNAPSHOT	Spring Boot >=2.6.4-SNAPSHOT and <2.7.0-M1
2021.0.0	Spring Boot >=2.6.1 and <2.6.4-SNAPSHOT
2021.0.0-RC1	Spring Boot >=2.6.0-RC1 and <2.6.1
2021.0.0-M3	Spring Boot >=2.6.0-M3 and <2.6.0-RC1
2021.0.0-M1	Spring Boot >=2.6.0-M1 and <2.6.0-M3
2020.0.5	Spring Boot >=2.4.0.M1 and <2.6.0-M1
Hoxton.SR12	Spring Boot >=2.2.0.RELEASE and <2.4.0.M1
Hoxton.BUILD-SNAPSHOT	Spring Boot >=2.2.0.BUILD-SNAPSHOT
Hoxton.M2	Spring Boot >=2.2.0.M4 and <=2.2.0.M5
Greenwich.BUILD-SNAPSHO	Spring Boot >=2.1.9.BUILD-SNAPSHOT and <2.2.0.M4
Greenwich.SR2	Spring Boot >=2.1.0.RELEASE and <2.1.9.BUILD-SNAPSHOT
Greenwich.M1	Spring Boot >=2.1.0.M3 and <2.1.0.RELEASE
Finchley.BUILD-SNAPSHOT	Spring Boot >=2.0.999.BUILD-SNAPSHOT and <2.1.0.M3
Finchley.SR4	Spring Boot >=2.0.3.RELEASE and <2.0.999.BUILD-SNAPSHOT
Finchley.RC2	Spring Boot >=2.0.2.RELEASE and <2.0.3.RELEASE
Finchley.RC1	Spring Boot >=2.0.1.RELEASE and <2.0.2.RELEASE
Finchley.M9	Spring Boot >=2.0.0.RELEASE and <=2.0.0.RELEASE
Finchley.M7	Spring Boot >=2.0.0.RC2 and <=2.0.0.RC2

目前我使用的版本是：SpringCloud Hoxton.SR12和 Springboot 2.3.4.RELEASE

3.3 创建父工程

• 新建父工程项目microservicecloud,切记Packageing是pom模式
• 主要是定义POM文件，将后续各个子模块公用的jar包等统一提取出来， 类似一个抽象父类

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.xz</groupId>
    <artifactId>springcloud</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>8</maven.compiler.source>
        <maven.compiler.target>8</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.data>1.8</maven.compiler.data>
        <junit.version>4.12</junit.version>
        <log4j.version>1.2.17</log4j.version>
        <lombok.version>1.18.22</lombok.version>
    </properties>

    <!--打包方式-->
    <packaging>pom</packaging>

    <dependencyManagement>
        <dependencies>
            <!--SpringCloud依赖-->
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Hoxton.SR12</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>

            <!--SpringBoot-->
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>2.3.4.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter</artifactId>
                <version>2.3.4.RELEASE</version>
            </dependency>

            <!--Mybatis 启动器-->
            <dependency>
                <groupId>org.mybatis.spring.boot</groupId>
                <artifactId>mybatis-spring-boot-starter</artifactId>
                <version>2.2.2</version>
            </dependency>

            <!--数据库-->
            <dependency>
                <groupId>mysql</groupId>
                <artifactId>mysql-connector-java</artifactId>
                <version>5.1.47</version>
            </dependency>
            <dependency>
                <groupId>com.alibaba</groupId>
                <artifactId>druid</artifactId>
                <version>1.2.8</version>
            </dependency>

            <!--日志/测试-->
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-core</artifactId>
                <version>1.2.11</version>
            </dependency>
            <dependency>
                <groupId>junit</groupId>
                <artifactId>junit</artifactId>
                <version>${junit.version}</version>
            </dependency>
            <dependency>
                <groupId>log4j</groupId>
                <artifactId>log4j</artifactId>
                <version>${log4j.version}</version>
            </dependency>
            <dependency>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>${lombok.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

可以视情况导入资源导入问题的配置:

<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <includes>
                <include>**/*.properties</include>
                <include>**/*.xml</include>
            </includes>
            <filtering>false</filtering>
        </resource>
        <resource>
            <directory>src/main/java</directory>
            <includes>
                <include>**/*.properties</include>
                <include>**/*.xml</include>
            </includes>
            <filtering>false</filtering>
        </resource>
    </resources>
</build>

3.4 项目结构

想要该项目的小伙伴可以私信跟我要~ 一起加油

4. Eureka服务注册与发现

4.1 什么是Eureka

4.2 原理

• Eureka的基本架构

  • SpringCloud 封装了NetFlix公司开发的Eureka模块来实现服务注册和发现(对比Zookeeper)

  • Eureka采用了C-S的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心

  • 而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。 这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一些其他模块(比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑;

  • 和Dubbo架构对比

    

  

  • Eureka包含两个组件: Eureka Server和Eureka Client。
  • Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册， 这样Eureka Server中的服务注册表中将会村粗所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。
  • Eureka Client是一个Java客户端， 用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后,将会向EurekaServer发送心跳(默认周期为30秒)。如果
    Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将 会从服务注册表中把这个服务节点移除掉(默认周期为90秒)

4.3 Eureka的自我保护机制

4.4 集群(关联)配置

注册

效果:

4.5 对比Zookeeper

CAP理论的核心

• 一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
• 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类:
  • CA: 单点集群，满足一致性，可用性的系统，通常可扩展性较差
  • CP: 满足一致性，分区容错性的系统, 通常性能不是特别高
  • AP: 满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心，Eureka比Zookeeper好在哪里?

Zookeeper保证的是CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接
down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP
Eureka看明白了这一-点， 因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时,如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:

1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用)
3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障 导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

5. Ribbon

5.1 简介

5.2 图示

6. Feign负载均衡

6.1 简介

Feign集成了Ribbon

• 利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。

7. Hystrix

7.1 简介

分布式系统面临的问题

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败!

什么是Hystrix
Hystrix是一个用于处理分布式系统的延迟和容错的开源库， 在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等, Hystrix能够保证在一个依赖出问题的情况下， 不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，向调用方返回一个服务预期的，可处理的备选响应(FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩.

Hystrix能做什么

• 服务降级
• 服务熔断
• 服务限流
• 接近实时的监控
• …

官网资料

https://github.com/Netflix/Hystrix/wiki

7.2 服务熔断&服务降级

​ 熔断机制是对应雪崩效应的一种微服务链路保护机制。

​ 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级,进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand.

7.3 DashBoard流监控

如何看

• 七色

  

• 一圈

  实心圆:公有两种含义,他通过颜色的变化代表了实例的健康程度

  它的健康程度从绿色<黄色<橙色<红色 递减

  该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大，该实心圆就越大，所以通过该实心圆的展示，就可以在大量的实例中快速发现故障实例和高压力实例。

  

• 一线

  曲线: 用来记录2分钟内流量的相对变化, 可以通过他来观察到流量的上升和下降趋势

  

• 整图说明

  

• 搞懂一个才能看懂复杂的

  

8. Zuul路由网关

8.1 概述

8.2 Zuul能干什么

• 路由
• 过滤
• …

官方文档: https://github.com/Netflix/zuul

9. SpringCloud config分布式配置

9.1 概述

什么是SpringCloud config分布式配置中心

​ Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环节提供了一个中心化的外部配置。

​ Spring Cloud Config 分为服务端和客户端两部分;

​ 服务端也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密,解密信息等访问接口。

​ 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。

SpringCloud config分布式配置中心能干嘛

• 集中管理配置文件
• 不同环境，不同配置，动态化的配置更新，分环境部署，比如/dev /test /prod /beta /release
• 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息。
• 当配置发生变动时，服务不需要重启，即可感知到配置的变化,并应用新的配置
• 将配置信息以REST接口的形式暴露

SpringCloud config分布式配置中心与github整合

​ 由于Spring Cloud Config默认使用Git来存储配置文件(也有其他方式，比如支持SVN和本地文件)，但是最推荐的还是Git，而且使用的是http/https访问的形式;