SpringCloud的学习笔记

231 阅读9分钟

微服务的拆分注意事项:

1、不同微服务,不要重复开发相同业务
2、微服务数据独立,不要访问其他微服务的数据库
3、微服务可以将自己的业务暴露为接口,供其他微服务调用
上面的点可以结合自己的项目进行理解,面试可能会问你的项目多少微服务,一般五十人的团队三四十个微服务比较合适。

微服务之间的调用:

    思考不同的微服务之间怎么相互调用,不能直接访问别的微服务的数据库。
可以用RestTemplate来调用。
步骤:
    1、在微服务的配置类中注入RestTemplate这个bean,后期应该会有特定的配置类
    2、直接给RestTemplate调用方法参数中注入远程服务的路径,需要返回的类对象类型,他会自动将数据对象序列化。

微服务中Eureka的作用:

     如果服务的地址是不固定的,消费者怎么获取服务提供者的地址信息,多个服务提供者,怎么选择,怎么知道
 服务提供者的健康状态。
     所以我们应该有一个注册中心用来监控我们的微服务,他就是Eureka-Server,他管理的服务就叫Eureka-Client。
     Eureka-Server的作用:
         1、服务提供者向Server注册自己的信息,Server保存这些信息,然后消费者根据名称向Server拉取提供者信息。
         2、多个服务提供者的话Server负责进行负载均衡,从服务列表中挑一个。
         3、Eureka-Client每隔30S会向Eureka-Server发起心跳方便Eureka-Server进行管理,要是心跳不正常就会被踢除服务。

微服务怎么搭建:

首先是搭建Server
    1、引入依赖Eureka-Server
    2、在微服务的启动类上面加上注解@EnableEurekaServer
    3、配置文件中配置好服务端口、服务名称、并且在服务上面注册自己,这个是为了后面Server集群的准备。
搭建Client
    1、引入依赖Eureka-Client
    2、配置文件中配置好服务名称,并在服务上注册自己的地址
搭建好了之后,我们在RestTemplate上面的方法中,将地址参数改为服务名称即可
这里如果希望服务被负载均衡的调用,应该在注入RestTemplate的类上面加上@LoadBalanced注解,这里
你希望谁负债均衡的调用别的服务就在谁上面加注解,也就是说这里的注解应该加在服务的消费者上面。

Ribbon负载均衡

底层其实就是个拦截器,拦截了所有的RestTemplate调用的接口,在通过调用的是哪个服务来判断对应的ip,拼接好正确的url之后,在通过HTTP请求再去请求对应的接口就可以了。
有两种方式可以更改Ribbon的负载均衡策略:
    1、代码方式,在微服务的启动类或者配置类中定义一个新的IRule类然后注入进去
    2、在yml文件中,修改Ribbon的负载均衡策略
在yml文件中也可以通过注解开启Ribbon的饥饿加载。

SpringCloudAliBaBa之Nacos:

使用Nacos的步骤:
    1、将之前Eureka的依赖改为Nacos
    2、在配置文件中将服务端地址改成Nacos的地址
    3、其他的代码都不需要改动,都是通过RestTemplate来调用
Nacos的服务分级:
    在Nacos的服务分级中,依次是服务->集群->实例,同一个地域的就是一个集群,这样做是为了防止跨集群调用延迟过高的问题。
    要配置集群也很简单,只需要在配置文件中配置好cluster-name就好了。
    配置好了集群之后要想达到同一集群优先调用,需要在配置文件中对Ribbon做一下配置。
    如果某个集群的服务都挂了,会出现跨集群访问,这种情况会在Nacos中报警。
Nacos修改服务的权重:
    直接在控制台编辑修改就好了,权重值越小,被访问的次数相对来说越少。修改权重这个功能可以用在项目更新的清况,如果版本升级了,可以将一个服务的权重调小,然后最后到0,迭代好了再把权重调回来,其他的服务按照这个清况来一遍就好了。
Nacos的环境隔离:
    在业务层次上,我们将服务划分成为了服务,集群,实例,在实际开发中还会有生产环境,开发环境的一些区分,所以环境隔离就是用来做这个的。
    怎么做:
        1、在控制台新建好不同的namespace
        2、在服务的yml配置文件中配置好服务对应的命名空间的ID,重启服务即可
    效果:
        不同环境的服务是不能相互访问的
Nacos充当配置管理:
    直接在控制台新建配置文件,然后在配置文件区域将配置文件写好保存即可。
    在没有Nacos的时候,项目读取配置文件的过程是:项目启动->读取本地配置文件->创建Spring容器->加载bean
    所以我们的配置管理交给Nacos之后,我们的项目流程就变成了:先读取Nacos中的配置文件->读取本地配置文件->创建Spring容器->加载bean
    但是这样的话,由于我们的Nacos的地址在本地配置文件中,所以我们得先把与Nacos地址有关的配置文件信息都放在最先加载的bootstrap配置文件中。
    Nacos充当配置文件管理的步骤:
        1、引入Nacos-config的依赖
        2、这一步是通过Nacos来读取配置文件,在项目的resource添加一个bootstrap配置文件,这个文件是引导文件,优先级高于application.yml,在这个配置文件中应该配置好服务名称,服务的开发环境,服务的地址,服务的配置后缀名
    Nacos配置热更新:
        只需要在微服务上面的controller类上面加上注解@RefreshScope这种方式虽然很简单,但是其实还有另外一种更加规范的方式。
        配置热更新的第二种方式:单独做一个热更新的配置类,在这个配置类里面对那些需要读取的配置用@ConfigurationProperties
    Nacos的配置环境共享:
        什么情况下需要用到这个呢,一些配置在不同的环境下是不变的,这种情况下,我们可以用这种多环境配置文件共享。
        实现步骤:直接在Nacos的配置文件管理那里新建一个服务名称.yml的配置文件,在这个配置文件配置的都会被该服务共享。
        多服务配置的优先级:服务名称-profile.yaml>服务名称.yaml>本地配置
Nacos的集群部署:后面有时间再更新

SpringCloud之Feign:

     首先还是要知道为什么要用fegin,之前我们不同微服务之前的访问是通过RestTemplate来实现的,但是这样的话
有很大的问题,在RestTemplate里面我们还需要传入我们的微服务url路径以及返回值类型,这很不优雅,尤其是你的微
服务的url路径比较长的时候,很不好维护,所以我们需要一个声明式的远程调用服务,只需要我们配置好,就可以直接用,
这个就是Feign
     使用Feign的步骤:
         1、引入openfegin的依赖
         2、在服务的启动类中加入@EnableFeignClients的注解
         3、编写Feign的客户端,申明服务名称、服务路径、请求方式、请求参数、返回值类型
         注意事项:比如你要在订单微服务中调用用户的微服务,你需要在订单微服务中将需要访问的服务名称和服务路径等信息写上,调用的时候直接用方法调用即可。
     feign的优化:
         1、feign的底层客户端默认实现是URLConnetion,他不支持连接池,可以使用Apache HttpClient或者OKHttp代替默认的URLConnetion
             这个优化的步骤:
             1.1引入httpClient的依赖 
             1.2在配置文件中启用httpClient,然后配置好连接池参数
         2、日志级别最好用basic或者none
    Feign的最佳实践:
        方式一:给消费者的FeignClient和提供者的controller定义统一的父接口作为标准,但是这种方式会导致服务之间紧耦合,不利于后期的迭代和维护。
        方式二:将feign的相关信息和功能都抽取到一个单独的模块中,做成依赖,谁要用,直接引入依赖就好了

SpringCloud之GateWay

    首先我们先思考一下为什么需要网关:很多微服务是不需要暴露给用户的,利用网关可以对一些请求做身份认证和权限校验,还可以做服务路由,负载均衡,请求限流。springcloud有两个网关的组件,一个是zuul,一个是gateway,后者比较新,用的人多一些。
    Gateway网关服务的搭建:
        1、创建一个新的服务,然后引入gateway的依赖
        2、配置文件中配置好网关服务的端口,服务名称,nacos地址,路由规则(路由规则主要是路由id以及这个id对应的服务地址或者名称,以及路由断言,这个断言就是网关的具体匹配规则)
    网关的请求流转:
        请求来到了gateway->gateway做一下路由规则判断->拉取服务列表->负载均衡发送请求

SpringCloudAliBaBa之Sentinel

学习这个框架之前,需要知道一些微服务的常见问题以及解决方案:
    什么是雪崩问题?
        微服务之间调用比较复杂,调用链中如果一个出现了问题,那么很容易导致整条调用链路都无法访问。
    如何避免因瞬时高并发流量而导致服务故障?
        对流量做一些控制
    如何避免因故障导致的雪崩问题?
        超时处理:给业务设定超时时间,如果超时了,就释放资源返回异常信息
        线程隔离:每一个业务隔离开,设置单独的线程隔离池,如果这个业务出问题了,那么最多耗尽他这个业务对应的线程隔离池资源
        降级熔断:统计一个业务的故障比例,如果比例过高,就标记为异常业务,做一些降级的处理或者阻止请求访问该业务