从spring到SpringBoot再到SpringCloud，现在“面试造火箭、入职拧螺丝”从微服务的发展史上就可以展现得淋漓尽致，除了像阿里那种大型互联网公司外，很少会用到SpringCloud，但是你又不得不去学习，因为你出去面试会发现，面试必问！

这不，最近阿里内部首发一套SpringCloud笔记（共四份）涵盖了SpringCloud的全部技术内容，同时也包含了面试热点（不知道是不是阿里有意为之......）总而言之，从各个维度来讲，这都是一份不可多的笔记！

下面就为大家免费分享出来这份笔记，受限于文章篇幅的原因，小编只能为大家展示部分的内容，完整PDF全彩版的免费获取方式放在了文末！

下面进入正题！

DAY1：微服务基础知识

SpringCloud概述

案例搭建

使用微服务架构的分布式系统微服务之间通过网络通信。我们通过服务提供者与服务消费者来描述微服务间的调用关系。

服务提供者:服务的被调用方,提供调用接口的一方

服务消费者:服务的调用方,依赖于其他服务的一方

我们以电商系统中常见的用户下单为例,用户向订单微服务发起一个购买的请求。在进行保存订单之前需要调用商品微服务查询当前商品库存,单价等信息。在这种场景下,订单微服务就是一个服务消费者,商品微服务就是一个服务提供者。

服务注册Eureka基础

服务注册Eurek高级

Eureka替换方案Consul

服务调用Ribbon入门

经过以上的学习,已经实现了服务的注册和服务发现。当启动某个服务的时候,可以通过HTTP的形式将信息注册到注册中心,并且可以通过SpringCloud提供的工具获取注册中心的服务列表。但是服务之间的调用还存在很多的问题,如何更加方便的调用微服务,多个微服务的提供者如何选择,如何负载均衡等。

服务调用Ribbon高级

DAY2：服务调用Feign、服务注册与发现总结、微服务架构的高并发问题

通过注册中心已经实现了微服务的服务注册和服务发现,并且通过Ribbon实现了负载均衡,已经借助Feign可以优雅的进行微服务调用。那么我们编写的微服务的性能怎么样呢,是否存在问题呢?

服务熔断Hystrix以及替换方案

18年底Ntflix官方宣布Hystrix已经足够稳定,不再积极开发Hystrix , 该项目将处于维护模式。就目前来看Hystrix是比较稳定的,并且Hystrix只是停止开发新的版本,并不是完全停止维护, Bug什么的依然会维护的。因此短期内, Hystrix依然是继续使用的。但从长远来看, Hystrix总会达到它的生命周期,那么Spring Cloud生态中是否有替代产品呢?

DAY3：微服务网关概述

在学习完前面的知识后,微服务架构已经初具雏形。但还有一些问题 :不同的微服务-般会有不同的网络地址,客户端在访问这些微服务时必须记住几十甚至几百个地址,这对于客户端方来说太复杂也难以维护。如下图：

微服务网关Zuul

微服务网关GateWay

Zuul 1.x是一个基于阻塞I0的API Gateway以及Servlet;直到2018年5月, Zuul2.x(基于Netty ,也是非阻塞的,支持长连接)才发布,但Spring Cloud暂时还没有整合计划。Spring CloudGateway比Zuul 1.x系列的性能和功能整体要好。

微服务的链路追踪概述

在实际的企业开发中,消息中间件是至关重要的组件之-。消息中间件主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终-致性架构。不同的中间件其实现方式，内部结构是不一样的。如常见的RabbitMQ和Kafka,由于这两个消息中间件的架构上的不同,像RabbitMQ有exchange , kafka有Topic , partitions分区,这些中间件的差异性导致我们实际项目开发给我们造成了一定的困扰,我们如果用了两个消息队列的其中一种,后面的业务需求,我想往另外- -种消息队列进行迁移,这时候无疑就是一个灾难性的, 一大堆东西都要重新推倒重新做,因为它跟我们的系统耦合了,这时候springc loud stream给我们提供了一种解耦合的方式。