最后我们该如何学习？
1、看视频进行系统学习
这几年的Crud经历，让我明白自己真的算是菜鸡中的战斗机，也正因为Crud，导致自己技术比较零散，也不够深入不够系统，所以重新进行学习是很有必要的。我差的是系统知识，差的结构框架和思路，所以通过视频来学习，效果更好，也更全面。关于视频学习，个人可以推荐去B站进行学习，B站上有很多学习视频，唯一的缺点就是免费的容易过时。
另外，我自己也珍藏了好几套视频资料躺在网盘里，有需要的我也可以分享给你：
2、读源码，看实战笔记，学习大神思路
“编程语言是程序员的表达的方式，而架构是程序员对世界的认知”。所以，程序员要想快速认知并学习架构，读源码是必不可少的。阅读源码，是解决问题 + 理解事物，更重要的：看到源码背后的想法；程序员说：读万行源码，行万种实践。
Spring源码深度解析：
Mybatis 3源码深度解析：
Redis学习笔记：
Spring Boot核心技术-笔记：
3、面试前夕，刷题冲刺
面试的前一周时间内，就可以开始刷题冲刺了。请记住，刷题的时候，技术的优先，算法的看些基本的，比如排序等即可，而智力题，除非是校招，否则一般不怎么会问。
关于面试刷题，我个人也准备了一套系统的面试题，帮助你举一反三：
只有技术过硬，在哪儿都不愁就业，“万般带不去，唯有业随身”学习本来就不是在课堂那几年说了算，而是在人生的旅途中不间断的事情。
人生短暂，别稀里糊涂的活一辈子，不要将就。
Spring Cloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册为Eureka服务治理下的应用，同时从Eureka中获得了所有其他微服务的实例信息
对于路由规则的维护，Zuul默认会将通过以服务名作为ContextPath的方式来创建路由映射
Zuul提供了一套过滤器机制，可以支持在API网关无附上进行统一调用来对微服务接口做前置过滤，已实现对微服务接口的拦截和校验
3. Ribbon（负载均衡）
================
提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
Ribbon是一个基于HTTP和TCP的客户端负载均衡器，它可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到服务均衡的作用。
当Ribbon和Eureka联合使用时，Ribbon的服务实例清单RibbonServerList会被
DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。同时它也会用NIWSDiscoveryPing来取代IPing，它将职责委托给Eureka来去定服务端是否已经启动
在客户端负载均衡中，所有客户端节点都维护着自己要访问的服务端清单，而这些服务端的清单来自于服务注册中心（比如Eureka）。在客户端负载均衡中也需要心跳去维护服务端清单的健康性，只是这个步骤需要与服务注册中心配合完成。
通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用只需要如下两步：
-
服务提供者只需要启动多个服务实例并且注册到一个注册中心或是多个相关联的服务注册中心
-
服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用
4. Hystrix（熔断保护器）
==================
熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
提供线程池不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务器雪崩的问题。
在微服务架构中，存在着那么多的服务单元，若一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统架构更加不稳定。为了解决这样的问题，产生了断路器等一系列的服务保护机制
在分布式架构中，当某个服务单元发生故障之后，通过断路器的故障监控，向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延
Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等强大功能
Hystrix使用舱壁模式实现线程池的隔离，它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的依赖服务
5. Feign（REST转换器）
==================
基于动态代理机制，根据注解和选择的机器，拼接请求url地址，发起请求。Feign的关键机制是使用了动态代理
-
首先，对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
-
接着调用接口的时候，本质就是调用Feign创建的动态代理
-
Feign的动态代理会根据在接口上的@RequestMapping等注解，来动态构造要请求的服务的地址
-
针对这个地址，发起请求、解析响应
Feign是和Ribbon以及Eureka紧密协作的
-
首先Ribbon会从Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口
-
然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
-
Feign就会针对这台机器，构造并发起请求
6. Config（分布式配置）
=================
配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。
注册中心与API网关的分析
=============
微服务网关更多是在前后端分离，或者说涉及到独立的类似手机APP等前端应用的时候使用的最多，即把内部各个微服务组件模块的API接口能力统一注册和接入到网关，对于APP也只需要访问网关暴露的接口即可，同时通过网关还可以进一步的实现安全隔离。
也就是说在这种场景下，网关更多的是实现了接口服务的代理和路由转发能力，更多的是向外的一种能力发布。
-
一个独立的开发团队，为保证独立自治，以及内部多个微服务模块间的交互集成，最好启用独立的服务注册中心实现服务注册，发现能力。即开发团队内部多个微服务模块间的集成，不需要通过网关，只需要通过服务注册中心进行集成即可。
-
开发团队需要暴露能力给外部，包括暴露能力给其它的开发团队，需要考虑将该API接口注册到外部的网关上。在这里建议是拆分两个独立网关，一个是内部API网关，一个是放置到DMZ区面对公网访问的API网关。对于服务如果同时涉及到内部和外部使用，则两边注册。建议不要通过两次网关去路由，一个是影响性能，一个是不方便后续问题排查。
-
构建在开发团队之外的API网关必须具备负载均衡能力，可以配置多个IP地址。通过该API网关也最好具备和Docker容器扩展后的服务自动注册和地址加入扩展能力。
Eureka 的竞品分析：Nacos、ZooKeeper、Etcd
=================================
服务发现是一个古老的话题，当应用开始脱离单机运行和访问时，服务发现就诞生了。目前的网络架构是每个主机都有一个独立的IP地址，那么服务发现基本上都是通过某种方式获取到服务所部署的IP地址。DNS协议是最早将一个网络名称翻译为网络IP的协议，在最初的架构选型中，DNS+LVS+Nginx基本可以满足所有的RESTful服务的发现，此时服务的IP列表通常配置在Nginx或者LVS。后来出现了RPC服务，服务的上下线更加频繁，人们开始寻求一种能够支持动态上下线并且推送IP列表变化的注册中心产品。
Eureka
======
-
Spring Cloud Eureka所选择的是AP，采用的是去中心化结构，放弃了强一致性。也就是说Eureka集群中的各个结点都是平等的，没有主从的概念。通过互相注册的方式来进行消息同步和保证高可用。并且一个Eureka Server结点挂掉了，还有其他同等的结点来提供服务，并不会引发服务的中断
-
Eureka只能当注册中心，想搞配置中心的话，还得搭配Spring Cloud Config+Spring Cloud Bus。其中后者支持Rabbiimq和Kafka两种模式。
-
使用Java语言来开发的，并且也是Spring Cloud的子项目，所以可以直接通过引入jar包的方式来集成Eureka，这点非常方便
1. ZooKeeper
=============
这是一款经典的服务注册中心产品（虽然它最初的定位并不在于此），在很长一段时间里，它是国人在提起RPC服务注册中心时心里想到的唯一选择，这很大程度上与Dubbo在中国的普及程度有关。
-
Apache Zookeeper所选择的是CP，也就是放弃了高可用性。Zookeeper集群在进行消息同步的时候，必须有一半以上结点完成了同步才会返回；而当Master结点挂了或者集群中有过半的结点不能工作了，此时就会触发故障恢复，重新进行Master选举。在这个过程中，整个Zookeeper集群无法对外提供服务，从而实去了A（可用性）
-
为了达到C，Zookeeper采用的是自己的ZAB协议。
2. Nacos
=========
Nacos是阿里巴巴旗下的开源项目，在2018年开源，携带着阿里巴巴大规模服务生产经验，试图在服务注册和配置管理这个市场上，提供给用户一个新的选择。
-
Nacos一大特性是即支持CP，也支持AP。可以根据需要灵活选择。
-
Nacos除了注册中心之外，也能充当配置中心的作用。且配置中心可以按照namespace，group等维度来进行数据隔离，来达到不同环境之间配置隔离的功能。
值得一提的是，Nacos作为配置中心的持久化机制可以依赖于Mysql来完成（默认依赖于内置数据库）。只需要将Nacos目录下的sql脚本放到mysql中执行（会生成11个表），然后在nacos配置文件里面配一下mysql的账号密码即可。这样使用mysql作为数据源的方式相比于nacos内置数据库来说更容易管理
3. Consul
==========
Consul是HashiCorp公司推出的一个开源工具。
-
Consul是用Go语言编写的，所以无法像Eureka那样直接引入jar包就能集成，它还需要去服务器中进行额外的安装。
-
除了注册中心的功能之外，Consul还能起到配置中心的作用。
Consul它保证的是CP，使用raft协议，要求必须有过半的结点都写入成功才算是注册成功了，并且它也有Master和Follower的概念，在Master挂掉后，也需要自己内部进行
4. Etcd（待续）
============
对比SpringCloud，Kubernetes也提供完整的分布式微服务管理框架，几乎所有组件都有对应的产品，其中Etcd也可以提供类似Eureka的注册中心。
在 Go 生态中，还可以选择基于 Etcd 作为注册中心，Etcd 是由 CoreOS 团队维护的、高可用分布式键值存储数据库，可用于为集群提供配置和服务发现功能，Google 开源的容器管理工具 Kuberbetes 就是基于 Etcd 的。
和 Consul 一样，Etcd 也是基于 Raft 协议作为分布式一致性算法来解决领导者选举和日志复制问题，同样也是基于 Go 语言编写。
Etcd 也支持代理模式（proxy），只不过在 Etcd 中，代理模式和 Consul 的客户端代理模式类似，安装在部署服务的节点上，用来转发请求到 Etcd 集群，本身不存储任何数据，Etcd 集群相当于 Consul 中以服务端模式运行的 Consul 集群，通常要求配置三个及以上节点（不要太多，3~5就够了，以便可用性和性能上达到平衡），负责真正的请求处理 —— 服务注册与发现。
在目前最新版本的 Etcd v3中，通过网关模式（gateway）取代了 V2 版本中的代理模式（proxy）。
从服务发现的实现原理上来说，Consul 和 Etcd 的基本设计思路是一致的，Etcd 更简单，Consul 则更像一个全栈的解决方案，功能比 Etcd 要更丰富，比如支持可视化的 Web UI 管理界面、支持多数据库中心、安全层面除了 HTTPS 外还支持 ACL、更加全面的健康检查功能、内置 DNS Server 等，这些都是 Etcd 所不具备的，但是更全面的功能往往意味着更高的复杂性，针对微服务的服务注册和发现场景，Etcd 完全够用了。
Spring Cloud 全家桶的简介
===================
-
Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。
-
Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
-
Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。
-
Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
-
Zuul：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。
-
Archaius：配置管理 API，包含一系列配置管理 API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
-
Consul：封装了 Consul 操作，Consul 是一个服务发现与配置工具，与 Docker 容器可以无缝集成。
-
Spring Cloud for Cloud Foundry：通过 Oauth2 协议绑定服务到 CloudFoundry，CloudFoundry 是 VMware 推出的开源 PaaS 云平台。
-
Spring Cloud Sleuth：日志收集工具包，封装了 Dapper 和 log-based 追踪以及 Zipkin 和 HTrace 操作，为 Spring Cloud 应用实现了一种分布式追踪解决方案。
-
Spring Cloud Data Flow：大数据操作工具，作为 Spring XD 的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。
-
Spring Cloud Security：基于 Spring Security 的安全工具包，为你的应用程序添加安全控制。
-
Spring Cloud Zookeeper：操作 Zookeeper 的工具包，用于使用 Zookeeper 方式的服务发现和配置管理。
-
Spring Cloud Stream：数据流操作开发包，封装了与 Redis、Rabbit、Kafka 等发送接收消息。
-
Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
-
Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。
-
Turbine：Turbine 是聚合服务器发送事件流数据的一个工具，用来监控集群下 Hystrix 的 Metrics 情况。
-
Feign：Feign 是一种声明式、模板化的 HTTP 客户端。
-
Spring Cloud Task：提供云端计划任务管理、任务调度。
-
Spring Cloud Connectors：便于云端应用程序在各种 PaaS 平台连接到后端，如：数据库和消息代理服务。
-
Spring Cloud Cluster：提供 Leadership 选举，如：Zookeeper，Redis，Hazelcast，Consul 等常见状态模式的抽象和实现。
-
Spring Cloud Starters：Spring Boot 式的启动项目，为 Spring Cloud 提供开箱即用的依赖管理。
本书适合具有一定Java基础和Spring MVC基础的人群以及希望往架构师方向发展的开发者阅读。
书籍教程结构
======
本书共分四部分，从基础到实战，讲解了基于Spring Cloud的常用组件。
第一部分(基础篇):第1~4章
第二部分(实战篇):第5~10章
第三部分(高级篇):第11~13章
第四部分(部署篇):第14~15章
第一部分(基础篇)
=========
第1章微服务概述
我们要学习微服务架构，就要了解它，本章将带领大家初步了解微服务，为后面系统学习微服务架构奠定良好的基础。
第2章Spring Boot基础
本书以实战为导向，讲解了如何使用Spring Cloud开发微服务项目，而Spring Cloud基于SpringBoot,所以本章先来初步了解如何使用Spring Boot搭建框架。
第3章Spring Boot核心原理
通过第2章的学习，读者应该对Spring Boot有了一个大致的认识，利用Spring Boot可以极大地简化应用程序的开发，这都归功于Spring Boot的四大核心原理:起步依赖、自动配置、Actuator 和Spring Boot命令行。本章中，我们将深入探讨Spring Boot的核心原理，以便读者能更好地学习和使用Spring Boot。
第4章Spring Cloud概述
从本章开始，我们将正式踏上探索Spring Cloud秘密的旅程。学完本书后，读者将学会搭建一个完整的分布式架构，从而向架构师的目标靠近。
第二部分(实战篇)
=========
SpringCloud实战演练文档K8S+实战+笔记+项目教程转发+评论，关注我私信回复"笔记"即可免费获取
第5章 项目准备阶段
本章中，我 将开始 个大型实战项目一一博客网站。通过“以战代练”的方式来学习如何构建Spring loud 微服务架构，让读者走出理论的丛林，在实践中玩转微服务架构。
第6章 公共模块封装
最后
最后，强调几点：
- 1. 一定要谨慎对待写在简历上的东西，一定要对简历上的东西非常熟悉。因为一般情况下，面试官都是会根据你的简历来问的； 能有一个上得了台面的项目也非常重要，这很可能是面试官会大量发问的地方，所以在面试之前好好回顾一下自己所做的项目；
- 2. 和面试官聊基础知识比如设计模式的使用、多线程的使用等等，可以结合具体的项目场景或者是自己在平时是如何使用的；
- 3. 注意自己开源的Github项目，面试官可能会挖你的Github项目提问；
我个人觉得面试也像是一场全新的征程，失败和胜利都是平常之事。所以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！
以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。
面试答案
- 3. 注意自己开源的Github项目，面试官可能会挖你的Github项目提问；
我个人觉得面试也像是一场全新的征程，失败和胜利都是平常之事。所以，劝各位不要因为面试失败而灰心、丧失斗志。也不要因为面试通过而沾沾自喜，等待你的将是更美好的未来，继续加油！
以上面试专题的答小编案整理成面试文档了，文档里有答案详解，以及其他一些大厂面试题目。
面试答案
[外链图片转存中…(img-gmkjMM9H-1715775263295)]
[外链图片转存中…(img-yQMDu5UZ-1715775263296)]
[外链图片转存中…(img-Cw9AkTry-1715775263296)]
扫一扫
2202
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
