spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,均可以用 spring boot 的开发风格作到一键启动和部署。git
在分布式架构中,断路器模式的做用也是相似的,当某个服务单元发生故障(相似用电器发生短路)以后,经过断路器的故障监控(相似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。spring
Eureka:服务注册于发现。编程
Feign:基于动态代理机制,根据注解和选择的机器,拼接请求 url 地址,发起请求。后端
Ribbon:实现负载均衡,从一个服务的多台机器中选择一台。缓存
Hystrix:提供线程池,不一样的服务走不一样的线程池,实现了不一样服务调用的隔离,避免了服务雪崩的问题。springboot
Zuul:网关管理,由 Zuul 网关转发请求给对应的服务。服务器
SpringCloud和Dubbo都是如今主流的微服务架构
SpringCloud是Apache旗下的Spring体系下的微服务解决方案
Dubbo是阿里系的分布式服务治理框架
从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo自己只是实现了服务治理,而SpringCloud如今以及有21个子项目之后还会更多
因此其实不少人都会说Dubbo和SpringCloud是不公平的
可是因为RPC以及注册中心元数据等缘由,在技术选型的时候咱们只能两者选其一,因此咱们经常为用他俩来对比
服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义
服务的注册中心来看,Dubbo使用了第三方的ZooKeeper做为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,固然SpringCloud也可使用ZooKeeper实现,但通常咱们不会这样作
服务网关,Dubbo并无自己的实现,只能经过其余第三方技术的整合,而SpringCloud有Zuul路由网关,做为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制,事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素微信
从技术选型上讲~网络
目前国内的分布式系统选型主要仍是Dubbo毕竟国产,并且国内工程师的技术熟练程度高,而且Dubbo在其余维度上的缺陷能够由其余第三方框架进行集成进行弥补
而SpringCloud目前是国外比较流行,固然我以为国内的市场也会慢慢的偏向SpringCloud,就连刘军做为Dubbo重启的负责人也发表过观点,Dubbo的发展方向是积极适应SpringCloud生态,并非起冲突架构
Rest和RPC对比
其实若是仔细阅读过微服务提出者马丁福勒的论文的话能够发现其定义的服务间通讯机制就是Http Rest
RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,咱们须要为每个微服务进行接口的定义,并经过持续继承发布,须要严格的版本控制才不会出现服务提供和调用之间由于版本不一样而产生的冲突
而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是经过一个约定进行规范,但也有可能出现文档和接口不一致而致使的服务集成问题,但能够经过swagger工具整合,是代码和文档一体化解决,因此REST在分布式环境下比RPC更加灵活
这也是为何当当网的DubboX在对Dubbo的加强中增长了对REST的支持的缘由
文档质量和社区活跃度
SpringCloud社区活跃度远高于Dubbo,毕竟因为梁飞团队的缘由致使Dubbo中止更新迭代五年,而中小型公司没法承担技术开发的成本致使Dubbo社区严重低落,而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起
Dubbo通过多年的积累文档至关成熟,对于微服务的架构体系各个公司也有稳定的现状
SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速搭建单个微服务
而SpringCloud专一于解决各个微服务之间的协调与配置,服务之间的通讯,熔断,负载均衡等
技术维度并相同,而且SpringCloud是依赖于SpringBoot的,而SpringBoot并非依赖与SpringCloud,甚至还能够和Dubbo进行优秀的整合开发
总结:
SpringBoot专一于快速方便的开发单个个体的微服务
SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务
SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
SpringBoot专一于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架
1.远程过程调用(Remote Procedure Invocation):
也就是咱们常说的服务的注册与发现
直接经过远程过程调用来访问别的service。
优势:
简单,常见,由于没有中间件代理,系统更简单
缺点:
只支持请求/响应的模式,不支持别的,好比通知、请求/异步响应、发布/订阅、发布/异步响应
下降了可用性,由于客户端和服务端在请求过程当中必须都是可用的
2.消息:
使用异步消息来作服务间通讯。服务间经过消息管道来交换消息,从而通讯。
优势:
把客户端和服务端解耦,更松耦合
提升可用性,由于消息中间件缓存了消息,直到消费者能够消费
支持不少通讯机制好比通知、请求/异步响应、发布/订阅、发布/异步响应
缺点:
消息中间件有额外的复杂
在计算中,负载均衡能够改善跨计算机,计算机集群,网络连接,中央处理单元或磁盘驱动器等多种计算资源的工做负载分布。负载均衡旨在优化资源使用,最大吞吐量,最小响应时间并避免任何单一资源的过载。使用多个组件进行负载均衡而不是单个组件可能会经过冗余来提升可靠性和可用性。负载平衡一般涉及专用软件或硬件,例如多层交换机或域名系统服务进程。
1.服务发布时,指定对应的服务名,将服务注册到 注册中心(eureka zookeeper)
2.注册中心加@EnableEurekaServer,服务用@EnableDiscoveryClient,而后用ribbon或feign进行服务直接的调用发现。
在复杂的分布式系统中,微服务之间的相互调用,有可能出现各类各样的缘由致使服务的阻塞,在高并发场景下,服务的阻塞意味着线程的阻塞,致使当前线程不可用,服务器的线程所有阻塞,致使服务器崩溃,因为服务之间的调用关系是同步的,会对整个微服务系统形成服务雪崩
为了解决某个微服务的调用响应时间过长或者不可用进而占用愈来愈多的系统资源引发雪崩效应就须要进行服务熔断和服务降级处理。
所谓的服务熔断指的是某个服务故障或异常一块儿相似显示世界中的“保险丝"当某个异常条件被触发就直接熔断整个服务,而不是一直等到此服务超时。
服务熔断就是至关于咱们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,经过维护一个本身的线程池,当线程达到阈值的时候就启动服务降级,若是其余请求继续访问就直接返回fallback的默认值
优势
每个服务足够内聚,代码容易理解
开发效率提升,一个服务只作一件事
微服务可以被小团队单独开发
微服务是松耦合的,是有功能意义的服务
能够用不一样的语言开发,面向接口编程
易于与第三方集成
微服务只是业务逻辑的代码,不会和HTML,CSS或者其余界面组合
开发中,两种开发模式
先后端分离
全栈工程师
能够灵活搭配,链接公共库/链接独立库
缺点
分布式系统的负责性
多服务运维难度,随着服务的增长,运维的压力也在增大
系统部署依赖
服务间通讯成本
数据一致性
系统集成测试
性能监控
1.ZooKeeper保证的是CP,Eureka保证的是AP
ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,可是选举期间不可用的
Eureka各个节点是平等关系,只要有一台Eureka就能够保证服务可用,而查询到的数据并非最新的
自我保护机制会致使
Eureka再也不从注册列表移除因长时间没收到心跳而应该过时的服务
Eureka仍然可以接受新服务的注册和查询请求,可是不会被同步到其余节点(高可用)
当网络稳定时,当前实例新的注册信息会被同步到其余节点中(最终一致性)
Eureka能够很好的应对因网络故障致使部分节点失去联系的状况,而不会像ZooKeeper同样使得整个注册系统瘫痪
2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等
3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
4.Eureka本质上是一个工程,而ZooKeeper只是一个进程
当Eureka Server 节点在短期内丢失了过多实例的链接时(好比网络故障或频繁启动关闭客户端)节点会进入自我保护模式,保护注册信息,再也不删除注册数据,故障恢复时,自动退出自我保护模式。
ribbon是一个负载均衡客户端,能够很好的控制htt和tcp的一些行为。feign默认集成了ribbon。
1.feign采用的是基于接口的注解
2.feign整合了ribbon,具备负载均衡的能力
3.整合了Hystrix,具备熔断的能力
使用:
1.添加pom依赖。
2.启动类添加@EnableFeignClients
3.定义一个接口@FeignClient(name=“xxx”)指定调用哪一个服务
1.Ribbon都是调用其余服务的,但方式不一样。
2.启动类注解不一样,Ribbon是@RibbonClient feign的是@EnableFeignClients
3.服务指定的位置不一样,Ribbon是在@RibbonClient注解上声明,Feign则是在定义抽象方法的接口中使用@FeignClient声明。
4.调用方式不一样,Ribbon须要本身构建http请求,模拟http请求而后使用RestTemplate发送给其余服务,步骤至关繁琐。Feign须要将调用的方法定义成抽象方法便可。
spring cloud bus 将分布式的节点用轻量的消息代理链接起来,它能够用于广播配置文件的更改或者服务直接的通信,也可用于监控。
若是修改了配置文件,发送一次请求,全部的客户端便会从新读取配置文件。
使用:
1.添加依赖
2.配置rabbimq
防雪崩利器,具有服务降级,服务熔断,依赖隔离,监控(Hystrix Dashboard)
服务降级:
双十一 提示 哎哟喂,被挤爆了。 app秒杀 网络开小差了,请稍后再试。
优先核心服务,非核心服务不可用或弱可用。经过HystrixCommand注解指定。
fallbackMethod(回退函数)中具体实现降级逻辑。
当一个服务调用另外一个服务因为网络缘由或自身缘由出现问题,调用者就会等待被调用者的响应 当更多的服务请求到这些资源致使更多的请求等待,发生连锁效应(雪崩效应)
断路器有彻底打开状态:一段时间内 达到必定的次数没法调用 而且屡次监测没有恢复的迹象 断路器彻底打开 那么下次请求就不会请求到该服务
半开:短期内 有恢复迹象 断路器会将部分请求发给该服务,正常调用时 断路器关闭
关闭:当服务一直处于正常状态 能正常调用
在分布式系统中,因为服务数量巨多,为了方便服务配置文件统一管理,实时更新,因此须要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client。
使用:
一、添加pom依赖
二、配置文件添加相关配置
三、启动类添加注解@EnableConfigServer
在微服务架构中,须要几个基础的服务治理组件,包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等,由这几个基础组件相互协做,共同组建了一个简单的微服务系统
在Spring Cloud微服务系统中,一种常见的负载均衡方式是,客户端的请求首先通过负载均衡(zuul、Ngnix),再到达服务网关(zuul集群),而后再到具体的服。,服务统一注册到高可用的服务注册中心集群,服务的全部的配置文件由配置服务管理,配置服务的配置文件放在git仓库,方便开发人员随时改配置。
项目截图:
项目源码:
视频教程:
项目教程文档(500页):
工具清单:
如何领取?
扫描下方二维码关注微信公众号:Java团长;
而后在公众号后台回复关键字:001