SpringCloud随笔
1.初识SpringCloud与微服务
背景：由于单体应用讲各种模块整合在一起，并且部署在一个进程内，所以我们通常对其中一个业务模块的修改也必须将整个应用重新打包上线。
为了解决单体应用变得庞大臃肿之后产生的难以维护的问题，微服务架构孕育而生。
1.1 什么是微服务
微服务 (Microservices) 是一种软件架构风格，主旨是将一个原本独立的系统拆分成多个在独立的进程中运行的小型服务，服务之间通过基于HTTP和RESTful API进行通信协作。
这种去中心化的模式，使得后期维护和开发变得更加灵活和方便。
1.2 什么是SpringCloud
SpringCloud是一个基于SpringBoot实现的微服务架构开发工具。SpringCloud的诞生并不是为了解决微服务中的某一个问题，而是提供了一套解决微服务架构实施的综合性解决方案。
它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
关于SpringCloud版本号：Spring Cloud是一个由各个独立项目组成的综合项目，每个独立项目有着不同的发布节奏，为了管理每个版本的子项目清单，避免Spring Cloud的版本号与其子项目的版本号相混淆，没有采用版本号的方式，而是通过命名的方式。这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序。比如”Angel”是Spring Cloud的第一个发行版名称, “Brixton”是Spring Cloud的第二个发行版名称。当一个版本的Spring Cloud项目的发布内容积累到临界点或者一个严重bug解决可用后，就会发布一个”service releases”版本，简称SRX版本，其中X是一个递增的数字，所以Brixton.SR5就是Brixton的第5个Release版本。
2. SpringCloud Eureka服务治理
2.1 服务治理
假如不存在服务治理的组件，对于微服务的实例A和B，当A需要调用B中的某个REST接口时，需要对B发起请求，此时，B服务的IP和端口信息作为静态资源配置在A服务中。当某天B服务进行了服务器的迁移，需要对A中的静态配置进行更改。
现实中服务间的关系往往是复杂的。
所谓服务治理，就是用来实现各个微服务之间的自动化注册与发现。在这种模式下服务间的调用不再是指定具体的实例地址来实现，而是通过向服务注册中心获取服务名，并发起请求调用实现。
2.2 Eureka
Eureka是Netfix开发的一款服务治理的开源框架。springCloud对它做了集成。它包含服务端和客户端。
服务端是一个微服务注册中心（Eureka Server)，提供服务的注册和发现。
客户端是一个服务提供者（Server Provider)，它将自己提供的服务注册到Eureka服务端，并周期性的发送心跳来刷新自己的服务租约，同时也能从服务端查询当前注册的服务信息并将它们缓存到本地并周期性的刷新服务状态。这样，服务的消费者（Server Consumer）便可以从服务注册中心获取服务名称，并消费服务。
Eureka的保护模式：
微服务部署后，可能因为网络问题无法及时发送心跳给Eureka服务端，这时候Eureka服务端认定Eureka客户端挂掉了，实际上Eureka客户端还在正常运行着。保护模式实际上就是为了解决这个问题，当Eureka服务端短时间内丢失了过多的Eureka客户端的时候，就会进入保护模式。不去剔除掉这些客户端。
2.3 Eureka集群
所有Eureka客户端都将自己提供的服务注册到Eureka服务端，然后供所有服务消费者使用。
当单节点的Eureka服务端宕机后，会导致所有的服务都无法正常访问，为了提高可用性，我们会讲Eureka进行集群部署，并且相互之间同步服务
eureka:
client:
register-with-eureka: false
fetch-registry: false
开启如上两个参数配置为true（默认为true），可以让当前的Eureka服务端将自己也作为服务注册到其他的Eureka服务端中去，并从别处的Eureka服务端获取服务进行同步。
2.4 Eureka-Server 添加认证
出于安全考虑，我们可能会对Eureka服务端添加用户认证的功能。
需要引入依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
然后在application.yaml中配置用户名密码
security:
basic:
enabled: true
user:
name: mrbird
password: 123456
服务端配置了密码后，所有的所有eureka.client.serviceUrl.defaultZone的配置也必须配置上用户名和密码，格式为：eureka.client.serviceUrl.defaultZone=http://${userName}:${password}@${hosetname}:${port}/eureka/，如：
eureka:
client:
serviceUrl:
defaultZone: http://mrbird:123456@peer2:8081/eureka/
2.5 Eureka配置总结
Eureka存在很多配置，可以参考EurekaClientconfigBean，EurekaServerConfigBean和EurekaInstanceConfigBean配置类的源码
| 配置 | 含义 | 默认值 |
|---|---|---|
| eureka.client.enabled | 是否启用Eureka Client | true |
| eureka.client.register-with-eureka | 表示是否将自己注册到Eureka Server | true |
| eureka.client.fetch-registry | 表示是否从Eureka Server获取注册的服务信息 | true |
| eureka.client.serviceUrl.defaultZone | 配置Eureka Server地址，用于注册服务和获取服务 | http://localhost:8761/eureka |
| eureka.client.registry-fetch-interval-seconds | 默认值为30秒，即每30秒去Eureka Server上获取服务并缓存 | 30 |
| eureka.instance.lease-renewal-interval-in-seconds | 向Eureka Server发送心跳的间隔时间，单位为秒，用于服务续约 | 30 |
| eureka.instance.lease-expiration-duration-in-seconds | 定义服务失效时间，即Eureka Server检测到Eureka Client木有心跳后（客户端意外下线）多少秒将其剔除 | 90 |
| eureka.server.enable-self-preservation | 用于开启Eureka Server自我保护功能 | true |
| eureka.client.instance-info-replication-interval-seconds | 更新实例信息的变化到Eureka服务端的间隔时间，单位为秒 | 30 |
| eureka.client.eureka-service-url-poll-interval-seconds | 轮询Eureka服务端地址更改的间隔时间，单位为秒。 | 300 |
| eureka.instance.prefer-ip-address | 表示使用IP进行配置为不是域名 | false |
| eureka.client.healthcheck.enabled | 默认Erueka Server是通过心跳来检测Eureka Client的健康状况的，通过置为true改变Eeureka Server对客户端健康检测的方式，改用Actuator的/health端点来检测。 | false |
3. SpringCloud Ribbon客户端负载均衡
负载均衡一般分为服务端负载均衡和客户端负载均衡，服务端负载均衡主要通过硬件（F5）或者软件（Nginx）来实现，而Ribbon实现的是客户端负载均衡。
负载均衡的原理是在硬件设备或者软件模块上缓存一份可用的服务清单，然后客户端发送服务请求到这些负载均衡的设备上，这些设备按照一定的负载均衡算法将这些请求转发出去。而客户端负载均衡是客户端自己从服务注册中心（如之前提到的Eureka Server）中获取服务清单缓存到本地，然后通过Ribbon内部算法均衡的去访问这些服务。
通过心跳检测，剔除故障的服务端结点。在客户端负载均衡中，也需要心跳去维护服务端清单的健康性。
3.1 Ribbon是什么
Ribbon是一款由Netflix开发的负载均衡的开源软件。我们可以选择提前配置好服务列表清单，也可以选择让它自己去获取服务清单。
通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单，只需要如下两步：
- 服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。
- 服务消费者直接通过调用被
@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。
4. Spring Cloud Hystrix 服务容错
在微服务中，会出现服务间的相互依赖，假设现在存在三个微服务节点：A\B\C，其中A作为B的消费者，B作为C的消费者，加入因为网络波动或服务自身故障，C服务无法正常提供服务，导致B调用C的线程被长时间的挂起等待。在高并发的情况下，可能导致B的资源被耗竭，导致B也崩溃了，从而导致服务A也不可用。出现这种连环式的雪崩效应。
为了解决这个问题，服务熔断技术应运而生。
熔断一词来自电路学，指的是电路中出现短路状况时，断路器能及时切断故障电路，避免因为电路过载发热引发火灾。
微服务架构中，断路器能够及时的发现故障服务，并向服务调用方返回错误响应信息，而不是长时间的等待。
Spring Cloud Hystrix在Hystrix的基础上进行了封装，提供了服务熔断，服务降级，线程隔离等功能，这些功能可以提供服务的容错率。
标签：服务,SpringCloud,Server,eureka,Eureka,随笔,服务端,客户端 From： https://www.cnblogs.com/radish40/p/16772587.html