Spring cloud 是一个基于 Spring Boot 实现的服务治理工具包,用于微服务架构中管理和协调服务的。Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用 Spring Boot 的开发风格做到一键启动和部署。通过 Spring Boot 风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。有了 Spring Cloud 之后,让微服务架构的落地变得更简单。
当我们的项目采用微服务架构之后就会引发一些列的难题需要去解决,如众多微服务的通信地址应该如何管理,微服务之间应该使用何种方式发起调用,微服务故障该如何处理,众多微服务的配置文件如何集中管理等等,Spring Cloud 为这一系列的难题提供了相应的组件来解决,下面我们简单来理解一下 Spring Cloud 最核心的几大组件如如下:
当我们的微服务过多的时候,管理服务的通信地址是一个非常麻烦的事情,Eureka就是用来管理微服务的通信地址清单的,有了Eureka之后我们通过服务的名字就能实现服务的调用。
Ribbon和Feign都是客户端负载均衡器,它的作用是在服务发生调用的时候帮我们将请求按照某种规则分发到多个目标服务器上,简单理解就是用来解决微服务之间的通信问题。
微服务的调用是非常复杂的,有的时候一个请求需要很多的微服务共同完成,那么一旦某个服务发生故障,导致整个调用链上的微服务全都出现异常,甚至导致整个微服务架构瘫痪。Hystrix就是用来解决微服务故障,保护微服务安全的组件。
zuul作为服务网关,我们可以把它看作是微服务的大门,所有的请求都需要经过zuul之后才能到达目标服务,根据这一特性,我们可以把微服务公共的事情交给zuul统一处理,如:用户鉴权,请求监控等。
微服务架构中的服务实例非常的多,服务的配置文件分散在每个服务中,每次修改服务的配置文件和重新服务实例都是一个很麻烦的工作,Spring Cloud Config作为分布式配置管理中心就是用来统一的管理服务的配置文件。
消息总线是在微服务中给各个微服务广播消息的一个组件,我们使用消息总线构建一个消息中心,其他微服务来接入到消息中心,当消息总线发起消息,接入的微服务都可以收到消息从而进行消费。
当我们的应用采用微服务架构之后,后台可能有几十个甚至几百个服务在支撑,一个请求请求可能需要多次的服务调用最后才能完成,链路追踪的作用就是来监控维护之间的调用关系,让程序员方便直观的感受到一个请求经历了哪些微服务,以及服务的请求时间,是否有异常等。
SpringCloud是基于SpringBoot的,所以两者的jar包都需要导入,需要注意的是SprinbCloud的版本需要和SpringBoot的版本兼容,本文章采用的SpringBoot版本是2.0.5.RELEASE , SpringCloud的版本是Finchley.SR1**。下面是版本兼容图:
Release Train | Boot Version |
Hoxton | 2.2.x |
Greenwich | 2.1.x |
Finchley | 2.0.x |
Edgware | 1.5.x |
Dalston | 1.5.x |
在微服务中服务间通过网络进行通信,那么服务间的远程调用方式有哪些呢?
RPC(Remote Produce Call) 远程过程调用,类似的还有 RMI。自定义数据格式,基于原生 TCP 通信,速度快,效率高。早期的 Webservice,现在热门的 Dubbo,都是 RPC 的典型。
Http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。 现在热门的Rest风格,就可以通过http协议来实现
我们可以认为SpringCloud就是基于Http协议实现服务之间的通信。
其实我们并不需要刻意去选择该使用RPC或者是Http,如果架构师选择Dubbo作为微服务开发框架,通信方式自然就是RPC,当架构师选择了SpringCloud作为微服务开发框架,那么通信方式自然就是基于Http协议,当然,如果服务的通信方式成为了微服务的性能瓶颈,那么架构师自然需要去考虑更换微服务的通信协议。
Dubbo 最早是有阿里巴巴提供的一个服务治理和服务调用框架,现在已经成为 Apache 的顶级项目,Dubbo 跟 SpringCloud 最显著的区别是Dubbo的定位只是一个 RPC 框架,相比SpringCloud 来说它缺少很多功能模块,如:网关,链路追踪等,所以往往在使用 Dubbo 作为微服务开发框架的时候,还需要去配合其他的框架一起使用,如:加入 zookeeper 作为注册中心。
早期在国内做分布式(微服务)应用 Dubbo 是比较热门的框架,被许多互联网公司所采用,并产生了许多衍生版本,如网易,京东,新浪,当当等等,奈何在2014年10月 Dubbo 停止维护,在Dubbo 停更的时间里 Spring Cloud 快速追赶上。在2017年9月,阿里宣布重启 Dubbo 项目,计划对 Dubbo 进行持续更新维护。2018.2月,阿里将 Dubbo 捐献给 Apache 基金会,Dubbo 成为Apache 孵化器项目。
所以当前微服务架构,Dubbo 和 SpringCloud 比较火,另外还有 Thrift、gRPC 等等 。很多人把 SpringCloud 和 Dubbo 进行对比,其实两个框架并没有太大的可比性,因为他们的定位不同。Spring Cloud 是一个完整的微服务解决方案,它提供了微服务各问题的解决方案集合,而Dubbo 是一个高性能的 RPC 框架,它有着很多功能的缺失。
定位不一样
SpringCloud 为了微服务的落地提供了一套完整的组件,而 Dubbo 只是一个 RPC 框架,缺失的功能很多。
通讯协议不一样
Dubbo 的通信方式是 RPC,基于原声的 tcp,性能较好,而 SpringCloud 的通信方式基于Http 协议,虽然底层基于 tcp,但是 Http 的封装过于臃肿,但是使用 Http 好处在于互相通信的两个服务可以使用不同的编程语言去编写,只要他们都支持 Http 通信即可互相调用,而 Dubbo 只支持 Java,当然 Dubbo 交给 Apache 维护之后做了升级,Dubbo 在以后不仅仅支持 Java。
背景都很强大
Dubbo 背靠阿里和 Apache,淘宝就是使用的 Dubbo 来开发经理过双" 11 "期间的高并发大流量检验,可以说是非常的稳定和成熟,SpringCloud 是 Spring 家族的成员,严格遵循 Martin Fowler 提出的微服务规范,可以认为 SpringCloud 是微服务架构的标准,总之两者背景都很强大,文档完善,社区活跃,所以不管作何选择,都是很有前途的。
开发风格
从开发风格上来讲,Dubbo 官方推荐倾向于使用 Spring xml 配置方式,SpringCloud 是基于SpringBoot 的开发风格,即采用注解的方式进行配置,从开发速度上来说,SpringCloud 具有更高的开发和部署速度。