SpringCloud知识点学习总结
大家好！我是【程序员写荣】，希望接下来可以通过书写博客，使自己的程序员生涯欣欣向荣。这博客通过面试题的形式将各个知识点进行汇总，是对自己学习的一点点总结及记录。
什么是单体应用架构？
一个应用中包含了应用程序的所有功能（比如：页面、代码、配置等），把应用打成一个war或jar包部署到Tomcat中，通常称为单体应用架构。
单体应用架构的优点和缺点？
- 优点
- 易于开发和测试：单个应用包含所有功能，不涉及多个应用的互联互调，便于在团队之间开发与测试。只更新这个大的应用程序，其他的都不用考虑。
- 易于部署：只需将单个应用打成war或jar包，进行部署到Tomcat即可，运维起来比较方便
- 易于整体扩展：当应用负载压力大时，将这个应用复制几份，分别部署在不同的服务器上，在通过负载均衡即可提高应用的并发能力。
- 缺点
- 复杂性高：由于是单个应用，所以整个项目文件包含的模块非常多，导致模块的边界非常模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个bug都会带来隐藏的缺陷。
- 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
- 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员必须使用相同的开发语言、持久化存储及消息系统。
什么是微服务架构？
微服务是一种架构风格，是以开发一组小型服务的方式来作为一个独立的应用系统，每个服务都运行在自己的进程中，服务之间采用轻量级的HTTP通信机制（通常采用HTTP的RESTful API）进行通信。这些服务都是围绕具体业务进行构建的，并且可以独立部署到生产环境上。这些服务可以用不同的编程语言编写，并且可以使用不同的数据存储技术。对这些微服务我们只需要使用一个非常轻量级的集中式管理来进行协调。
微服务架构的优点和缺点？
- 优点
- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快
- 局部修改容易部署：单个应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
- 按需伸缩：可根据需求，实现细粒度的扩展。
- 缺点
- 运维要求高：更多的服务意味着要投入更多的运维
- 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
- 接口的调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
微服务架构总结
- 微服务的核心就是将传统的单一应用，根据业务拆分成一个一个的服务，彻底地去耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事。
- 在 IDEA 工具中使用 Maven 构建的一个个独立的 Model，也就是使用 Spring Boot 开发的一个个小模块就是一个个微服务，将专业的事交给专业的模块来做。比如一个大型项目可能有上百个微服务，讲这些微服务集中起来构成一个大的系统，对外暴露服务进行调用与使用。
- 从技术角度看就是一种小而独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
Spring Cloud 是什么？
Spring Cloud 是一组技术的集合。基于 Spring Boot 提供了一套微服务解决方案，包括服务注册与发现、配置中心、全链路监控、服务网关、负载均衡、熔断器等组件，除了基于 NetFlix 的开源组件做高度抽象封装之外，还有一些选型中立的开源组件。
官方：构建分布式系统不用特别的复杂且避免容易出现的错误。Spring Cloud为最常见的分布式系统模式提供了一个简单和可访问的编程模式，帮助开发人员构建弹性、可靠和协调的应用程序。Spring Cloud 构建在 Spring Boot 之上，使开发人员很容易开始工作并迅速提高生产力。
Spring Boot 快速构建一个个微服务，多个微服务之间如何互通互调呢？
- 使用 Spring Cloud 进行管理协调服务间正常互联互调，从而实现分布式微服务架构。
- 说明：
- Spring Cloud 使用 RESTful API 实现服务之间通信
- Dubbo 使用 RPC（远程过程调用）实现服务之间通信
- Spring Cloud 包含21项技术
Spring Boot 和 Spring Cloud 的关系？
- Spring Boot 可以离开 Spring Cloud 单独使用开发项目，但是 Spring Cloud 离不开 Spring Boot，属于依赖的关系。
- Spring Boot 专注于快速方便的开发单个个体微服务，Spring Cloud 关注全局的服务治理框架。
- Spring Cloud 是关注全局的微服务协调治理框架，它将 Spring Boot 开发的一个个单体服务整合并管理起来，为各个微服务之间提供、配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务。
Spring Cloud 和 Spring Boot 的版本依赖关系？
| Could代号 | Boot版本 |
|---|---|
| Greenwich | 2.1.x |
| Finchley | 2.0.x |
| Edgware | 1.5.x |
| Dalston | 1.5.x |
最稳定版本：Finchley SR2，搭配 Spring Boot 2.0.7
GA：General Availability，正式发布的版本，官方推荐使用本版本。在国外都是用GA来说明 RELEASE 版本的。
PRE：预览版，内部测试版。主要是给开发人员和测试人员找bug用的，不建议使用。
SNAPSHOT：快照版，可以稳定使用，且仍在继续改进版本。
RestTemplate 组件是什么？
RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端模板工具集，提供了多种便捷访问远程 HTTP 服务的方法，简化了与 HTTP 服务的通信，并满足 RestFul 原则，程序代码可以给它提供 URL，并提取结果，能够大大提高客户端的编写效率。
RestTemplate 和 HttpClient 的比较？
RestTemplate 和 HttpClient 都是处理 HTTP 客户端工具，其中RestTemolate内部内置消息转化器，在一定程度上减少代码开发，例如 MappingJackson2HttpMessageConverter 将 json 格式数据转换为具体对象，如果使用 HttpClient，还需要手动将 json 数据转换为具体对象。
系统会根据业务被拆分成很多的微服务，微服务的信息如何管理？
Spring Cloud 中提供服务注册中心来管理服务信息。
轮询算法：向 Eureka Server 发送心跳（默认周期是30秒）。服务端在多个心跳周期内没有接受到某个节点的心跳，服务端就会从服务注册中心吧这个服务节点删除（默认周期90秒）。
为什么要用注册中心？
微服务数量众多，要进行远程调用就需要知道服务端的 ip 地址和端口号，注册中心帮助我们管理这些服务的 ip 和端口。
微服务会实时上报自己的状态，注册中心统一管理这些微服务的状态，将存在问题的服务踢出服务列表，客户端获取到可用的服务进行调度。
Spring Cloud Eureka 是什么？
Spring Cloud Eureka 是对 Netflix 公司的 Eureka 的二次封装，它实现了服务治理的功能，Spring Cloud Eureka 提供 Eureka Server 服务端与 Eureka Client 客户端，服务端即是 Eureka 服务注册中心，客户端完成微服务向 Eureka 服务的注册与发现。
客户端同时具备一个内置的使用轮询负载算法的负载均衡器。在微服务启动后，将会向 Eureka Server 发送心跳（默认周期是30秒）。如果 Eureka Server 在多个心跳周期内没有接受到某个节点的心跳，Eureka Server 将会从服务注册表中吧这个服务节点移除（默认周期90秒）。
Eureka Server 自我保护机制是什么？
当 Eureka Server 在一定时间内（默认90秒）没有接受到某个微服务的心跳，Eureka Server 会从服务列表将此服务实例注销。但是如果出现网络异常情况（微服务本身是正常的），微服务与 Eureka Server 之间无法正常通信，以上行为可能变的非常危险了，因为微服务本身其实是正常的，此时本不应该注销这个微服务。
Eureka Server 有一种自我保护模式来解决这个问题。当 Eureka Server 在短时间内丢失过多客户端是（可能发生了网络故障），此时 Eureka Server 会进入自我保护模式，一旦进入该模式，Eureka Server 就会保护服务注册表的信息，不在删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该 Eureka Server 会自动退出自我保护模式。
所以，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有的微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让 Eureka 集群更加的健壮、稳定。
为什么搭建集群版 Eureka Server 服务注册中心？
为了避免 Eureka Server 的失效， Eureka Server 高可用环境需要部署两个及以上 Eureka Server，它们互相向对方注册。微服务需要连接两台 Eureka Server 服务注册中心，其中一台 Eureka 死掉也不会影响服务的注册与发现。
什么是服务端负载均衡？
服务端负载均衡是我们处理高并发、缓解网络压力和进行服务端扩容的重要手段之一，简单地说就是将用户的请求平摊的分配到多个服务商，从而实现系统的高可用性集群。服务端负载均衡服务器为为两种。一种是通过硬件实现的负载均衡服务器，简称硬负载例如：F5。一种是通过软件来实现的负载均衡，简称软负载例如：Apache 和 Nginx。应付在和软负载相比前者作用的网络层次比较多可以作用到 Socket 接口的数据链路层对发出的请求进行分组转发但是价格成本比较贵，而软负载作用的层次在 HTTP 协议层之上可以对 HTTP 请求进行分组转发并且因为是开源的所以几乎是0成本。
无论是硬件负载均衡还是软件负载均衡都会维护一份可用的服务端清单，然后通过心跳机制来删除故障的服务端节点以保证清单中都是可以正常访问的服务端节点，此时当客户端的请求到达负载均衡服务器时，负载均衡服务器按照某种配置好的规则（负载均衡算法有：轮询、随机、加权轮询、加权随机、地址哈希等方法）从可用服务端清单中选出一台服务器去处理客户端的请求。所以负载均衡可以为微服务集群分担请求，降低系统的压力。
什么是客户端负载均衡（Ribbon）？
Spring Cloud Ribbon 是基于 Netflix 公司发布的开源项目 Ribbon 进行封装的一套客户端负载均衡器。
Ribbon是一个基于HTTP和TCP的客户端负载均衡器，当我们将Ribbon和Eureka一起使用时，Ribbon会从Eureka注册中心去获取服务端列表，然后进行轮询访问以到达负载均衡的作用，客户端负载均衡中也需要心跳机制去维护服务端清单的有效性，当然这个过程需要配合服务注册中心一起完成。
客户端负载均衡和服务端负载均衡的区别？
客户端负载均衡和服务端负载均衡最大的区别是服务清单所存储的位置。在客户端负载均衡中，每个客户端服务都有一份自己要访问的服务端清单，这些清单统统都是从 Eureka 服务注册中心获取的。而在服务端负载均衡中，只要负载均衡器维护一份服务端列表。
什么是 Feign？
Feign 是 Netflix 公司开源的轻量级 Rest 客户端，使用 Feign 可以非常方便、简单的实现 HTTP 客户端。Spring Cloud 对 Feign 进行了封装， Feign 默认继承了 Ribbon 实现了客户端负载均衡调用。
微服务间有哪些调用方式？
- 通过微服务名称，获得服务的调用地址。
- 通过接口+注解，获得服务的调用
Feign 工作原理是什么？
Feign 通过接口的方法调用Rest服务，请求发送给 Eureka 服务器，通过 Feign 直接找到服务接口，因为继承了 Ribbon 技术，Feign 自带负载均衡配置功能。
- 启动类添加@EnableFeignClients注解，Spring会扫描标记了@FeignClient注解的接口，并生成此接口的代理对象。
- @FeignClient("服务名称 ") 即指定了 product 服务名称，Feign会从Eureka注册中心获取 product 服务列表， 并通过负载均衡算法进行服务调用。
- 在接口方法中使用注解 @RequestMapping(value = “/product/list”,method = RequestMethod.GET)，指定调用的url，Feign 会根据url进行远程调用。
Feign 注意事项？
SpringCloud对Feign进行了增强兼容了SpringMVC的注解 ，我们在使用SpringMVC的注解时需要注意：
- @FeignClient接口方法有基本类型参数在参数必须加@PathVariable(“XXX”) 或 @RequestParam(“XXX”)。
- @FeignClient接口方法返回值为复杂对象时，此类型必须有无参构造方法。
什么是 Hystrix？
Hystrix 是 Netflix 公司开源项目，实现了熔断器模型，Spring Cloud 对这一组件进行了整合。
为什么使用 Hystrix？
在微服务架构中，根据业务来拆分成一个个的服务，而服务于服务之间存在着依赖关系（比如用户调商品、商品调库存、库存调订单等等），在 Spring Cloud 中多个微服务之间可以用 RestTemplate + Ribbon 和 Fegin 来调用。
在服务之间调用的链路上由于网络原因、资源繁忙或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，导致响应时间过长或不可用，此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的后果，这就是服务故障的“雪崩”效应。为了解决这个问题，业界踢出了熔断器模型。
什么是服务熔断？
熔断机制是应对雪崩效应的一种微服务链路保护机制。在微服务中，衣蛾请求需要调用多个服务是非常常见的。
当服务之间调用的链路上某个微服务不可用或者响应时间太长时，会导致连锁故障。当失败的调用带一定阈值（缺省是5秒内20次调用失败）就会启动熔断机制。在 Spring Cloud 框架里熔断机制通过 Hystrix 实现，Hystrix 会监控微服务间调用的状况。熔断器打开后，可用避免连锁故障 fallback 方法可以直接返回一个固定值。
什么是服务监控？
除了隔离依赖服务的调用以外，Hystrix 还提供了准实时的调用监控（Hystrix Dashboard），Hystrix 会持续地记录所有通过 Hystrix 发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括美妙执行多少请求多少成功，多少失败等。
Netflflix 通过 hystrix-metrics-event-stream 项目实现了对以上指标的监控。Spring Cloud也提供了 Hystrix Dashboard 的整合，对监控内容转化成可视化界面。
什么是 Zuul？
Zuul 是 Netflix 公司开源项目，Zuul 包含了对请求路由和校检过滤两个最主要的功能：
- 其中路由功能负责将外部请求转发到具体的微服务实力上，是实现外部访问统一入口的基础。
- 而过滤功能则负责对请求的处理过程进行干预，是实现请求校验等功能的基础。
Zuul 和 Eureka 进行整合，将 Zuul 自身注册为 Eureka 服务治理中的服务，同时从 Eureka中获得其他微服务的消息，也即以后的访问微服务都是通过 Zuul 跳转后获得。注意：Zuul 服务最终还是会注册进 Eureka。
如何自定义 Zuul 过滤器？
自定义过滤器需要继承 ZuulFilter，ZuulFilter是一个抽象类，需要覆盖它的4个方法：
- filterType：返回字符串代表过滤器的类型，返回值有：
- pre：在请求路由之前执行 route：在请求路由时调用
- post：请求路由之后调用，也就是在 route 和 error 过滤器之后调用
- error：处理请求发生错误时调用
- filterOrder：此方法返回整形数值，通过此数值来定义过滤器的执行顺序，数字越小优先级越高。
- shouldFilter：返回 Boolean 值，判断该过滤器是否执行。返回 true 表示要执行此过滤器，false 不执行。
- run：过滤器的业务逻辑。
分布式架构的问题有哪些？
在分布式微服务架构中，由于服务数量很多，使得有很多配置文件，在更新配置文件时很麻烦。我们每个微服务自己带着一个 application.yml，上百个配置文件的管理起来就很麻烦，所以一套集中地、动态的配置管理功能是必不可少的，在 Spring Cloud 中，有分布式配置中心组件 Spring Cloud Config 来解决这个问题。
什么是 Spring Cloud Config ？
Spring Cloud Config 为微服务架构中的微服务提供集中式的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。
Spring Cloud Config 分为服务端与客户端两个部分：
服务端 config server：也称为分布式配置中心，它是一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息，加密、解密信息等访问接口。配置服务器官方推荐采用 Git 来存储配置信息，这样就有助于对环境配置进行版本管理，并且可通过 Git 客户端工具来方便的管理与访问配置信息。
客户端 config client：通过制定的服务端来管理服务的资源，以及与业务相关的配置内容，并在启动的时候从服务器端获取和加载配置信息。
使用 Spring Cloud Config 的作用？
- 集中管理配置文件。
- 不同环境不同配置，动态化的配置更新，根据不同环境部署，如 dev/test/prod。
- 运行期间动态调整配置，不需要再每个服务部署的机器上编写配置，服务辉会向配置中心统一拉取自己的配置信息。
- 当配置发生变动时，服务不需要重启即可感知到配置的变化并使用修改后的配置信息将配置信息以REST接口的方式暴露。
bootstrap.yml 是什么？
application.yml 是用户级别的配置项，bootstrap.xml 是系统级别的配置项，优先级更高
Spring Cloud 会创建一个 Bootstrap Context，Bootstrap Context 会负责从外部资源加载配置属性并解析配置；Bootstrap 属性有高优先级，默认情况下，它们不会被本地配置覆盖。
Spring Cloud Bus解决的问题？
当我们更新 Github 中的配置文件内容后，Config客户端服务是否会及时更新的配置内容呢？
如果希望在不重启微服务的情况下更新配置如何来实现呢？我们是用 Spring Cloud Bus 来实现配置的自动更新。
Spring Cloud Bus 的使用机制？
Spring Cloud Bus 被国内很多都翻译为消息总线，大家可以把它理解为管理和传播所有分布式项目中的消息即可，其实本质是利用了 MQ 的广播机制在分布式的系统中传播消息，目前常用的有 Kafka 和 RabbitMQ。利用 Bus 的机制可以做很多的事情，其中配置中心客户端刷新就是典型的应用场景之一。Spring Cloud Bus 做配置跟新的步骤：
- 提交配置后发送 POST 方式的 /bus-refresh 请求给 Config 客户端。
- Config 客户端接收到请求从 Server 端更新配置并且发送消息给消息总线。
- 消息总线街道消息并通知给其他客户端。
- 其他客户端接收到通知，请求 Server 端获取最新配置。
- 全部客户端均获取到最新的配置。
什么是 Postman？
Postman 是款强大网页调试的 windows 客户端工具，提供功能强大的 Web API & HTTP 请求调试。软件功能非常强大，界面简洁明晰、操作方便快捷，设计得很人性化。Postman 中文版能够发送任何类型的 HTTP 请求（GET、DELETE、POST、PUT…），附带任何数量的请求参数。
非常感谢您的阅读！如果文章有书写错误或不清楚的地方，希望您评论指出，我将第一时间改正。如果您喜欢这篇文章的话，请你点赞和评论，如果您还能点击收藏，那就是对我最大的鼓励！