SpringCloud入门简述

1、微服务简述

​ 微服务，是一个小型的服务，也是一种设计理念，将一个大型繁杂的系统拆分为多个小型的服务，进行独立部署，这些服务在独立进程中运行，通过特定的协议进行通信

​ 优点：

1. 轻量化：一个服务不再像一个系统一个繁杂，更加小巧，功能相对单一
2. 低耦合：不同的服务模块之间的依赖性降低，可以更加专注于一个功能的开发
3. 灵活性高：可以进行独立的部署，也可以支持不同开发语言之间进行服务的调用

​ 缺点：

1. 运维成本高：微服务架构项目往往是由多个微服务构成，随着服务的增多，项目出现异常时不易查询根源
2. 重复性高：微服务的工具类不能够被其他服务调用，所以每个微服务都需要进行重复添加该类，导致重复
3. 接口调整成本高：一个被多个服务调用的服务一旦更改了接口，那么其他的接口也要做相应的修改，这一修改造成的成本会明显提高

1.1 常见的微服务框架

1. SpringCloud：SpringBoot基础上构建的微服务框架，通用组件较多，通信方式基于HTTP的rest方式
2. Dubbo：阿里巴巴的服务框架，使用RPC通信

​ 在服务通信性能上RPC更强，但是Rest更为灵活

1.2 微服务经常考虑的问题

1. 网关：提供统一的服务入口
2. 服务间调用
3. 服务发现：负载均衡时发现可用服务，下线不可用
4. 容错：服务调用失败的处理方式
5. 熔断：在特定场景下关闭服务的调用，防止错误的扩散
6. 限流和降级：请求数量过载，进行请求拒绝（限流）或者返回一个预先设置的返回值（降级）

2、SpringCloud简述

​ SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。

2.1 常用的一些组件

1. Netflix-Eureka：服务注册与发现
2. Netflix-Ribbon：负载均衡，分发请求到不同的服务器，缓解服务器压力
3. Netflix-Hystrix：服务保护与熔断机制
4. Netflix-Zuul：服务网关
5. Feign：服务间通讯
6. Config：配置中心

2.2 特点

​ ‎Spring Cloud专注于为典型的用例提供良好的开箱即用体验，并为其他用例提供扩展性机制。‎

• Distributed/versioned configuration——‎分布式/版本化配置‎
• Service registration and discovery——‎服务注册和发现‎
• Routing——‎路由‎
• Service-to-service calls——‎服务到服务呼叫‎
• Load balancing——负载平衡‎
• Circuit Breakers——‎断路器‎
• Global locks——‎全局锁‎
• Leadership election and cluster state——主节点投选与聚集状态
• Distributed messaging——‎分布式消息传递‎

2.3 与SpringBoot的区别

1. SpringBoot是基于Spring的快速配置脚手架，而SpringCloud是基于SpringBoot的云应用开发工具
2. SpringBoot专注于开发单个微服务，SpringCloud关注全局的微服务协调治理框架，用于整合管理SpringBoot开发的一个个微服务
3. SpringBoot可以离开SpringCloud独立开发使用，而SpringCloud离不开SpringBoot

参考地址：

1. Spring Cloud中文网-官方文档中文版：https://www.springcloud.cc
2. Spring Cloud中文API文档：https://www.springcloud.cc/spring-cloud-dalston.html
3. Spring Cloud中国社区：http://springcloud.cn/

3、Eureka 服务注册和发现

​ Eureka是Netflix开发的基于Rest的服务发现框架，SpringCloud基于此进行二次封装，实现服务的管理。

​ 创建一个Eureka服务：https://www.cnblogs.com/william-m/p/15991511.html

如果没有Eureka，如何进行服务之间的调用?

​ 使用Rest进行调用，先将RestTemplate注册到Bean，然后：

@RestController
public class MyController {
    private static final String REST_URL_PREFIX="http://localhost:8082";

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("user/getAll")
    public User getById(@RequestParam Long id){
        return restTemplate.getForObject(REST_URL_PREFIX+"/user/getAll/"+id,User.class);
    }

}

3.1 三个角色

• 注册中心

  Eureka Server，可以让其他服务将相关信息注册进去，然后让相关服务发现这些服务并来调用

• 服务提供者

  Eureka Client，将自身注册进Server中，提供自身的主机，端口，运行状况指示器URL，主页和其他详细信息让其他服务去发现，一般都是完成某些具体业务的服务

• 服务消费者

  Eureka Client，将自身注册进Server中，发现服务提供者并调用其相关接口，一般仅提供接口供外部调用，然后调用服务提供者的接口完成具体的业务

3.2 AP原则

C - consistency 强一致性

A - availability 可用性

P - partition tolerance 分区容错性

​ Eureka遵循的是AP原则，Eureka各个节点都是平等的，部分服务节点的下线不会影响正常服务的调用，只要该服务还剩下一个节点在线就可以进行正常的服务访问，即保证了服务可用，但是并不能保证查询到的信息是最新的。Zookeeper的CP原则与之不同，Zookeeper会有一个master节点来保证一致性，一旦master节点挂掉，剩余的节点会重新选举一个leader，而选择的过程需要时间，这期间会使得该服务瘫痪，所以需要满足高可用的话该情况是不能够容忍的。

4、Ribbon 负载均衡

​ Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，基于Netflix Ribbon实现，通过轮询、随机等算法选择一个可用服务。

​ 目的：将用户的请求平摊的分配到多个服务上，实现高可用

4.1 客户端负载均衡与服务器端负载均衡的区别

​ 最大区别：服务清单所存储的位置

• 服务器端负载均衡

​ 客户端先发送请求到负载均衡服务器，然后由负载均衡服务器通过负载均衡算法，在众多可用的服务器之中选择一个来处理请求。

• 客户端负载均衡

​ 客户端自己维护一个可用服务器地址列表，在发送请求前先通过负载均衡算法选择一个将用来处理本次请求的服务器，然后再直接将请求发送至该服务器。

4.2 服务调用

​ 逻辑时序：RestTemplate发起请求 → 负载均衡器拦截器拦截 → LoadBalanceClient获取ILoadBalance → 获取服务列表 → 根据负载均衡器选择一个server → 发起请求 → 记录调用信息

4.3 负载均衡算法重写

public class MyBalanceRule extends AbstractLoadBalancerRule {

    // 继承AbstractLoadBalancerRule并重写choose算法
    @Override
    public Server choose(Object key) {
        return choose(getLoadBalancer(), key);
    }

    public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            return null;
        }
        Server server = null;
        while (server == null) {
            if (Thread.interrupted()) {
                return null;
            }
            List<Server> upList = lb.getReachableServers();  // 获取活着的服务
            List<Server> allList = lb.getAllServers();   // 获取所有服务
            int serverCount = allList.size();
            if (serverCount == 0) {
                return null;
            }

            // =============================================
            //               自定义负载均衡算法
			// server = ......

            //===============================================
            if (server == null) {
                Thread.yield();
                continue;
            }
            if (server.isAlive()) {
                return (server);
            }
            server = null;
            Thread.yield();
        }
        return server;
    }
}

// 添加配置类，指定负载均衡算法
@Configuration
public class MyRuleConfig {
    @Bean
    public IRule myRule(){
        return new MyBalanceRule();
    }
}

5、Feign负载均衡

​ Feign是声明式的 web service 客户端，SpringCloud对Feign进行了封装，可以与Ribbon和Eureka使用以支持负载均衡，只需要创建一个接口并添加@FeignClient("服务名")注解即可。

5.1 Feign和Ribbon的区别

1. Application注解

   Ribbon使用@RibbonClient

   Feign使用@EnableFeignClients

2. 服务的指定

   Ribbon在@RibbonClient注解上声明

   Feign在接口中使用@FeignClient声明

3. 服务的调用

​ Ribbon基于HTTP和TCP客户端的负载均衡器可以自己构建HTTP请求，使用RestTemplate发送服务

​ Feign基于Ribbon进行改进，采用接口的方式，将需要调用的服务的方法定义成抽象方法

5.2 Feign的使用

Consumer应用

启动类

@EnableFeignClients
@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ChannelApplication.class, args);
    }
}

为了调用Product应用服务的接口类

@FeignClient(value = "Product")
public interface ProductService {

    @RequestMapping(value =  "/user/selectById", method = RequestMethod.GET)
    User selectById(@RequestParam(value = "id") Long id);

}

Product应用

controller

@RequestMapping("/user")
@RestController
public class ProductController {

    @RequestMapping(value =  "selectById", method = RequestMethod.GET)
    User selectById(@RequestParam(value = "id") Long id){
    	return "";
    }

}

6 、Hystrix 熔断

​ Hystrix是一个服务容错与保护的组件，用于服务降级、服务熔断、服务限流等等，能够保证在其中一个服务出现问题的时候，不会出现级联故障，防止雪崩，提高分布式服务的健壮性。

服务雪崩：微服务之间进行调用的时候，服务F同时被多个服务A、B、C、D调用，此时服务F发生故障（响应时间过长或者不可用等），对于服务ABCD的调用会占用越来越多的系统资源，引起系统整体的崩溃。

也就是说一个微服务的失败会引发整个系统的崩溃，像雪崩一样。

6.1 服务降级

​ 将某些服务停掉会i这不进行业务处理，释放资源来维持主要服务的功能。

6.1.1 使用场景：

1. 服务器压力剧增，为了保证核心业务的正常运行，对于一些不重要的服务进行有策略地不处理或者简单处理，保证不会和核心业务抢占资源
2. 某些服务不可用时，为了避免长时间的等待造成服务的卡顿雪崩，调用该服务时执行备用的降级逻辑，返回友好的提示，保障主题业务不受故障影响

6.1.2 降级方式

1. 接口拒绝服务：页面可以访问，进行增删改时提示服务器繁忙
2. 页面拒绝服务：页面提示繁忙他，跳转到其他静态页面
3. 延迟持久化：涉及增删改时提示稍后查看结构，不立即处理，将数据添加到异步队列，服务器空闲时处理
4. 随机拒绝服务：随机拒绝用户的访问，用户体验差，较少采用

6.2 服务熔断

​ 应对服务雪崩的一种保险措施，是微服务的链路保护机制，是服务降级的一种特殊处理方式。

​ 为了应对某个服务故障的情况，保证系统的整体可用性，熔断器会切断对该服务的请求，返回一个比较友好的错误响应，直到服务恢复正常

6.2.1 三种状态

​ 熔断机制的三种状态：

• 熔断关闭状态：业务正常访问时，熔断器关闭，服务可以正常调用
• 熔断开启状态：服务调用出错率达到阈值，开启熔断，对该服务的所有请求将会被切断，执行降级方法
• 半熔断状态：服务开启一段时间后进入半熔断状态，尝试恢复服务的调用，允许部分请求的调用并同时进行监控，如果成功率达到预期，则关闭熔断器，恢复服务的正常调用，否则开启熔断。

6.2.2 实现步骤

1. 当服务出现故障使得服务的调用失败率达到一个阈值，熔断器开启
2. 在熔断器开启时，对该服务的调用会转向设置的fallback降级方法，防止雪崩
3. 当熔断器开启达到一定的时间，进入半熔断状态，允许部分请求的调用，同时监控其成功率
4. 如果该服务的调用成功率达到预期，关闭熔断器，恢复原有服务的调用逻辑，否则继续开启熔断，重复234

示例：

// 在getUserById方法出现故障时执行getUserFallBack方法
@HystrixCommand(fallbackMethod = "getUserFallBack")
@GetMapping(value="getUserNameById")
public String getUserById(Long id){
        return UserService.selectById(id);
}

public String getUserFallBack(){
    return "请稍后再试";
}

6.3 熔断、降级、限流处理服务

熔断：直接切断服务的调用

降级：牺牲非核心业务保证核心服务的正常

限流：服务访问量达到阈值后拒绝多余的调用

7、Zuul网关

​ Zuul是一个微服务网关。网关：是一个网络系统的前置入口。也就是说要想访问一个有网关的网络系统请求相应的服务，需要先进入网关，然后路由到相应的服务。

​ 通常是组成一个系统的微服务很多、或者有权限要求时需要用到网关。

7.1 网关的作用

• 统一入口

  为全部的服务提供一个统一的入口，将内外隔离，保障了服务的安全性

  （如：多个微服务组成的系统拥有一个统一的请求入口）

• 鉴权校验

  识别每一个请求的权限，拒绝不符合要求的请求

  （如：校验用户的请求权限）

• 动态路由

  动态地将请求路由到不同的后端集群中

• 减少耦合

  减少客户端和服务端的耦合程度，使得服务可以独立发展，通过网关层来映射

7.2 过滤器

​ Zuul提供一个过滤器，父类为ZuulFilter，用来过滤代理请求，提供额外的功能逻辑（这点类似于AOP），包括前置过滤、路由后过滤、后置过滤、异常过滤。

​ ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run

• filterType

  返回一个字符串，代表过滤器的类型

  • pre：前置过滤，在请求路由之前执行，如：身份认证、日志记录等
  • router：在路由执行后，服务调用前被调用
  • error：处理请求发生错误时调用
  • post：请求到达服务之后执行，如：添加响应头，记录响应日志

​

• filterOrder

  过滤器的执行顺序，数值越小，优先级越高

• shouldFilter

  是否执行该过滤器，true，false

• run

  执行相关业务逻辑

8、Config配置中心

​ 当微服务众多的时候，想要管理各个服务的配置时过于繁杂，SpringCloud Config则可以用来对每个微服务的配置进行集中的管理。可以实现权限管控、灰度发布、版本管理、格式检验、安全配置等。

灰度发布：在进行产品研发时，新版本的发布可能存在一定的风险，那么让一部分用户继续使用A特性，并且提供B特性让部分用户使用，如果B特性口碑良好，产品稳定，就可以逐渐进行用户的迁移。灰度发布保证发生问题可以及时解决。就像是打游戏有个测试版本，如果测试用户对该版本满意，则可以继续发布到正式，用户不满意就能及时补救，反正没有发布到正式。

作用：

• 集中管理配置文件
• 在服务运行期间实现动态的配置刷新
• 实现属性值的加密解密
• 可以实现基于GIT进行版本管理

特点：

• 中心化管理
• 不限语言
• 灵活的版本控制