微服务框架-SpringCloud简介

前面一篇文章谈到微服务基础框架,而Netflix的多个开源组件一起正好可以提供完整的分布式微服务基础架构环境,而对于Spring Cloud正是对Netflix的多个开源组件进一步的封装而成,同时又实现了和云端平台,和Spring Boot开发框架很好的集成。

Spring Cloud是一个相对比较新的微服务框架,今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。

Spring Cloud 为开发者提供了在分布式系统(配置管理,服务发现,熔断,路由,微代理,控制总线,一次性token,全居琐,leader选举,分布式session,集群状态)中快速构建的工具,使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。

我们先简单阐述下Spring Cloud中文社区对四个基础关键组件的描述:

社区地址:http://springcloud.cn/

Spring Cloud Config配置中心

Spring Cloud Config就是我们通常意义上的配置中心。Spring Cloud Config-把应用原本放在本地文件的配置抽取出来放在中心服务器,本质是配置信息从本地迁移到云端。从而能够提供更好的管理、发布能力。

Spring Cloud Config分服务端和客户端,服务端负责将git(svn)中存储的配置文件发布成REST接口,客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化,从而主动去获取新的配置,这需要每个客户端通过POST方法触发各自的/refresh。

Spring Cloud Netflix 服务发现


Spring Cloud Eureka提供在分布式环境下的服务发现,服务注册的功能。

Spring Cloud Netflix,该项目是Spring Cloud的子项目之一,主要内容是对Netflix公司一系列开源产品的包装,它为Spring Boot应用提供了自配置的Netflix OSS整合。

通过一些简单的注解,开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括:服务发现(Eureka),断路器(Hystrix),智能路由(Zuul),客户端负载均衡(Ribbon)等。

Spring cloud Hystrix 熔断器

断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关),并在远程服务恢复时自动恢复(闭合开关)的设施。

断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关),并在远程服务恢复时自动恢复(闭合开关)的设施,Spring Cloud通过Netflix的Hystrix组件提供断路器、资源隔离与自我修复功能。

Spring Cloud Zuul 服务网关

Spring Cloud Eureka提供在分布式环境下的服务发现,服务注册的功能。

Spring Cloud Netflix,该项目是Spring Cloud的子项目之一,主要内容是对Netflix公司一系列开源产品的包装,它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解,开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括:服务发现(Eureka),断路器(Hystrix),智能路有(Zuul),客户端负载均衡(Ribbon)等。

当然Spring Cloud还有额外扩展的其它很多组件,包括了服务链路监控和跟踪(很关键的一个功能),消息总线,数据流处理,批量任务处理等。而对于整个Spring Cloud微服务框架简单来说,即是:

你只要划分到你的微服务组件和模块,并定义好需要暴露的API接口,那么剩下的整个开发和传统方式没有太大的区别,你开发完成的组件集成起来就是一个分布式可扩展的微服务环境。里面设计到的接口发布,服务注册,服务调用和路由,服务监控,健康检测和流控等都会由微服务框架来帮你完成。

正是有了成熟的微服务框架,我们才更应该将微服务架构设计重心从技术底层转移到组件划分和接口设计上。

SpringCloud和Dubbo的区别问题

对于两者的区别在如下文章有详细描述可以参考:

http://blog.didispace.com/microservice-framework/

可以看到SpringCLoud能够提供的基础能力要多于Dubbo,Dubbo可以看作是SpringCLoud简单实现。

Dubbo是RPC服务治理框架,和Spring Cloud一样具备服务注册、发现、路由、负载均衡等能力。但是没有配置中心,完整的好用全链路监控,需要采用开源的解决方案定制或者自研。Spring cloud的配置中心,全链路监控等组件。从目前来看,Spring Cloud国内中小型企业用的比较多,大型企业可能需要对其需要的组件进行定制化处理。

但是也需要看到Spring Cloud基于注解的服务发现,服务治理等功能具有代码侵入性,dubbo没有代码侵入性,业务开发人员不需要通过注解的方式去关注框架级别的处理。从中间件或者做基础架构的角度来看,其实服务治理等功能对普通的业务程序员应该是透明的,业务程序员不需要关注服务治理框架的使用,专注于业务代码即可。

基于SpringCLoud微服务框架的实践

对于基于SpringCLoud框架的具体实践,建议参考翟永超博客的系列文章,具体如下:

  • 服务注册和发现:http://blog.didispace.com/springcloud1/
  • 服务消费:http://blog.didispace.com/springcloud2/
  • 服务熔断机制:http://blog.didispace.com/springcloud3/
  • 服务配置中心:http://blog.didispace.com/springcloud4/
  • 服务网关:http://blog.didispace.com/springcloud5/
  • 高可用服务注册中心:http://blog.didispace.com/springcloud6/
  • 消息总线:http://blog.didispace.com/springcloud7/

服务注册和发现

注意这里仍然使用的是SpringBoot框架,并和SpringBoot框架进行了集成,在pom.xml配置文件中增加了对SpringCLoud相关包和组件的依赖。在原有的接口API定义的基础上,我们增加@EnableDiscoveryClient注解后,即可以让服务注册中心很轻松的发现服务提供方以及提供的服务。

服务消费

方式1 - Ribbon是一个基于HTTP和TCP客户端的负载均衡器。Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。当Ribbon与Eureka联合使用时,ribbonServerList会被DiscoveryEnabledNIWSServerList重写,扩展成从Eureka注册中心中获取服务端列表。

方式2 - Feign是一个声明式的Web Service客户端,它使得编写Web Serivce客户端变得更加简单。我们只需要使用Feign来创建一个接口并用注解来配置它既可完成。它具备可插拔的注解支持,包括Feign注解和JAX-RS注解。Feign也支持可插拔的编码器和解码器。Spring Cloud为Feign增加了对Spring MVC注解的支持,还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。

断路器

首先在pom.xml文件中增加引入对hystrix依赖,同时在消费端Application主类上增加@EnableCircuitBreaker注解开启断路器功能。注意原有的服务消费方式也涉及到修改,增加了服务Callback的回调函数。

服务网关

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。

原文地址:https://www.cnblogs.com/jiadp/p/9289734.html

时间: 2024-10-12 21:41:42

微服务框架-SpringCloud简介的相关文章

微服务框架——SpringCloud(四)

1.Spring Cloud Config 分布式配置 a.Config服务器 ①新建springboot项目,依赖选择Config Server ②pom文件关键依赖 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.3.RELEASE</ve

微服务框架Dubbo与Springcloud的区别

微服务框架Dubbo与Springcloud的区别 微服务主要的优势如下: 1.降低复杂度 将原来偶合在一起的复杂业务拆分为单个服务,规避了原本复杂度无止境的积累.每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界. 每个服务开发者只专注服务本身,通过使用缓存.DAL等各种技术手段来提升系统的性能,而对于消费方来说完全透明. 2.可独立部署 由于微服务具备独立的运行进程,所以每个微服务可以独立部署.当业务迭代时只需要发布相关服务的迭代即可,降低了测试的工作量同时也降低了服务发布的风

微服务框架-Spring Cloud简介(一)

Spring Cloud是一个微服务框架,相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案. Spring Cloud对微服务基础框架Netflix的多个开源组件进行了封装,同时又实现了和云端平台以及和Spring Boot开发框架的集成. Spring Cloud 为开发者提供了在分布式系统(配置管理,服务发现,熔断,路由,微代理,控制总线,一次性token,全居琐,leader选举,分布式session,集群状态)中快速构建的工具,使用Spring Clo

微服务架构 SpringCloud(一)组件和概念介绍

一:什么是微服务(Microservice) 微服务英文名称Microservice,Microservice架构模式就是将整个Web应用组织为一系列小的Web服务.这些小的Web服务可以独立地编译及部署,并通过各自暴露的API接口相互通讯.它们彼此相互协作,作为一个整体为用户提供功能,却可以独立地进行扩. 微服务架构需要的功能或使用场景 1:我们把整个系统根据业务拆分成几个子系统. 2:每个子系统可以部署多个应用,多个应用之间使用负载均衡. 3:需要一个服务注册中心,所有的服务都在注册中心注册

微服务框架学习收录链接(包括服务搭建中用到mybatis-plus等)

1.基于Spring Boot和Spring Cloud实现微服务架构学习(一)-Spring框架介绍 https://blog.csdn.net/zeb_perfect/article/details/51945350 2.Spring Cloud生态圈简介 https://blog.csdn.net/rickiyeat/article/details/59172258 3.标题:Spring Boot 快速搭建微服务框架详细教程 http://www.jb51.net/article/123

SprngCloud微服务框架搭建(一)

参照来源 :https://blog.csdn.net/forezp/article/details/70148833 1.简介 目前来说,SpringCloud是比较完整的微服务解决方案框架.不像其他rpc远程调用框架,只是解决某个微服务中的问题. 2.微服务框架搭建 2.1.服务的注册与发现Eureka(Finchley版本) 本次采用Eureka作为服务注册与发现的组件. 2.1.1.创建服务注册中心 首先创建一个空的maven工程,在其pom文件引入依赖, Spring Boot 版本采

微服务和SpringCloud入门

微服务是什么 微服务的核心是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底去耦合,每个微服务提供单个业务功能的服务,一个服务做一件事情,从技术角度看就是一种小而独立的处理过程,类似进程概念,能够进行单独启动和销毁,可以拥有独立的数据库. 微服务与微服务架构的区别 微服务:它强调的事服务的大小,它关注的是某个点,是具体解决某一个问题/提供落地对应服务的一个服务应用 微服务架构:它是一种架构模式,它提成将单一应用程序划分成一组小的服务,服务之间相互配合协调,为服务提供最终价值.每个服务运行在

微服务框架对比

功能点/服务框架 Netflix/SpringCloud Motan gRPC Thrift Dubbo/DubboX 功能定位 完整的微服务框架 RPC框架,但整合了ZK或Consul,实现集群环境的基本的服务注册/发现 RPC框架 RPC框架 服务框架 支持REST 是 Eibbon支持多种可插拔的序列化选择 否 否 否 否 支持RPC 否 是 是 是 是 支持多语言 是 否 是 是 否 服务注册/发现 是,Eureka服务注册表,karyon服务端框架支持服务自注册和健康检查 是(zook

谈谈我对微服务、SpringCloud、k8s、Istio的一些杂想

一.微服务与SOA "微服务"是一个名词,没有这个名词之前也有"微服务",一个朗朗上口的名词能让大家产生一个认知共识,这对推动一个事务的发展挺重要的,不然你叫微服务他叫小服务的大家很难集中到一个点上. 业界对微服务与SOA的区别争论比较多大多都是在微观上对比他们的区别什么微服务粒度更细啊.微服务没有ESB啊.微服务通讯相比SOA采用更轻量级的协议啊等等,但是从微观谈区别本身就有悖论, 这些区别只是微服务的一种"最佳实践"而已.我个人理解微服务与S