Spring Cloud

Spring官方在spring boot的基础上,对Netflix开源组件进一步封装,提供了一个名为Spring Cloud的开源的一套云应用开发工具,一个非常优秀的服务治理框架。另一个非常优秀的服务治理框架 Dubbo。
Spring Cloud专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖。

Netflix公司和Pivotal公司

Netflix是一家视频网站,该网站上的美剧应该是最火的。Netflix的微服务大规模的应用,在技术上毫无保留的把一整套微服务架构核心技术栈开源了出来,叫做Netflix OSS。

Pivotal把Netflix开源的一整套核心技术产品线做了一系列的封装,就变成了Spring Cloud,Spring Cloud到现在为止不只有Netflix提供的方案可以集成,但其中Netflix是最成熟的。

Spring Cloud微服务架构

在Spring Cloud微服务系统中,一种常见的负载均衡方式是:客户端的请求首先经过负载均衡(zuul、Ngnix),再到达服务网关(zuul集群),然后再到具体的服务。服务统一注册到高可用的服务注册中心集群,服务的所有的配置文件由配置服务管理,配置服务的配置文件放在git仓库,方便开发人员随时改配置。

Spring Cloud微服务架构中的几个基础服务治理组件:

  • 服务注册中心:Eureka Server
  • 注册服务:Eureka Client
  • 发现服务:Discovery Client
  • 负载均衡:Load Balance、RestTemplate、Ribbon,Feign
  • 断路器:Hystrix,另外Feign自带断路器功能。断路打开后,可以避免连锁故障,fallback方法可以直接返回一个固定值。Turbine可以汇聚监控信息,并提供给Hystrix Dashboard集中展示和监控。
  • 分布式配置中心:Spring Cloud Config,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。两个角色,config server config client。
  • 消息总线:Spring Cloud Bus,将分布式节点加入消息总线,利用轻量的消息代理(message broker 经纪人)使得应用程序可以高效地解耦通信过程。在众多的开源消息中间件产品中,当前版本的spring cloud bus仅支持两款中间件产品:rabbitmq和kafka两个binder,也可以自己写binder扩展。
  • Api gateway:微服务场景下,将细粒度的服务组合起来提供一个粗粒度的服务,所有请求都导入一个统一的入口,那么整个服务只需要暴露一个api,对外屏蔽了服务端的实现细节,也减少了客户端与服务器的网络调用次数。与业务关系并不大的通用处理逻辑可以从Api gateway中剥离出来,Api gateway仅仅负责服务的编排与结果的组装。这样对一些后端微服务进行了代理,避免了各个后端服务独立管理CORS和验证问题。
  • 路由网关转发和过滤器:zuul,zuul还能过滤做一些安全验证,zuul默认和Ribbon结合实现了负载均衡的功能。Zuul是Netflix 提供的一个开源组件,是致力于在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。zuul静态路由配置规则:
    分布式系统中未使用注册服务时,service1的名称可更换,下面的配置中.path中的**会被添加到.url的后面。若不配置.url,可直接使用service1作为请求路径。

    zuul.routes.service1.url=http://localhost:8002/storage/
    zuul.routes.service1.path=/proxy/**
    
  • 动态路由
    动态路由需要达到配置持久化和动态刷新的效果。即不仅要能满足从spring的配置文件properties加载路由信息,还需要从数据库加载配置。另外一点是,在容器启动后,能动态刷新内存中的路由信息,达到不停机维护路由信息的效果。
  • 数据监控,Spring Boot Actuator 提供了强大的应用自省功能,提供了丰富的 Endpoints 的信息,覆盖 Spring Boot 应用程序运行的方方面面。这些指标都是以 JSON 接口数据的方式呈现。而使用 Spring Boot Admin 可以实现这些 JSON 接口数据的界面展现,结合可视化的 Spring Boot Admin 管理界面,一切显得如此“高大上”。
  • 链路追踪:Sleuth。

Ribbon、Feign与Nginx

Feign与Ribbon区别之一是调用方式不同。Ribbon需要自己构建http请求使用RestTemplate发送给其它服务,步骤繁琐。Feign则是在Ribbon的基础上进行了改进,采用接口的方式将需要调用的其他服务的方法定义成抽象方法。Feign 是一个声明web服务客户端,Feign 是一个使用起来更加方便的HTTP 客戶端,使用起来就像是调用自身工程的方法。Feign包含了ribben,feign是远程调用的,ribbon是做负载均衡。

Nginx是服务端负载均衡,即请求由 nginx 服务器端进行转发。负载均衡、反向代理,代理后端服务器。隐藏真实地址,防火墙,不能外网直接访问,安全性较高。

Ribbon是客户端负载均衡, 是从 eureka 注册中心服务器端上获取服务注册信息列表,缓存到本地,然后在本地实现轮询负载均衡策略,即在客户端实现负载均衡。

应用场景的区别:Nginx 适合于服务器端实现负载均衡 比如 Tomcat ,Ribbon 适合与在微服务中 RPC 远程调用实现本地服务负载均衡,比如 Dubbo、SpringCloud 中都是采用本地负载均衡。

Cloud与Boot与微服务的关系

微服务是一种架构的理念,提出了微服务的设计原则,从理论为具体的技术落地提供了指导思想。
Spring Boot是一套快速配置脚手架,可以基于Spring Boot快速开发单个微服务。Spring Cloud是一个基于Spring Boot实现的服务治理工具包。Spring Boot专注于快速、方便集成的单个微服务个体,Spring Cloud关注全局的服务治理框架。Spring Boot/Cloud是微服务实践的最佳落地方案。

Cloud版本变化

  • Spring Cloud Finchley 在2018年 06 月 19 日正式发布,这次的重大发布主要带来了以下 4 项重大更新。
    (1)新增 Spring Cloud Gateway 组件
    Spring Cloud Gateway 是一个基于 Spring Webflux 和响应式 Netty 的下一代 API 网关,用来替换 Spring Cloud Netflix Zuul。它提供了更加简单的动态路由,以及针对每个路由的过滤器(如地址重写、断路器、添加/删除请求头、限流和安全等)。
    (2)新增 Spring Cloud Function 组件
    Spring Cloud Function 的主要功能如下:
    通过一系列函数推进业务逻辑的实现;
    将业务逻辑的开发生命周期从任何特定运行目标中分离,以便相同的代码可以作为一个 Web 端点、一个流处理器或一个任务来运行;
    支持一个跨 serverless providers 的统一编程模型,并拥有独立运行的能力(本地或 PaaS 平台);
    支持在 serverless providers 上面启用 Spring Boot 特性,如自动配置、依赖注入、指标等;
    (3)兼容 Spring Boot 2.0.x
    Finchley 版本是基于 Spring Boot 2.0.x 构建的,官方建议不要与 Spring Boot 1.5.x 及之前的版本一起工作。
    (4)最低支持 JDK 1.8
    JDK 门槛提高了,1.8 毕竟是现在的主流。
  • Camden。
  • Dalston将于 2018 年 12 月结束生命周期。
  • Edgware伴随着 Spring Boot 1.5.x 的结束而结束生命周期。

参考:
《Spring Cloud微服务实战》
http://blog.didispace.com/
http://blog.csdn.net/forezp/article/details/70148833
http://blog.csdn.net/u010066934/article/details/54232622

Spring Cloud 文档
http://cloud.spring.io/spring-cloud-static/spring-cloud.html#_features

PiggyMetrics微服务编译运行解析
http://blog.csdn.net/nihaomanihao11/article/details/73822681
http://blog.csdn.net/rickiyeat/article/details/60792925

中小型互联网公司微服务实践-经验和教训
http://www.ityouknow.com/springcloud/2017/10/19/micro-service-practice.html

Spring Cloud各个微服务之间用HTTP通信的效率的讨论

Spring cloud的http从几个方面可以优化:1、换成okhttp3。2、应用中不要做异步传输,防止异步等待,如果遇到异步场景,一定要利用好消息队列和缓存。3、如果http1.1,有些场景利用keep-alive,减少连接损耗。4、可以考虑尝试HTTP/2。替换原有的Jackson序列化为更快的或者更适合的序列化方式(例如fastJson,kryo);还有http连接池替换实现等都会有可观的性能提升。
一般场景下spring cloud的性能足以满足大多数需求,最终要看服务拆分是否合理和业务场景的实际需求。
rpc固然速度比http快,但是稳定性、数据传输的可靠性、熔断保护、更方便的链路监控和追踪,这时候HTTP的优势就体现了。
http传输内容上比rpc多了几十字节的头,对于一般都是几k到几十上百k的数据,几十个字节的头影响不大。
如果使用feign,会默认加keepalive也是长链接,就多了http的20字节报文头,但是开发效率却提升了几个档次。
目前很多大型项目多语言共存,http是最通用的协议,可以很好地解决跨语言跨平台兼容性。比如Dubbo协议,无法简单地实现跨语言。http交互只是协议比较重,但不会慢太多,追求单机极致性能的确可以考虑换协议。
微服务的一个重要理念就是水平扩展,慢这个问题通过业务设计还有多实例部署可以很好地提速。http协议很成熟,并且特点熟知:1.支持客户/服务器模式。2.简单快速。3.灵活。4.无连接。5.无状态。也是一个速度与开发成本还有兼容性相互妥协兼顾的结果。

https://www.zhihu.com/question/270355472

spring cloud与dubbo性能对比
http://www.cnblogs.com/chen110xi/p/6349580.html

Eureka配置

eureka.client.register-with-eureka: 表示是否将自己注册到Eureka Server, 默认为true。 如果当前应用就是Eureka Server,则设为 false。
eureka.client.fetch-registry: 表示是否从Eureka Server获取注册信息,默认为true。如果这是一个单点的 Eureka Server,不需要同步其他节点的数据,可以设为false。
eureka.client.serviceUrl.defaultZone:在client端可以指定多个eureka服务,用逗号分隔。
https://www.jianshu.com/p/67fa6bbdbadf

在eureka中注册的服务能互通的前提是各服务间的网络本来就是通的。
主机服务程序在eureka中默认使用哈希值代替ip来作为识别码,可以配置eureka.instance.preferIpAddress=true来指定使用IP来作为识别码。

是纯正的 servlet 应用,需部署到web容器中。

Hystrix

使用feign时断路器不起作用,检查在引入了openfeign依赖后,不要再引入ribbon、hystrix。

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
<version>2.1.0.RELEASE</version>
</dependency>

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

发表评论