一、 简述

微服务架构就是将单体的应用程序分成多个应用程序，每个应用程序就称为微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信。这些服务围绕业务能力来划分，并通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言，不同数据库，以保证最低限度的集中式管理。

SpringCloud 是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以做到一键启动和部署。

SpringCloud 并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过 SpringBoot 风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。SpringCloud 完成这些只需要一个 jar 的依赖就可以了，所谓的开箱即用。而 dubbo+zookeeper 下载配置起来却颇为复杂。

SpringCloud 大多数子模块都是直击痛点，像 zuul 解决的跨域，fegin 解决的负载均衡，hystrix 的熔断机制等等。

二、SpringCloud 的优缺点

1️⃣优点：

1. 耦合度比较低。不会影响其他模块的开发。
2. 减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发。
3. 配置比较简单，基本用注解就能实现，不用使用过多的配置文件。
4. 微服务跨平台的，可以用任何一种语言开发。
5. 每个微服务可以有自己的独立的数据库也有用公共的数据库。
6. 直接写后端的代码，不用关注前端怎么开发，直接写自己的后端代码即可，然后暴露接口，通过组件进行服务通信。

2️⃣缺点：

1. 部署比较麻烦，给运维工程师带来一定的麻烦。
2. 针对数据的管理比麻烦，因为每个微服务可以使用一个数据库。
3. 系统集成测试比较麻烦
4. 性能的监控比较麻烦。【最好开发一个大屏监控系统】

三、SpringBoot 和 SpringCloud 的区别

1. SpringBoot 专注于快速方便的开发单个个体微服务。
2. SpringCloud 关注全局的微服务治理框架，它将 SpringBoot 开发的单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。
3. SpringBoot 可以离开 SpringCloud 独立使用开发项目， 但是 SpringCloud 离不开 SpringBoot ，属于依赖的关系。

四、dubbo和 SpringCloud 的区别

五、SpringCloud 的核心组件

1. 【服务注册与发现 Eureka】各个服务启动时，Eureka Client 都会将服务注册到 Eureka Server，并且 Eureka Client 还可以反过来从 Eureka Server 拉取注册表，从⽽知道其他服务在哪⾥。

2. 【客户端负载均衡 Ribbon】服务间发起请求的时候，基于 Ribbon 做负载均衡，从⼀个服务的多台机器中选择⼀台。

3. 【声明性的Web服务客户端 Feign】基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起请求。

4. 【断路器 Hystrix】发起请求是通过 Hystrix 的线程池来⾛的，不同的服务⾛不同的线程池，实现了不同服务调⽤的隔离，避免了服务雪崩的问题。

5. 【服务网关 Zuul】如果前端、移动端要调⽤后端系统，统⼀从 Zuul ⽹关进⼊，由 Zuul ⽹关转发请求给对应的服务。

6. 【分布式统一配置管理 Confifig】

六、使用 SpringBoot 开发微服务面临的问题

1. 与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
2. 服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。
3. 冗余-分布式系统中的冗余问题。
4. 负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。
5. 性能-问题 由于各种运营开销导致的性能问题。

七、服务注册和发现：Eureka

当开始一个项目时，通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

Eureka 是 SpringCloud 的服务注册中心，系统中的其他服务通过 Eureka 的客户端连接到 EurekaService 中，并且保持心跳。可以通过 EurekaService 来监控各个微服务是否运行正常。

默认情况，如果 EurekaService 在一定时间内没有接收到某个微服务的心跳，会进入自我保护模式，在该模式下 EurekaService 会保护服务注册表中的信息，不再删除注册表中的数据，当网络故障恢复后，Eureka Servic 节点会自动退出自我保护模式。

Eureka 高可用实现：集群，注册多台 Eureka，然后把 SpringCloud 服务互相注册。客户端从 Eureka 获取信息时，按照 Eureka 的顺序来访问。

八、Eureka 和ZooKeeper的区别

九、Spring Cloud Zuul(服务网关)

网关相当于一个网络服务架构的入口，所有网络请求必须通过网关转发到具体的服务。网关的作用：统一管理微服务请求，权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等。常用的网关框架：Nginx、Zuul、Gateway。

Zuul 是对 SpringCloud 提供的成熟的路由方案，根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口，对外隐蔽了微服务的真正接口地址。它可以和Eureka、Ribbon、Hystrix等组件配合使用。应用场景：对外暴露，权限校验，服务聚合，日志审计等。三个重要概念：动态路由表，路由定位，反向代理：

• 动态路电表：Zuul 支持 Eureka 路由，手动配置路由，这俩种都支持自动更新。
• 路由定位：根据请求路径，Zuul 有自己的一套定位服务规则以及路由表达式匹配。
• 反向代理：客户端请求到路由网关，网关受理之后，在对目标发送请求，拿到响应之后在给客户端。

网关与过滤器的区别：网关是对所有服务的请求进行分析过滤，过滤器是对单个服务而言。

十、Zuul 与 Nginx 的区别

Zuul 是 Java 实现的，主要为 Java 服务提供网关服务，尤其在微服务架构中可以更加灵活的对网关进行操作。Nginx 是使用C语言实现，性能高于 Zuul，但是实现自定义操作需要熟悉 lua 语言，对程序员要求较高，可以使用 Nginx 做 Zuul 集群。

十一、如何设计一套API接口

考虑到API接口的分类可以将API接口分为开发API接口和内网API接口，内网API接口用于局域网，为内部服务器提供服务。开放API接口用于对外部合作单位提供接口调用，需要遵循Oauth2.0权限认证协议。同时还需要考虑安全性、幂等性等问题。

十二、ZuulFilter 常用方法

1. Run()：过滤器的具体业务逻辑
2. shouldFilter()：判断过滤器是否有效
3. fifilterOrder()：过滤器执行顺序
4. fifilterType()：过滤器拦截位置

十三、如何实现动态 Zuul 网关路由转发

通过 path 配置拦截请求，通过 ServiceId 到配置中心获取转发的服务列表，Zuul 内部使用 Ribbon 实现本地负载均衡和转发。

十四、Zuul 网关如何搭建集群

使用 Nginx 的 upstream 设置 Zuul 服务集群，通过 location 拦截请求并转发到 upstream，默认使用轮询机制对 Zuul 集群发送请求。

十五、负载平衡的意义

十六、负载均衡：Ribbon

Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法。Ribbon 客户端组件提供一系列完善的配置项，如连接超时，重试等。简单的说，就是在配置文件中列出后面所有的机器，Ribbon 会自动的帮助你基于某种规则(如简单轮询，随即连接等)去连接这些机器。开发者很容易使用 Ribbon 实现自定义的负载均衡算法。(有点类似Nginx)

Ribbon 底层实现原理：Ribbon 使用 discoveryClient 从注册中心根据服务别名读取目标服务信息，对同一接口请求进行计数，使用%取余算法获取目标服务集群索引，返回获取到的目标服务信息。

@LoadBalanced 注解的作用：开启客户端负载均衡。

十七、Nginx 与 Ribbon 的区别

Nginx 是反向代理同时可以实现负载均衡，nginx 拦截客户端请求采用负载均衡策略根据 upstream 配置进行转发，相当于请求通过 nginx 服务器进行转发。

Ribbon 是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端操作。

十八、什么是断路器

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应。当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应(雪崩效应)。断路器有三种状态：

1. 【打开状态】一段时间内达到一定的次数无法调用并且多次监测没有恢复的迹象，断路器完全打开，那么下次请求就不会请求到该服务。
2. 【半开状态】短时间内有恢复迹象，断路器会将部分请求发给该服务，正常调用时断路器关闭。
3. 【关闭状态】当服务一直处于正常状态，能正常调用。

十九、雪崩效应的产生、影响及预防

1️⃣服务雪崩效应产生的原因
因为 tomcat 默认只有一个线程池来维护客户端发送的所有的请求，此时某一接口在某一时刻被大量访问就会占据 tomcat 线程池中的所有线程，其他请求处于等待状态，无法连接到服务接口。

2️⃣谈谈服务雪崩效应

大型互联网项目中，某服务发生宕机，调用该服务的其他服务也会发生宕机，大型项目的微服务之间的调用是互通的，这样就会将服务的不可用逐步扩大到各个其他服务中，从而使整个项目的服务宕机崩溃，发生雪崩效应的原因有以下几点：

1. 单个服务的代码存在bug。
2. 请求访问量激增导致服务发生崩溃(如大型商城的枪红包，秒杀功能)。
3. 服务器的硬件故障也会导致部分服务不可用。

3️⃣防雪崩利器：Hystrix

分布式系统，一定会依赖各种服务，那么这些个服务一定会出现失败的情况，就会导致雪崩。Hystrix 它具有服务降级，服务熔断，服务隔离，监控等一些防止雪崩的技术。Hystrix 有四种防雪崩方式：

1. 【服务降级】接口调用失败就调用本地的方法返回一个空。
2. 【服务熔断】接口调用失败就会进入调用接口提前定义好的一个熔断的方法，返回错误信息。
3. 【服务隔离】隔离服务之间相互影响
4. 【服务监控】在服务发生调用时会将每秒请求数、成功请求数等运行指标记录下来。

二十、在微服务中，如何保护服务

一般使用 Hystrix，实现服务隔离来避免出现服务的雪崩效应，从而达到保护服务的效果。当微服务中，高并发的数据库访问量导致服务线程阻塞，使单个服务宕机，服务的不可用会蔓延到其他服务，引起整体服务灾难性后果，使用服务降级能有效为不同的服务分配资源，一旦服务不可用则返回友好提示，不占用其他服务资源，从而避免单个服务崩溃引发整体服务的不可用。

二十一、谈谈服务降级、熔断、服务隔离

1. 【服务降级】当客户端请求服务器端的时候，防止客户端一直等待，不会处理业务逻辑代码，直接返回一个友好的提示给客户端。
2. 【服务熔断】是在服务降级的基础上更直接的一种保护方式，当在一个统计时间范围内的请求失败数量达到设定值(requestVolumeThreshold)或当前的请求错误率达到设定的错误率阈值(errorThresholdPercentage)时开启断路，之后的请求直接走fallback方法，在设定时间(sleepWindowlnMilliseconds)后尝试恢复。
3. 【服务隔离】就是 Hystrix 为隔离的服务开启一个独立的线程池，这样在高并发的情况下不会影响其他服务。服务隔离有线程池和信号量两种实现方式，一般使用线程池方式。

二十二、服务降级底层实现

Hystrix 实现服务降级的功能是通过重写 Hystrix Command 中的getFallback()，当 Hystrix 的 run 方法或 construct 执行发生错误时转而执行 getFallback()。