Spring Cloud快速了解并入门

学习SpringCloud前提要景:

1.JavaSE ->掌握
2. 数据库 ->掌握
3. 前端 ->熟练
4. Servlet ->掌握
5. Http ->了解
6. MyBatis *(重点)
7. Spring
8. SpringMVC
9. SpringBoot ->熟练使用springboot进行开发
10. 分布式基础,Dubbo,Zookeeper ->了解即可
11. Maven,Git ->掌握
12. Ajax,Json ->熟悉

---

提示：

---

该如何学习

微服务架构的4个问题
	1. 服务很多,客户端如何访问
	2. 这么多服务,服务之间是如何通信
	3. 这么多服务,如何治理
	4. 服务挂了怎么办

解决方案:
SpringCloud不是一个技术,是一种生态,具有天然解决以上4个问题,
SpringCloud是基于SpringBoot的
	
	1. Spring Cloud  NetFilx 一站式解决方案!
		1. api网关:zuul组件
		2. Feigin --HttpClient    -- HTTP通信方式,同步,阻塞
		3. 服务注册与发现: Euraka
		4. 熔断机制:Hystrix
	
	2. Apache Dubbo zookeeper   半自动,需要整合别人的!
		1. ApI:没有,找第三方组件
		2. 通信方式:Dubbo
		3. 服务注册与发现:Zookeeper
		4. 熔断没有,借助Hystrix
		Dubbo这一套方案并不完善

 	3. Spring Cloud Alibaba 最新的一站式解决方案!更简单
 		1. 注册中心:Nacos
 		2. 熔断:Sentinel
 		3. 网关:GetWay

新概念: 服务网格~Server Mesh	

常见面试题

1. 什么是微服务
2. 微服务之间是如何进行通讯的
3. SpringCloud和Dubbo的区别
4. SpringBoot和SpringCloud,请谈谈你对它们的理解
5. 什么是服务熔断?什么是服务降级?
6. 微服务的优缺点是什么?请说出你在项目中遇到的坑
7. 你所知道的微服务技术栈有哪些?请列举一二
8. eurka和zookeeper都可以提供服务注册与发现,请说说区别!

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、什么是微服务？

微服务最近几年流行起来的一种架构思想,关于它还是很难一言以蔽之,还是要看看Martin Fowle的一篇论文(点击蓝色字体自动跳转)

• 用技术的维度来理解:
  • 微服务的核心就是将传统的一站式应用,根据业务拆封成一个个的服务,彻底的去耦合,每一个微服务提供的单个业务功能的服务,一个服务做一件事情,从技术的维度看就是一种小而独立的处理过程,类似进程的概念,能够自行独立启动或销毁,拥有自己独立的数据库

二、微服务与微服务架构

1.微服务

• 微服务强调的是大小,它关注的是某一个点,是具体解决某一个问题/提供落地对应服务的一个服务应用,狭义的看,它就是IDEA中的一个个微服务工程,或者Moudle

2. 微服务架构

• 微服务架构是一种架构模式,它提倡将单一应用划分为一组小的服务,服务之间互相协调,互相配合,为用户提供最终价值,每个服务运行其独立的进程中,服务于服务间采用轻量级的通信机制相互协作,每个服务都围绕着具体的业务进行构建,并且能够独立的部署到生产环境中,另外,应采用避免统一的,集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择何时的语言,工具对其进行构建

三、微服务的优缺点

优点

1. 单一职责
2. 每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个指定的业务功能或也无需求
3. 开发简单,开发效率高,一个服务可能就是专一的只干一件事
4. 微服务能够被小团队单独开发,这个小团队一般2~5人
5. 微服务是松耦合的,是用功能意义的服务,无论是在开发阶段或者部署阶段都是独立的
6. 微服务能会用不同语言开发
7. 易于第三方集成,微服务允许容易且灵活的方式继承并且自动部署,通过持续集成工具,如HubSon,Jenkins
8. 微服务易于被一个开发人员理解,修改和维护,这样小的团队能够更关注自己的工作成果,无需通过合作才能体现价值
9. 微服务允许你利用融合最新技术
10. 微服务只是业务逻辑代码,不会和HTML,CSS或者其他界面混合
11. 每个微服务都有自己的存储能力,可以有自己的数据库,也可以有统一的数据库

缺点

12. 开发人员要处理分布式系统的复杂性
13. 多服务运维难度,随着服务的增大,运维的压力也在增大
14. 系统部署依赖
15. 服务间通信成本
16. 数据一致性
17. 系统集成测试
18. 性能监控

四、微服务的技术栈

• 更详细的可以去官网看,列举其中几十个就可以
• https://spring.io/projects/spring-cloud-circuitbreaker
  

五、SpringCloud和SpringBoot的关系

• springboot专注于快速方便开发单个个体微服务
• springcloud是关注全局的微服务协调整理治理框架,它将springboot开发的一个个单体微服务整合并管理起来,为各个微服务之间提供:配置管理,服务发现,断路器,路由,微代理,事件总栈,全局锁,决策竞选,分布式会话等等集成服务
• springboot可以离开springcloud单独存活,但springcloud离不开springboot,属于依赖关系
• springboot专注于快速,方便的开发单个个体微服务,springcloud关注全局的服务治理框架

六、SpringCloud和Dubbo选型技术

分布式+服务治理Dubbo

目前成熟的互联网架构:应用服务化拆分+消息中间件

Dubbo和SpringCloud的对比

最大区别: SpringCloud抛弃了Dubbo的RPC通信,采用基于HTTP的REST方式

• 两者都有优劣,从一定的角度来说,后者牺牲了服务调用的性能,但也避免了上面提到的RPC带来的问题,而且REST比HTTP更加灵活,服务提供方和调用方 依赖只能靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更合适
  社区影响力: Dubbo中途停更了5年,虽然在2017.7重启了,对于技术发展的新需求,需求有开发者自行拓展升级(比如当当网弄出了DubboX),这对于很多想要采用微服务架构的中小软组织,显得不是特别合适,中小公司没有强大的技术去修改Dubbo源码+周边 一整套解决方案,并不是每一个公司都有阿里的大牛+真正上线的生产环境测试过
  解决问题领域不一样: Dubbo定义的就是RPC框架,Spring Cloud的目标就是微服务架构下的一站式解决方案

Spring Cloud的版本号

Spring Cloud是一个由众多独立子项目组成的大型综合项目,
每个子项目有不同的发行节奏,都维护着自己的发布版本,
Spring Cloud通过一个资源清单BOM(Bill of Materials) 来管理每个版本的子项目清单,
为避免与子项目的发布号混淆,所以没有采用版本号的方式,而是通过命名方式

这些版本号都采用的是伦敦地铁站的名称,同时根据字母表的顺序来对应版本时间顺序
SNAPSHOT是快兆版本不建议使用
GA通常是稳定版本

CAP原则

RDBMS (Mysql,Orcal,sqlServer ) ====>ACID
NoMysql(redis,mongdb) ====>CAP

1. CAP是什么

• C 强一致性
• A 可用性
• P 分区容错性

CAP的三进二:CA,CP,AP

CAP理论的核心:

• 一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求
• 根据CAP原则,将NOSQL数据库分成了满足CA原则,满足CP原则,满足AP原则这三大类:
  • CA:单点集群,满足一致性,可用性的系统,通常扩容性非常差
  • CP:满足一致性,分区容错性,通常性能不是很高
  • AP:满足可用性和分区容错性,通常可能对一致性要求低一些

七、EureKa服务注册与发现

什么是EureKa

• Netfilx在设计EureKa,遵循的就是AP原则
• EureKa是Netfilx的一个字模块,也是核心模块之一,EureKa是一个基于Rest的服务,用于定位服务,以实现云端中间层服务发现和故障转移,服务注册和发现对于微服务来说是很重要的,有了服务注册和发现,只需要使用服务的标识符,就可以访问到服务,而不需要修改服务调用的配置文件了,类似于Dubbo的注册中心,Zookeeper

原理理解

• EureKa的基本架构
  • Spring Cloud 封装了Netfilx公司的EureKa作为服务注册与发现的服务器,它是注册中心
  • 而系统中的其他微服务,使用EureKa客户端连接到Eureka Server并维持心跳(每几秒发送一个请求看看是否还活着)连接,这样的系统的维护人员就可以通过Eureka Server系统来发现系统中的各个微服务是否正常运行,Spring Cloud的一些其它模块(比如Zuul)就可以通过Eureka Server来发现系统中的其它微服务,并执行相关逻辑
  • Eureka包含两个组件:Eureka Server和Eureka Client
  • Eureka Server提供服务注册,各个节点启动后,会在Eureka Server中注册,这样EureKa Server中的服务注册表会将存储所有可用的服务节点信息,服务节点的信息可以在界面直观的看到
  • Eureka Client 是一个Java客户端,用于简化Eureka Server的交互,客户端同时具备一个内置的,使用轮询载算法的负载均衡器,在应用启动后,将会在Eureka Server发送心跳(默认周期为30s),如果Eureka Server 在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务器的节点移除掉(默认周期为90s)
• 三大角色:
  • Eureka Server :提供服务的注册与发现
  • Server Provider :将自身服务注册到Eureka中,从而使消费者能够找到
  • Server Consumer: 服务消费者从Eureka中获取注册服务列表,从而找到消费服务

自我保护机制

一句话总结就是:某个时刻一个微服务不可以用了,Eureka不会立即清理,依旧对该服务的信息进行保存

• 默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳,Eureka Server将会注销该实例(默认90s),但是当网络分区故障发生时,微服务和Eureka之间层正常通信,以上行为可能会变得非常危险了,因为微服务本身其实是健康的,此时不应该注销这个服务,Eureka通过自我保护机制来解决这个问题,当EurekaServer 节点在短时间内丢失过多客户端时(可能会发生网络分区故障),那么这个节点就会进行自我保护模式,一旦进入自我保护模式,EurekaServer就会保护服务注册中的信息,不再删除服务注册表中的数据(也就是不再注销任何微服务),当网络故障恢复后,该EurekaServer节点会自动退出自我保护模式
• 在自我保护模式中,EurekaServer会保护服务注册表中的信息,不再注销任何服务实例,当它接收到心跳数重新恢复到阈值以上时,该EurekaServer就会退出自我保护模式,它的设计哲学就是宁可保留错误的服务注册中心信息,也不盲目的销毁任何可能健康的服务实例,一句话:好死不如赖活.
• 综上:自我保护模式就是一种应对网络异常的安全措施,它的建构哲学是宁可同时保留所有微服务(健康的和不健康的都会保留),也不盲目的注销任何微服务,使用自我保护模式,可以让Eureka Server集群更加的稳定和健壮
• 在Spring Cloud 中,可以使用 eureka.server.enable-self-preservation = false 禁止自我保护模式[不推荐关闭]

七、EureKa和Zookpper的区别

著名的CAP理论指出,一个分布式系统不可能同时满足C,A,P原则,
由于分区容错率在分布式中必须要保证的,因此我们只能在A,和C中权衡

• Zookeeper保证的是CP
• Eureka保证的是AP

Zookeeper保证的是CP

• 当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用,也就是说,服务注册中心功能对可用性的要求要高于一致性,但是zookeeper会出现一种情况,当master节点因为网络故障和其他节点失去联系时,剩余的节点就会重新进行leader选举,问题在于,选择leader的时间太长,30~120s,且选举期间整个zookeeper集群都是不可用的,这就导致了在选举期间服务器瘫痪,在云部署的环境下,因为网络问题使得zk集群时区master节点是较大概率发生的事件,虽然服务最终能恢复,但是漫长的选举时间导致的注册长期不可用是零容忍的

Eureka保证的是AP

• Eureka看明白了这一点,因此在设计的时候实现保证可用性,Eureka各个节点都是平等的,几个节点挂掉不会影响其他节点的正常工作,剩余的节点依然可以提供注册和查询服务,而Eureka的客户端在向Eureka注册时,如果发现连接失败,则会自动切换到其他节点,只要有一台Eureka还在,就能保证注册中心的可用性,只不过查不到信息可能不是最新的,除此之外,Eureka还有一些自我保护机制,如果在15min分钟内查过85%的节点都没有正常的心跳,那么Eureka就会人为客户端与注册中心发生了网络故障,因此会出现以下几种情况:
  • Eureka不再从注册列表中移除因为长时间没有接收到心跳而应该过期的服务
  • Eureka仍然能够接受新服务的注册和查询服务,但是不会被同步到其他节点上(保证当前节点依然可用)
  • 当网络稳定时,当前实例新的注册信息会被同步到其他节点中
    因此Eureka可以很好的应对网络故障导致部分节点会去联系的情况,而不会像Zookeeper那样使得整个服务注册中心都瘫痪

八、Ribbon

1. 什么是Ribbon

• Spring Cloud Ribbon是基于Netfilx Ribbon实现的一套客户端负载均衡的工具
• 简单的说:Ribbon是Netfilx发布的开源项目,主要作用就是提供客户端的软件负载均衡算法,将Netfilx的中间层服务连接在一起,Ribbon的客户端,组件提供系列完整的配置项,如:连接超时,重试等等,简单的说,就是在配置文件中列出LoadBalaner(简称LB:负载均衡)后面所有的机器,Ribbon会自动帮你基于某种规则(如简单轮询,随机连接等等)去连接这些机器,我们也很容易使用Ribbon实现自定义的负载均衡算法

2.Ribbon能干嘛

• LB,负载均衡,在微服务或分布式集群中常用的一种应用
• 负载均衡简单的说就是将用户的请求分摊到多个服务器上,从而达到HA(高可用)
• 常见的负载均衡软件还有Nginx,Lvs等
• 负载均衡的简单分类
  • 集中式LB
    • 即在服务的消费方和提供方之间独立适用的LB设施,如Nginx,由该设施复杂把访问请求通过某种策略发至服务的的提供方
  • 进程式LB
    • 将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选取一个合适的服务器
    • Ribbon就属于进程式LB,它只是一个类库,集成于消费方进程,消费方通过它来获取到服务提供方的地址!

九、Fegin

• Fegin是声明式Web Service客户端,它让微服务之间的调用变得更简单了,类似于controller调用service,Spring Cloud集成了Ribbon和Eureka,可以使用Fegin时提供负载均衡的http客户端
  • 只需要创建一个接口,写注解就可以了

Fegin可以干嘛

1. Fegin只在使编写Java Http客户端变得更容易
2. 前面的Ribbon+RestTemplate时,利用RestTemplate对Http请求的封装处理,形成一套模板化的调用方法,但是在实际开发中,由于对服务依赖的调用可能不止一处,往往一个接口就会被多处调用,所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用,所以,Feign在此基础上做了进一步封装,由他来帮助我们定义和实现依赖服务接口的定义,在Fegin实现下,我们只需要创建一个接口并使用注解的方式来配置它(类似于以前DAO接口上标注@Mapper注解,现在是一个微服务接口上面标注一个Fegin注解即可),即可完成对服务提供方的接口绑定,简化了使用Spring Cloud Ribbon时,自动封装服务调用客户端的开发量
3. 更加面向接口编程

Fegin继承了Ribbon

利用Ribbon维护MicroServiceCloud-Dept的服务列表信息,并且通过轮询实现了客户端的负载均衡,而与Ribbon不同的是,通过Feign只需要定义服务绑定接口且以声明式的方法,优雅而且简单的实现了服务调用

九、Hystrix

分布式系统面临的问题

• 复杂分布式体系中的应用程序有数十个依赖,每个依赖在某些时候将不可避免的失败!

服务雪崩

• 多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其他的微服务,这就是所谓的"扇出",如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的"雪崩效应"
• 对于高流量的应用来说,单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和,比失败更糟糕的是,这些应用程序还可能导致服务服务之间的延迟增加,备份队列,线程和其他系统资源紧张,导致整个系统发生更多的级联故障,这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统
  我们需要弃车保帅

什么是Hystrix

• Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时,异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务,避免级联故障,以提高分布式系统的弹性.
  “断路器” 本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝).向调用方法返回一个服务预期的,可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方法无法处理的异常,这样就可以保证了服务调用方的线程不会被长时间,不必要的占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩

服务熔断

• 熔断机制是对应雪崩效应的一种微服务链路保护机制
• 当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回 错误的信息.当检测到该节点微服务调用响应正常后恢复调用链路,在SpringCloud 框架里熔断机制通过Hystrix实现,Hystrix会监控微服务间调用的状况,当失败的调用到一定的阈值,缺省的是5s内20次调用失败就会启动熔断机制,熔断机制的注解是@HystrixCommand

十、Zuul路由器和过滤器

路由是微服务不可缺少的一部分,例如/可能被映射到你的web应用程序,/api/users被映射到用户服务,/api/shop被映射到商店服务,zuul是Netfix的基于JVM的路由器和服务器端负载平衡器

• Netfilx将Zuul用于以下用途

1. 见证方法
2. 连接
3. 压力测试
4. 金丝雀测试
5. 动态路由
6. 服务迁移
7. 减载
8. 安全
9. 静态响应处理
   10.主动/主动流量管理

• Zuul的规则引擎可使用几乎所有JVM语言编写规则和过滤器,并内置对Java和Groovy的支持

十一、Config

是一个C-S架构,通过客户端访问服务端,服务端访问远程Git

什么是Spring Cloud分布式配置中心

• Spring Cloud Config 为微服务架构中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所欲环境提供了一个中心化的外部配置
• Spring Cloud Config分为服务端和客户端两部分
• 服务端也称为 分布式配置中心,它是一个独立的微服务应用,用来连接配置服务器并为客户端提供获取配置信息,加密,解密信息等访问接口
• 客户端则是通过指定的配置中心来管理应用资源,以及与业务相关的配置内容,并在启动的时候从配置中心获取和加载配置信息,配置服务器默认采用git来存储配置信息,这样就有助于对环境配置进行版本管理,并且可以通过git客户端工具来方便的管理和访问配置内容