很久以前就想写篇关于Spring Cloud的文章,然而终究许久未动笔,直到时间的车轮转到2018。
本篇以基础概要介绍为主,适合宏观了解Spring Cloud的整体布局及主要组件用途。
目录
Spring Cloud背景简介
Microservice微服务
Spring Cloud - Netflix
Sping Cloud - Main Projects
Cloud v.s. Dubbo
总体回顾
Spring Cloud是在云时代背景下,由Spring家族于2015年推出的主要针对分布式系统开发的基础设施,组合,集成了一系列经典的框架(17年版本中就集成了19+个子项目),提供了分布式开发的核心基础功能如服务注册与发现,配置,消息总线,服务网关,负载均衡,服务熔断,数据治理与监控等,它整个框架系列构建与自身家族Spring Boot,大大简化了开发,实现和部署。当然,其幕后推手除了本身大东家Pivotal外,还有Netfix作为强大后盾。
这套框架的整合,集成之道,又一次发挥,弘扬了Spring的“吸星大法”,这正是Spring在框架,架构上的精髓,尽量避免重复轮子,取各家之精华,整合为我用,抽象并构建统一而简单的接口给开发人员,当然Spring初创之时当然自带神器。
另外,Spring Cloud之所以变得炙手可热,除了后云时代,很大程度上也借助了近几年兴起的微服务之风。正是由于Spring Cloud诞生于云端,生而为支持分布式系统及基础,与微服务架构不谋而合,甚至很多人提及Spring Cloud就认为其就是一个微服务框架。
既然谈到这里,顺便提议一下微服务。微服务是一种架构风格,组件的另一种模式或实现,一个大型的系统由多个微服务组成,每个微服务可以独立部署,并且微服务间是松耦合。其中每个微服务理想情况,完成一个小的业务能力。
其实微服务在软件行业发展多年后,突然发现在工业,硬件领域,似乎其更加模块化,一个大型器械或者我们更熟悉的电脑可以通过每个独立的模型部件快速拼搭而成,而一个软件项目则说来惭愧,无法像积木一样快速搭建,尽管已经大规模模块化,组件化...(当然,近几年软件业蓬勃发展,已经有了很多容器技术如Docker, 集群技术K8s, Mesos 等等)
其实“微服务”这个概念名词源于2014年3月Martin大叔写的一片文章 “Microservices”,既然出自大师之手,自然瞬间在坊间开始追捧,推动。
简单来说,微服务架构是以专注于单一职责的小型功能模块为子服务,一个后台服务通过RPC相互通信,去中心化,松耦合化完成复杂业务系统的设计思想。
微服务框架核心要解决或者基础设施必须要做到RPC, 服务注册与发现,负载均衡,分布式配置,服务熔断机制和服务网关路由几个核心要素。
在带来上述好处的同时,也具有维护,部署,版本,运营,DevOps,分布式事务以及本身服务间通信成本,测试等一些列挑战,当然,对于坊间的架构师来说,这都不是事,每一个新技术都看作圣杯,情怀第一。
赶快进入正题 - SpringCloud,先从主要且重要的五大神兽说起:
服务发现 - Netflix Eureka
负载均衡 - Netfilx Ribbon
服务熔断 - Netfix Hystrix
服务网关 - Netflix Zuul
分布式配置 - Spring Cloud Config
怎么样,看看名字就没有夸大Netfix这个强大后盾吧,为了避嫌,以上统称Spring Cloud Netflix。Netflix五大神兽组成了SpringCloud的核心。
P.S. Netflix是美国流媒体提供商,收费视频网站 - 奈飞,VoD内容(Video on Demand)点播,各种美剧,纸牌屋。。。。奈飞的成功关键之一是其本质是一家技术驱动型公司,类似Tesla貌似造汽车,其实是IT+AI,Amazon看起来是网店,其实是IT公司+AWS;
Netflix的技术全栈Genie, Inviso, Asgard, 微服务(上述神兽), EVCache和Dynomite用于大规模Memcached和Redis及很多云端服务框架,和安全框架。
Netflix整个技术栈比较成熟,其潜台词就是其开发也比较早,早于Docker和K8s时代,当时只有AWS云。当然,我们也可以进行定制化,比如选择Netflix的核心优势如Eureka,Zuul,而部署则Docker化。
Eureka掌管服务发现:作为服务中心,基于REST服务,提供云端服务发现,定位服务,同时实现云端服务故障转移,类似于大多分布式框架的核心功能之一,如Locator, ZK等。
RibbonRibbon顾名思义,主要提供客户端的软负载均衡。内置包括了连接超时,重试,以及一些列负载均衡策略:
简单轮询
加权响应
区域感知轮询
随机负载均衡
另外还包括一下功能:
于Eureka集成
基于Archalus完成运行时配置
支持可插拔序列化
整体架构示意图:
Hystrix主要提供服务熔断(Circuit Breaker),或者称之为断路器。
通常来讲,分布式服务的稳定及可用性非常重要,如由于某些机器故障导致服务不可用,或者服务器负载多大造成后续请求无法处理(秒杀),或者bug等造成的服务不可用,极端恶劣情况下,服务相互关联,甚至服务雪崩。
鉴于此,我们需要对分布式服务进行主动内部保护,而常用的缓解或解决方案主要有熔断,隔离,限流及降级。
熔断:参考电路保险丝断路/熔断,如电压过高,保险丝会熔断而避免发生火灾。分布式系统中的熔断,则某个服务调用异常慢或者大量超时,系统主动熔断,避免后续继续恶性循环等待,直接返回,快速释放资源,若目标服务之正常后则恢复服务可用性。
注 : 不忘吐槽一下我大a股的熔断,呵呵。
隔离:隔离也很好理解,如病人隔离避免进一步传染;系统中如线程池隔离,信号量隔离
限流:不同上述出错后的补救机制,限流则是事先预防模式,对于服务请求提前预设最高的QPS阀值,如有些框架用锁来实现
降级(fallback):服务降级则是针对整个分布式系统,当出现整体资源紧缺的情况下,主动关闭一些次级服务,以提升主服务响应,待整体性能恢复后再重新开启次级服务
Hystrix通过隔离服务的访问点,停止级联故障和提供后备选项提高整体分布式系统的弹性延迟和容错能力。
下图为Hystrix的关键流程解析,包括了熔断判断,降级策略
https://github.com/Netflix/Hystrix/wiki/How-it-Works
Zuul主要作为API级别分布式服务网关Gateway(请求转发),类似Nginx,基于JVM路由提供反向代理功能。Netfix Zuul另外扩展在云端上的动态路由,监控,弹性,权限,安全等服务。
简单网关:
多渠道网关:
Spring Cloud Config顾名思义,是提供以解决分布式系统的配置管理方案。包含了Client和Server。
Server端的配置文件服务化,提供运行时动态修改,刷新功能。目前集群配置管理已经做到支持本地存储,Git和SVN,装备精良,大家各取所需。
还是要简单介绍一下其他子项目,虽然比较多。
Spring Cloud Bus
Spring Cloud Bus是将分布式节点用轻量的消息代理连接起来,支持服务之间或者广播通信。同时,消息总线可以为微服务做监控。
比如,当我们修改并提交配置文件时,会通过Bus分发广播消息,从而自动出发对应服务的Refresh:
目前Spring Cloud Bus已经支持Kafka和RabbitMQ.
Spring Cloud for Cloud Foundry
Spring Cloud for Cloud Foundry则主要用于与Pivotal自家开源PaaS云平台CloudFoundry集成。
Spring Cloud Cluster
Spring Cloud Cluster主要为分布式中的需要进行leadership选举的各家提供了抽象,如ZK, Redis, Hazelcast, Consul等。
此外也提供了分布式中需要的集群状态一致性,全局锁,tokens等抽象。
Spring Cloud Data Flow
Spinrg Cloud Data Flow运行时原声云端分布式服务编排服务,其来源于SpringXD重构而成,可以开发和执行大范围数据处理包括ETL,实时处理,流处理,批处理,数据导入导出,持续计算和编排数据通道(Data Pipelines)的统一编程模型和托管服务。
支持DSL,REST
支持单元测试
支持run as Maven或者Docker
支持YARN, Mesos, Ku8s
Spring Cloud Stream
Spring Cloud Stream,轻量级事件驱动框架,对于分布式数据流封装,支持与Redis, Rabbit, Kafka等发送接受消息,分布式服务则可以pub/sub,定义分组/分区。
具体程序中则引入简单的注解@EnableBinding,并通过@StreamListener来处理事件流。
Others 其他集成框架
其他集成的框架太多了,以下简单罗列:
Spring Cloud Consul,基于Hashicorp Consul实现的服务发现与配置,无缝集成Docker
Spring Cloud Task,短生命周期云端/分布式Task
Spring Cloud ZK,使用zk进行服务发现和配置管理
Spring Cloud AWS,使用Spring的API/语法与ASW集成交互
Spring Cloud Sleuth,日志收集,封装了Dapper, Ziplin
Spring Cloud Security,安全控制,如QAuth2
Spring Cloud CLI, 基于Boot CLI, 构建命令行方式云端服务组件
Spring Cloud v.s. Dubbo
Dubbo是阿里开源的基于RPC的分布式服务框架,在多内影响较大,虽然中间维护停滞了很长时间,听说最近又重启了。
Dubbo实现了服务治理,包括服务注册,发现,调度,监控,治理等核心,支持注册中心对等集群,缓存服务,提供高可用与健壮性。
由于Dubbo本身出自电商,大多数场景使用长连接小数据量的模式提供服务使用。
从整体服务治理,成熟度而言,下图提供了更详细的比较,仅参考:
P.S. 图出自网络,此处仅引用:
仅按上图比较来看,Dubbo有点类似Netlfix的核心子集。当然Dubbo新的版本也在开始维护中,期待有更好的表现。
Spring Cloud整体框架比较复杂,有必要快速整体回顾梳理一下:
分布式整体运作的基础目标:RPC, 服务注册与发现,负载均衡,分布式配置,服务熔断机制和服务网关路
服务网关:通过Zuul来实现,响应服务请求
服务注册与发现: 通过Eureka来实现获取可用服务
服务路由:由Ribbon进行负载均衡后,分发到后端具体分布式服务
服务配置:由Spring Cloud Config来支持分布式配置
熔断机制:由Netfix Hystrix来提供熔断机制,主动保护分布式系统
总体来说,Spring Cloud以高级的封装,整合提供了一站式的分布式服务的基础,配置管理,服务发现,熔断,智能路由,微代理,控制总线,token,全局锁,leader选主,分布式会话,集群状态管理等等,大而全!对于微服务开发,搭建,可以量身定制。