SpringCloud学习笔记

网站：https://springcloud.cc/spring-cloud-dalston.html

一、网站架构演变过程

从传统项目（单点应用）→分布式架构（以项目进行拆分）→SOA架构（面向服务架构）→微服务架构

传统项目架构：

其实就是SSH或SSM，属于单点应用，把整个业务模块都会在一个项目进行开发，分为MVC架构，会拆分控制层，业务逻辑层、数据持久层。

com.controller

com.service

com.dao

一般只适合于一个人或小团队开发

缺点：耦合度太高，一旦某个模块不可用，可能会影响其他模块。

分布式架构：

是基于传统架构演变过来的，将传统项目以项目模块进行拆分n多子项目，比如拆分成会员项目，订单项目，支付项目，优惠卷等，每个项目都有自己独立的数据库，独立redis等。

总结：分布式架构跟传统架构的区别：项目粒度更加细，慢慢开始适用于互联网公司开发，耦合度降低。

SOA架构

它也是基于分布式架构演变过来的，SOA架构是面向服务架构，俗称服务化，可以理解为面向业务逻辑层，将共同的代码抽取出来，提供给其他接口调用。服务与服务之间通讯采用rpc远程调用技术。

服务概念：将共同的业务逻辑进行拆分，拆分独立一个项目进行部署，没有视图层 类似于webservice项目

Webservice底层是采用Http协议+XML（soap）。

RPC是远程调用技术，两个或者多个应用实现远程调用。

rpc远程调用技术特点：httpClient、springcloud、dubbo、grpc 核心底层socket或者netty实现。

SOA架构特点：

底层基于SOAP或者ESB（消息总线）实现，底层使用HTTP协议或者 HTTPS协议+重量级XML数据交换格式进行通讯。

SOA架构缺点：

1、依赖于中心化服务发现机制

2、因为SOA机构采用SOAP协议（HTTP+XML），因为XML传输协议比较占用宽带，整个XML的报文中又有非常大的冗余数据，所以在微服务中用json轻量级方式替代了XML报文传输。

3、服务管理非常混乱，缺少服务管理和治理，设施不完善。

微服务架构模式：

微服务架构是从SOA架构上演变过来的，比SOA架构上粒度更加精细，让专业的人做专业的事情，目的是为了提高效率。

每个服务与服务之间互不影响，每个服务必须独立部署（独立数据库，独立redis），微服务框架更加体现轻量级，采用restful风格提供API，也就是使用http协议+json格式，更加轻巧，更加适用于互联网公司敏捷开发，快速迭代产品。

二、SpringCloud简介

SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务框架，其内容包含服务治理、注册中心、配置管理、断路器、只能路由、微代理、控制总线、全局锁、分布式会话等。

SpringCloud包含众多子项目：

           SpringCloud config 分布式配置中心

           SpringCloud netflix 核心组件

           Eureka 服务治理 注册中心

           Hystrix 服务保护框架

           Ribbon 客户端负载均衡器

           Feign 基于Ribbon 和hystix 的声明式服务调用组件

           zuul 网关组件，提供智能路由、访问过滤等功能

三、SpringCloud服务注册与发现

SpringCloud支持三种注册中心

Eureka、Consul（go语言编写）、Zookeeper

使用注册中心的目的？？？

服务治理、服务的注册与发现能有实现负载均衡，管理服务与服务之间的依赖关系。

Dubbo支持常用两种：zookeeper和Redis

1、服务注册与发现原理 在任何rpc远程框架中，都会有一个注册中心

2、注册中心概念：存放服务地址相关信息

      微服务的负载均衡：本地负载均衡

      服务注册：将服务信息注册到注册中心

      服务发现：从注册中心上获取服务信息

1、Eureka的使用：

案例：订单服务调用会员服务：

第一步：首先启动注册中心

第二步：启动会员服务

第三步：会员服务在启动的时候，会把当前服务基本信息 比如服务的地址、端口 以别名的方式注册到注册中心上去 serviceid name value 127.0.0.1:8080 128.0.0.1:8080 有集群的情况下可以存放多个

第四步：消费这在调用接口的时候，使用服务别名也就是serviceId去注册中心获取实际rpc远程调用地址，地址会缓存在jvm内存中，默认情况下eureka每隔30秒更新一次服务地址

第五步：如果消费者获取到实际的PRC远程调用地址之后，在本地使用HttpClient技术实现调用

如果让你来设计一套微服务rpc远程调用框架，你如何来设计？

核心在于服务治理---注册中心。

2、搭建Eureka集群

原理：eureka搭建集群原理使用相互注册原理，形成一组相互注册的注册中心。从而实现数据交互的同步，达到高可用效果。相互注册

在注册过程中，只会保证一台注册中心服务有对应服务信息数据，当8100注册中心宕机之后，启动转移同步数据到9100上去。

3、Eureka的自我保护机制？

为了防止EurekaClient可以正常运行，但是与EurekaServer网络不通的情况下，EurekaServer会误将EurekaClient服务进行剔除，（5秒心跳时间 90秒时间保护时间）

什么环境开启自我保护机制？

本地开发环境禁止自我保护机制，详细配置见文档

生产环境建议开启

4、Ribbon与Nginx实现负载均衡的区别

Ribbon本地负载均衡，原理：在调用接口的时候，会从eureka注册中心获取到注册服务信息列表，获取到之后会缓存在jvm本地，让你使用本地实现rpc远程调用技术调用调用，即是客户端实现负载均衡。

Nginx是服务器负载均衡，客户端所有请求都会交给nginx，而后让nginx实现转发请求，即是服务器端实现负载均衡。

应用场景：

Ribbon本地负载均衡器适合在微服务RPC远程调用，比如dubbo，springCloud

Nginx服务器负载均衡 适用于针对服务器端，比如tomcat、jetty等

SpringCloud feign客户端时默认开启ribbon的；

四、服务雪崩效应

默认情况下tomcat只有一个线程池去处理客户端发送的所有请求，这样的话在高并发的情况下，如果客户端所有的请求堆积到同一个服务接口上面，就会产生tomcat所有的线程去处理该服务接口，可能会导致其他服务接口无法访问，就会导致其他服务接口访问的时候，产生延迟和等待。

tomcat默认有50个线程去处理请求

五、Hystrix服务保护框架

在微服务中Hystrix能够为我们解决什么事情？

实现的两种方式 注解 、 接口

1、断路器

2、服务降级（友好提示）

在高并发的情况下，防止用户一直等待，使用服务的降级方式（返回一个友好的提示直接给客户端，不会去处理请求，调用fallBack本地方法），目的为了用户体验

比如 秒杀活动------当前请求人数过多，请稍后重试

（在tomcat中没有线程去处理客户请求的时候，不应该让用户一直在转圈等待）

如果调用其他接口超时的时候（默认时间是1秒），业务逻辑是正常访问的，要是没有即时返回就会走服务降级方法。1秒说的是浏览器的相应时间，不是调用接口时间

3、服务熔断

目的为了保护服务，在高并发的情况下，如果请求达到了一定极限（可以自己设置阈值），如果流量超出了设置的阈值，自动开启保护服务功能，使用服务降级方式返回一个友好的提示。

熔断跟降级是一起使用的。

4、服务隔离机制

两种方式：

（1）线程池隔离机制：每个服务都有自己的线程池，每个线程池互不影响，不是所有的接口都需要采用线程池隔离

缺点：CPU占用率过高

（2）信号量隔离

5、雪崩效应 连环雪崩效应，比较严重的话，可能会导致整个系统瘫痪

解决雪崩效应的原理：

降级、隔离、熔断

六、SpringCloud分布式配置中心

1、为什么要使用分布式配置中心？

背景：在微服务如果使用传统的方式管理配置文件，配置文件管理器非常复杂。

如果生产环境配置文件需要改变的时候，需要重新打war，重新读取配置文件。

2、什么是分布式配置文件中心？

在微服务当中使用同一个服务器管理所有的配置文件信息，能够实现后台可管理，当服务器正在运行的时候，如果配置文件信息需要改变，可以实现不重启服务器实时更改配置文件信息。

3、分布式配置中心框架

阿波罗 携程写分布式配置中心 有图形界面可管理配置文件信息 配置文件信息存放在数据库中

SpringCloud Config没有后台可管理分布式配置中心，配置文件信息存放在版本控制器里面（svn、get）

使用Zookeeper实现分布式配置中心，持久点+事件通知

4、SpringCloud Config分布式配置中心原理

5、分布式配置中心的核心组件？？？

5.1、web后台管理系统 ： 后台可以使用图像界面管理配置文件信息 SpringCloud没有

5.2、存放分布式配置文件服务器（持久储存服务器） --使用版本控制器存放配置文件信息

5.3、ConfigServer缓存配置文件服务器（临时缓存存放）

5.4、ConfigClient 读取ConfigService配置文件信息

6、搭建git环境 目的： 持久化储存配置文件信息 采用码云

6.1、git环境上文件夹以项目进行区分

member_config会员服务配置中心

order_config 订单服务配置中心

6.2、公司项目上的环境怎么区分？？？

        dev ---本地环境

         sit ---测试环境

         pre --预生产环境

        prd --生产环境

      uat --验收环境

七、网关

概念：相当于客户端请求统一先请求到网关服务器，再由网关服务器进行请求转发。类似于Nginx

作用：网关可以拦截客户端的所有请求，对该请求进行权限控制、负载均衡、日志管理、接口调用监控等。

1、网关API（接口） Getway（网关）

      接口网关注意：接口没有界面

2、接口在什么背景下产生的？

      在面向服务架构和微服务背景下产生的，目的是为了解耦，RPC远程调用中产生的。

3、接口如何分类？

外部接口：其他机构的合作伙伴进行调用（必须在外网访问），蚂蚁开放平台，微信公众号开发需要通过appid+appsocet生成accessToken进行通讯。对接支付开发、微信开发。目的可以授权一些接口权限OAuth协议方式 第三方联合登陆。

内部接口：一般只能在局域网内进行访问，服务于服务之间关系都在同一个微服务系统中。目的是为了安全性。

4、现在让你设计一套公司项目的接口，你会如何设计？？？

考虑

接口权限（开放接口|内部接口），考虑幂等性、安全性（https）防止篡改数据（验证签名）、使用网关拦截接口实现白名单黑名单、接口使用http+json格式 restful 目的是为了跨平台。

http底层使用socket，底层使用二进制进行数据交互，所以跨平台没问题。

考虑高并发 对接口服务实现保护 服务降级、熔断、隔离之类，最后使用同一API管理平台

（api swagger）；

5、网关跟过滤器的区别？？？

过滤器适合于单个tomcat服务器进行拦截请求。

网关是拦截整个微服务的所有请求。

6、Nginx与zuul的区别？？？

相同点： Nginx跟zuul都可以实现负载均衡、反向代理、过滤请求、实现网关效果。

不同点：（1）Nginx是用C语言写的

                          Zuul是用java语言写的

                 （2）Zuul负载均衡的实现：采用ribbon+eureka实现本地负载均衡

                           Nginx负载均衡实现：采用服务器端实现负载均衡

                 （3）Nginx比Zuul更加强大，引文Nginx可以整合一些脚本语言（Nginx+Lua）

                           Nginx适合于服务器端负载均衡，也可以实现网关

                            Zuul适合微服务中实现网关，而且使用java语言编写。

建议方案：

                   最好使用Nginx+zuul实现网关

                    Nginx作用 实现反向代理（隐藏服务器的真实地址）

                    Zuul对微服务实现网关代理