Spring Cloud 理论篇

微服务

在 jsp 时代,应用前后端耦合,前后端 all in 一台服务器,随着流量的增大,代码数量的增加,单体应用不再适合互联网的发展,微服务顺应提出。

image

微服务是一种用于构建应用的架构方案。区别于更为传统的单体式方案,将应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作(和出现故障)时不会相互影响。

image

参考:https://www.redhat.com/zh/topics/microservices/what-are-microservices

Spring Cloud 版本

在微服务大哥的带领下,各种架构层出不穷,有 Dubbo、gRPC、Thrift、SpringCloud 等等,其中 Spring Cloud 背靠 Spring 生态,脱颖而出。Spring Cloud 框架是在 Springboot 框架基础上编写的,因此在技术选型的时候,我们需要注意 Spring Cloud 版本要与 Springboot 版本对应。

Spring Cloud 社区活跃,已经出了好几个版本,生命力旺盛。值得一提的是他的版本号。SpringCloud 不是使用数字作为版本号,而是将伦敦地铁站作为版本号,这让我想起被地铁支配的恐惧。

image

目前 SprinCloud官网主推荐版本是 Hoxton SR1。Spring Cloud 与 Spring Boot 有明确的版本对应关系。

Spring Cloud Spring Boot
Hoxton 2.2.x
Greenwich 2.1.x
Finchley 2.0.x
Edgware 1.5.x
Dalston 1.5.x
Camden 1.4.x
Brixton 1.3.x
Angel 1.2.x

从图表可以看出 Spring Cloud 版本号的首字母是按照字母顺序排列的。
本文主要介绍的是基于 Spring Boot 1.5.x 的 Dalston 版本的 Spring Cloud。

Spring Cloud 是什么

Spring boot 是一个身怀绝技的武林高手,能上九天揽月下五洋捉鳖,反正就是牛,他喜欢结交武林各路英雄豪杰,有 MyBatis 、Redis、RabbitMQ、Kafaka、Elasticsearch 等等各路高手,他们喜欢行侠仗义,助人为乐,慢慢的以 Spring boot 为大佬的帮派越来越多,有一天 Spring boot 和兄弟们说,要不我们成立一个门派把,就叫 Spring Cloud 。

大家一呼百应。但是成立的门派后,需要管理啊,所以 Spring Cloud 成立了 Eureka 分舵(服务中心),负责对各个分舵同步门派的大事件,有新成员(提供者)加入门派,也需要到 Eureka 分舵报道,其他分舵(消费者)需要协助,也像 Eureka 分舵请求支援。分舵也培养新分舵,出现了几个职能相同的分舵(服务带集群),Eureka 分舵看到分舵越来越多,自己也开始培养新分舵(服务中心集群)。同时也建立了一个 Ribbon 分舵(客户端负载均衡),负责对各个分舵进行高效的沟通。 Spring Cloud 门派名声越来越大,加入的人越来越多,Spring Cloud 开始成立了 Zuul 分舵(网关),负责对新加入的人员进行筛选。

江湖还在,Spring Cloud 门派也越来越强大,到处都是他的传说

image

Spring Cloud 与 Dubbo 区别

目前来说,在 Java 领域,微服务主要是 Spring Cloud 和 Dubbo 的天下,因此,人们经常喜欢比较两种技术,然后选择其中一种进行搭建。

image

由于 Dubbo 是国人开发的,有详细的开发文档,在 Spring Cloud 的萌芽时, 国人凭着满腔热情大力发展 Dubbo,不断试坑,后来 Dubbo 发展停滞,Spring Cloud 的春风开始席卷神州大地。不过,目前 Dubbo 又开始起色,捐给了 Apache 。

技术维度 Dubbo Spring Cloud
服务注册中心 Zookeeper Spring Cloud Netflix Eurrke
服务调用方式 RPC REST API
服务监控 Dubbo-monitor spring boot admin
断路器 不完善 Spirng Cloud Netflix Hystrix
服务网关 Spring Cloud Netflix Zuul
分布式配置 Spring Cloud Config

Eureka 组件

Eureka 音译尤里卡,是 Spring Cloud 的注册中心。在分布式系统中,包含很多个节点,这些节点大体分为消费者和提供者。

image

服务端和客户端就是通过 Eureka 进行管理的。举一个例子,Eureka 就好比小区的快递箱,快递就是服务端,取快递的人就是客户端。我们什么时候可以取快递呢,等快递箱向我们发送短信,我们就可以去取快递了。这就是 Eureka 的作用。这样看来服务中心 Eureka 是十分重要的,为了保证高可用,避免注册中心挂掉,我们两眼一抹黑的尴尬局面,一般来说, Eureka 会做集群,保证高可用。同理可得,服务中心我们也需要集群,保证高可用。

Eureka 作为 Spring Cloud 框架的注册中心,与之对应的是 Dubbo 框架的Zookeeper。他俩有什么区别呢?这里需要引入一个 CAP 定理。所谓 CAP 定理,分布式系统的三个指标 C(一致性)、A(可用性)、P(分区容错性)不可以同时满足了。

image

一般来说,分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们,剩下的 C 和 A 无法同时做到

参考:https://www.ruanyifeng.com/blog/2018/07/cap.html

而 Eureka 的设计原则是 AP,即可用性和分区容错性。他保证了注册中心的可用性,但舍弃了数据一致性,各节点上的数据有可能是不一致的(会最终一致)。ZK 的设计原则是 CP,即强一致性和分区容错性。他保证数据的强一致性,但舍弃了可用性,如果出现网络问题可能会影响 ZK 的选举,导致 ZK 注册中心的不可用。

参考:https://www.infoq.cn/article/jlDJQ*3wtN2PcqTDyokh

Ribbon

微服务划分成几个节点,他们分布在不同的虚拟机,通讯就成了一个难点,通过我们会想到 HttpClient,如果是 Spring的话,我们可以用 RestTemplate,但是在集群环境下,他们并不能做到负载均衡。因此,Ribbon 出现了。Ribbon 是一款在客户端实行负载均衡的工具。Ribbon 其实现原理就是根据在配置文件中列出的机器,自动按照某种规则(轮询,随机)去连接这些机器。使用者也可以自定义自己的负载均衡算法。负载均衡目的是达到高可用。

Feign

Feign 是有一款客户端负载均衡工具。既然有了 Ribbon ,为什么还要有 Feign 呢? 在实际使用 Ribbon 组件中,我们会发现 Ribbon 会让我们硬编码,十分不灵活。因此,在 Ribbon 的基础下,面向接口编程的 Feign 组件 就出现了。Feign 让我们可以编写出优雅的代码,因此,实际中,Feign 得到大力使用。

Hystrix

Hystrix 是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix 能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。

Hystrix 断路器是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控,向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方不会长时间、不必要占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。

提到服务雪崩,我们可以通过一张图来理解。假设我们有三个服务调用 A B C。当其中下游的 C 服务发生故障,就有可能引起 服务雪崩。为了解决 服务雪崩,我们就需要引入 Hystrix 组件。

image

Hystrix 主要是通过服务熔断和服务降级来解决服务雪崩问题。那么问题来了,服务熔断和服务降级的区别又是什么?

image

简单来说服务熔断属于服务降级的一种,而服务降级有很多种降级方式!如开关降级、限流降级、熔断降级。

参考:https://www.cnblogs.com/rjzheng/p/10340176.html

Zuul

Zuul中文是神兽的意思。在Spring Cloud 中,Zuul是一项网关服务,可提供动态路由,监视,弹性,安全性等。

image

简单的话,Zuul 就是楼下保安亭的大爷,所有进入大楼的人,都需要大爷检查,得到大爷的许可。 我们可以通过一张图理解。

image

Spring Cloud Config

实际工作中,我们可能会有几十上百的微服务节点,每一个节点有需要有配置信息,比如数据库的连接,服务中心的地址等等,当中信息变化的时候,我们可能面临手动一台一台修改的囧境。为了解决上述问题,我们能否借鉴 Git 的思想,有一个标准的配置,当我们配置修改,我们只需要同步刷新一下即可,不用手动搬运呢?答案是有的,我们可以通过 Spring Cloud Config 达到同步更新配置信息。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,743评论 6 492
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,296评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,285评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,485评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,581评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,821评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,960评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,719评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,186评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,516评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,650评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,329评论 4 330
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,936评论 3 313
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,757评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,991评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,370评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,527评论 2 349

推荐阅读更多精彩内容