SpringCloud——微服务

与SpringBoot的关系：

• SpringBoot是用于构建单个Spring应用的框架，而SpringCloud是用于构建分布式系统中的微服务架构的工具，SpringCloud提供了服务注册与发现、负载均衡、断路器、网关等功能。
• 二者可结合使用，通过SpringBoot构建单个微服务应用，然后用SpringCloud来实现微服务架构中的各种功能。

微服务常用组件：

• 注册中心：微服务核心组件。每个微服务都是独立而分散的，当各个微服务进行通信时，可能会出现该微服务已经无法响应的问题，同时我们难以知晓哪个服务实例是可用的。注册中心的作用便是对新节点的注册与状态维护，解决了如何管理新节点以及检查各节点运行状态的问题。
• 服务通信：解决了服务间进行消息通信的问题。服务间一般采用轻量级协议，通常是HTTP RESTful风格。但因为RESTful风格过于灵活，必须加以约束，通常应用时会对其进行封装。例如在SpringCloud就提供了Feign和RestTemplate来屏蔽底层实现，基于封装后统一的SDK进行开发。
• 服务发现与负载均衡：解决了如何发现服务并通过负载均衡选择适合的服务实例的问题。使用硬编码指定IP、端口进行通信的灵活度差，且对于服务的耦合性较高。且硬编码形式无法通过负载均衡来平衡服务压力。所以微服务框架采用服务注册+服务发现的形式，解耦调用方与服务方。由注册中心来管理所有实例的服务信息（IP、端口和健康状态），服务调用方可通过命名动态发现可用的服务实例列表，在这个过程中服务调用方或注册中心实现负载均衡来选择最合适的服务实例进行通信。
• 配置中心：解决了集中存储和管理各节点配置文件的问题。每个微服务的配置文件是独立的，包含jdbc配置、自定义配置、环境配置和运行参数配置等，当我们某个配置信息发生变动时，可能触及多个微服务配置文件的变更，这时候逐个调整各个节点对运维带来的压力极大。配置中心由此而生，配置中心将各节点配置文件从微服务中剥离，统一存储到配置中心中并进行持久化处理，而服务则是采用动态推送/拉取+本地缓存的形式获取最新的配置。
• 集中式日志管理：解决了如何收集各节点日志并统一管理。微服务默认将日志保存在当前服务中，与配置文件有所差别，日志一般无需物理集中存放，但需要一种收集方式来快速准确的定位到对应服务的日志。业内常见的方案有ELK/EFK（E指ElasticSearch）。通过搭建独立的日志收集系统，定时抓取各节点增量日志形成有效的统计报表，便于统计和分析。
• 服务保护：解决了如何对系统进行链路保护，避免服务雪崩的问题。在业务运行时，微服务间互相调用支撑，若某个微服务出现高延迟导致线程池满载或业务处理失败，就需要引入服务保护组件来进行服务熔断或快速降级，避免系统崩溃。

Spring Cloud Alibaba实现的微服务架构：

• 注册中心与服务发现：使用Alibaba Nacos组件实现注册中心，提供动态服务发现
• 服务端负载均衡：在Nacos服务端实现负载均衡，与Ribbon在调用端负载均衡不同，Nacos是在服务发现的同时利用负载均衡返回服务节点数据。
• 服务通信：使用Netflix Feign（Open Feign）和Alibaba Dubbo来实现服务通信，前者与SpringCloud采用的方案相同，后者则是对自家RPC框架也给予支持.
• 网关：在API服务网关组件中，使用与SpringCloud相同的组件，即SpringCloud GateWay
• 配置中心：配置中心组件使用Nacos内置配置中心，可将配置信息存储保存在指定数据库中
• 日志集中管理：在原有ELK方案外，还可以使用阿里云日志服务（LOG）实现日志集中式管理

负载均衡有哪些算法：

• 简单轮询：将请求按顺序分发给后端服务器，不关心各服务器当前性能和负载状态。
• 加权轮询：根据服务器性能给服务器设置不同权重，将请求按顺序和权重分发给后端服务器。
• 简单随机：将请求随机分发给后端服务器上，请求越多各个服务接受到的请求越平均。
• 加权随机：根据服务器自身性能给服务器设置不同权重，将请求按各个服务器的权重来随机分发给后端服务器。权重高的服务器随机分配到的请求也更多
• 一致性哈希：根据请求的客户端ip或请求参数通过哈希算法得到哈希值，取模后映射出对应的后端服务器，这样能保证同一个客户端或相同参数的请求每次都使用同一台服务器。
• 最小活跃数：统计每台服务器正在处理的请求数，也就是请求活跃数，将请求分发给活跃数最少的后台服务器。

服务熔断

应对微服务雪崩效应的一种链路保护机制，类似于保险丝。

例如某服务链路为A—B—C，若C响应时间过长或不可用，随着时间增长，频繁调用会导致C崩溃，但此时B的业务线程还在继续被占用，导致B的线程池满和崩溃，进而导致A的线程池满，最终导致全链路微服务的崩溃和不可用。

所以当某个服务不可用或响应超时时，为了防止整个系统出现雪崩，会暂时停止对该服务的调用，快速返回错误的响应信息释放线程资源。

服务降级

服务器压力剧增时，根据实际业务使用情况以及流量，对一些服务和页面有策略的不处理或使用简单方式处理，从而释放服务器资源以保证核心业务的正常高效运行。

高峰期为保证核心功能服务的可用性，就需要对某些服务降级处理。也可以理解为舍小保大。

为了预防某些功能出现负荷过载或响应慢的情况，在其内部暂时舍弃一些非核心接口和数据的请求，直接返回一个提前准备号的错误处理信息，这样虽然有损于服务，但保证了整个系统的稳定性和可用性。