SpringCloud

技术栈图例：

            

            

概述：

　　1.注意springboot与SpringCould的版本兼容关系

       2.微服务拆分的目的：贯彻单一职责，一个服务（功能模块）只做与自己相关的事情。

       3.拆分的原则：①不同微服务，不要重复开发相同业务；

                                ②微服务数据独立，不要访问其它微服务的数据库；　　

                                ③微服务可以将自己的业务暴露为接口，供其它微服务调用。

       4.远程调用(初始微服务)图例：

                  

 　　实现：要想实现跨服务远程调用，即实现http请求。先在Spring容器中注入一个RestTemplate对象，再利用RestTemplate中的getForobject方法告知请求的url路径与返回值类型（它会自动将JSON转化成相应类型），最后封装。

        代码：

               

　　5.服务提供者与服务消费者

　　服务提供者：提供接口给其它微服务；

       服务消费者：调用其它微服务提供的接口。

       服务A调用服务B，服务B调用服务C，服务B是什么角色？ 一个服务既可以是提供者，又可以是消费者（提供者与消费者角色是相对与业务而谈的）。

Eureka注册中心

　　作用：为了解决上述代码中地址硬编码的问题（服务地址是会发生变化的）。 

　　图例：

               

　　服务调用出现的问题：

       Ⅰ.服务消费者该如何获取服务提供者的地址信息?服务提供者启动时向Eureka注册自己的信息；

                                                                                Eureka保存这些信息；

  　　　　　　　　　　　　　　　　　　　　     消费者根据服务名称向Eureka拉取提供者信息；

      Ⅱ.如果有多个服务提供者，消费者该如ge何选择？服务消费者利用负载均衡算法，从服务列表中挑选一个。

      Ⅲ.消费者如何得知服务提供者的健康状态？服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态；

                                                                          Eureka会更新记录服务列表信息，心跳不正常会被剔除；  

　　　　　　　　　　　　　　　　　     　   消费者可以拉取到最新信息。

　　搭建Eureka服务：

　　　　①在项目下新建model，引入eruka-server依赖

                  

　　　　②在Eureka启动类中添加@EnableEurekaServer注解

                  

 　　　　③在yml文件中配置地址

                   

　　　　　注：Eureka自身也是一个服务。

　　Eureka服务注册步骤：

　　　　①引入eureka-client依赖

                 

　　　　②在yml中配置eureka地址

                 

　　　　③结果图

                 

　　　　总结：无论是消费者还是提供者，引入Eureka-client依赖+Eureka地址，都可以完成服务注册。

　　Eureka服务拉取：

　　　　路径： 

　　　　在服务容器上加负载均衡注解：

Ribbon负载均衡

　　图例：

              

Nacos注册中心

　　Nacos服务注册：

　　　　①在主工程pom文件中引入依赖，并注掉Eureka依赖

                  

　　　　②在副工程pom文件中引入客户端依赖

                  

　　　　③配置yml文件，在spring中配置即可。

                  

　　　　④结果图

                  

　　　　注：一个服务可以包含多个实例

　　Nacos服务分级存储：

　　　　图例：　　

                      

　　　　服务跨集群调用：服务调用尽可能选择本地集群的服务，跨集群调用延迟较高；

                                          本地集群不可访问时，再去访问其它集群。

　　设置实例的集群属性：

　　　　①在yml中配置，选中执行。

                  

　　　　②分别设置

                  

　　NacosRule负载均衡：

　　　　此时集群的作用并没有体现出来，如果进行访问还是会所有实例都被访问。在实例中配置NacosRule将会优先访问本地集群。（非轮询而是随机）。本地集群实例端口关闭时，将会自动跨集群访问。

              

              

              

             

 　　服务实例的权重设置：Nacos直接修改即可。权重越高被访问的频率越高，权重调为0时不会被访问。

          

 　　Namespace-环境隔离：

 　　　　 Nacos不仅是一个服务注册器，还是一个数据中心。

    

　　　　操作： 在Nacos控制台中选择命名空间>>>>新建命名空间>>>>>复制命名空间ID>>>>修改实例yml

                          

　　　　总结：Ⅰ每个Namespace都有唯一id；

                         Ⅱ不同namespace下的服务不可见。

　　Nacos统一配置管理：在Nacos中的配置管理面板中新建配置，ID必须唯一故一般命名格式： 微服务名称-环境（开发、测试..).格式，配置内容中进行书写模板。

                 

　　　　配置获取：没有Nacos时配置

               

　　　　有Nacos配置时：

               

　　　　操作：

　　　　　　①在对应的微服务pom文件中引入依赖

                         

　　　　　　②在resources目录下新建bootstrap.yml文件并配置相应信息：nacos地址、当前环境、服务名称、文件后缀名。这些决定了程序启动时去nacos读取哪个文件。

                         

　　　　　　③在controller中可以新建Value检验是否被读取

                         

　　配置热更新/自动更新操作：

  　　  ①在对应的controller类＋@RefreshScope注解

               

  　　  ②@ConfigurationProperties（prefix = "前缀名"）  注：约定大于配置。 例：先定义一个配置类，在将其注入成Bean方便调用。在UserController中注入类进行调用。

               

               

　　多环境配置共享：

               

　　多环境下的优先级问题：

               

Gateway网关

　　作用：①对用户请求做身份验证、权限校验；

                  ②将用户请求路由到微服务并实现负载均衡；

                  ③对用户请求做限流。

　　网关搭建步骤：

　　　　Ⅰ引入Model，在其对应pom文件中引入网关依赖、微服务发现依赖。

                  

   　  　Ⅱ 编写路由配置及Nacos地址，新建yml完成如下配置，通过新路径可得到结果，

                  

                  

　　流程图：

               

路由断言工厂

　　作用：读取用户配置的断言规则，然后解析成对应的条件

                  

路由过滤器

　　概述：GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理。

　　图例：

               

　　作用：Ⅰ对路由的请求或响应做加工处理，比如添加请求头；

　　　　　Ⅱ配置在路由下的过滤器只对当前路由的请求生效。

　　defaltFilters的作用：routes同级下配置，对所有路由器都生效。

                  

全局过滤器

　　概述：通过exchange做校验，chain放行，@Order注解定义顺序

　　作用：对所有路由都生效的过滤器，并且可以自定义处理逻辑。

　　步骤：实现GlobalFilter接口>>>>添加@Order注解或实现Order接口>>>>编写处理逻辑

                 

　　过滤器执行顺序：

　            

              

　　总结：Ⅰoder值越小，优先级越高；

  　　　　 Ⅱorder值一样时，顺序是defaultFilter优先，然后是局部的路由过滤器，最后是全局过滤器。

Docker 

　　作用：快速交付应用、运行应用技术。解决微服务部署问题，如：由于依赖关系复杂出现的兼容问题，开发、测试、生产环境有差异等。

　　解决方案：Ⅰ兼容问题： 将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包，形成可移植镜像；

 　　　　                                 将每个应用放到一个隔离容器去运行，使用沙箱机制相互隔离。

　　　　　　　Ⅱ环境差异问题：Docker镜像中包含完整运行环境，包括系统函数库，仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行。

Docker架构

　　镜像：Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。

　　容器：镜像中的应用程序运行后形成的进行就是容器，只是Docker会给容器做隔离，对外不可见。

　　DockerHub：DockerHub是一个Docker镜像的托管平台。这样的平台称之为Docker Registry。

　　Docker是一种C/S架构，由两部分组成：

　　　　服务端：Docker守护进程，负责处理Docker指令，管理镜像、容器等。

　　　　客户端：通过命令或RestAPI向Docker服务断发送指令，可以在本地或远程向服务端发送指令。

Docker基本操作

镜像操作

　　镜像名称一般分为两部分组成： [repository]:[tag]    注：[   ]/[版本]，没有指定tag时默认为latest，代表最新的版本。

       

 

 

　　命令：docker --help  //查看docker中所有命令

　　　　　docker images //查看本地镜像

　　案例：利用docker save将nginx镜像导出磁盘，再通过load加载回来

　　

　　解决：

        

容器操作

       

 　   docker run（创建并运行一个容器）命令的常用参数： --name //指定容器名称， -p //将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口   -d //让容器在后台运行

　　docker logs //查看容器日志，添加 -f 参数可以持续查看日志

　　docker ps //查看容器状态

　　案例：创建一个nginx容器

　　方案：

数据卷

　　作用：解决容器与数据耦合的问题（不便于修改、数据不可复用、升级维护困难），保证数据安全。

　　概述：一个虚拟目录，指向宿主机文件系统中的某个目录。　　

　　逻辑图：

        

　　操作：

       

 

　　案例：创建数据卷，并查看数据卷在宿主机的目录位置。

　　解决：

       

 

DockerCompose

　　作用：基于Compose文件快速部署分布式应用。

　　概述：Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。

MQ

　　同步通讯：如打视频，一个时间段只能与一人交流。（时效性较强，可以立即得到结果。）

       

　　同步调用存在的问题：

　　　　 1.耦合度高；每次加入新的需求，都要修改原代码。

　　　　 2.性能下降；调用者需要等待服务提供者响应，如果调用链过长则响应时间等于每次调用时间之和。

　　　　 3.资源浪费；调用链中的每个服务在等待响应的过程中，不能释放请求占用的资源，高并发场景下会极度浪费系统资源。

　　　　 4.级联失败；如果服务提供者出现问题，所有调用方都会跟着出问题。如同多米诺骨牌一样，迅速导致整个微服务群故障。

　　异步通讯：如微信聊天，一个时间段可以与很多人交流。（可能存在时效长的问题）常见实现是事件驱动模式。

　　工作流程：在同步调用中，当支付服务功能响应时会依次调用订单服务、仓储服务等功能。在异步通讯中，为了解决高耦合、性能低的问题，引入了事件代理者Broker。何为事件代理模式？在系统中，当产生支付业务时即为一个事件。而其它被调用功能模块，需要订阅Broker（接收通知，同时通知所有模块）完成对应工作。

        

　　异步通讯优势：

　　　　1.服务解耦；新增业务无需在修改支付模块代码。

　　　　2.性能提升，吞吐量提高；用户会在第一时间收到支付成功的消息，后续订单的所有操作不在占用支付服务事件。

　　　　3.服务没有强依赖，不担心级联失败问题；如支付成功后，某个被调用模块产生问题不影响支付服务模块使用。

　　　　4.流量销峰；

　　异步通讯缺陷：

　　　　1.过于依赖broker的安全性，可靠性，吞吐能力；

　　　　2.架构复杂，业务没有明显的流程线，不好追踪管理。

　　注：broker可以看为消息中间件的服务端，每一个服务既可以是发布者也可以是订阅者。

MQ概念

　　MQ——消息队列，即存放消息的队列也就是事件驱动架构中的broker。