微服务
在 jsp 时代,应用前后端耦合,前后端 all in 一台服务器,随着流量的增大,代码数量的增加,单体应用不再适合互联网的发展,微服务顺应提出。
微服务是一种用于构建应用的架构方案。区别于更为传统的单体式方案,将应用拆分成多个核心功能。每个功能都被称为一项服务,可以单独构建和部署,这意味着各项服务在工作(和出现故障)时不会相互影响。
参考: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 不是使用数字作为版本号,而是将伦敦地铁站作为版本号,这让我想起被地铁支配的恐惧。
目前 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 门派也越来越强大,到处都是他的传说
Spring Cloud 与 Dubbo 区别
目前来说,在 Java 领域,微服务主要是 Spring Cloud 和 Dubbo 的天下,因此,人们经常喜欢比较两种技术,然后选择其中一种进行搭建。
由于 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 的注册中心。在分布式系统中,包含很多个节点,这些节点大体分为消费者和提供者。
服务端和客户端就是通过 Eureka 进行管理的。举一个例子,Eureka 就好比小区的快递箱,快递就是服务端,取快递的人就是客户端。我们什么时候可以取快递呢,等快递箱向我们发送短信,我们就可以去取快递了。这就是 Eureka 的作用。这样看来服务中心 Eureka 是十分重要的,为了保证高可用,避免注册中心挂掉,我们两眼一抹黑的尴尬局面,一般来说, Eureka 会做集群,保证高可用。同理可得,服务中心我们也需要集群,保证高可用。
Eureka 作为 Spring Cloud 框架的注册中心,与之对应的是 Dubbo 框架的Zookeeper。他俩有什么区别呢?这里需要引入一个 CAP 定理。所谓 CAP 定理,分布式系统的三个指标 C(一致性)、A(可用性)、P(分区容错性)不可以同时满足了。
一般来说,分区容错无法避免,因此可以认为 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 组件。
Hystrix 主要是通过服务熔断和服务降级来解决服务雪崩问题。那么问题来了,服务熔断和服务降级的区别又是什么?
简单来说服务熔断属于服务降级的一种,而服务降级有很多种降级方式!如开关降级、限流降级、熔断降级。
参考:https://www.cnblogs.com/rjzheng/p/10340176.html
Zuul
Zuul中文是神兽的意思。在Spring Cloud 中,Zuul是一项网关服务,可提供动态路由,监视,弹性,安全性等。
简单的话,Zuul 就是楼下保安亭的大爷,所有进入大楼的人,都需要大爷检查,得到大爷的许可。 我们可以通过一张图理解。
Spring Cloud Config
实际工作中,我们可能会有几十上百的微服务节点,每一个节点有需要有配置信息,比如数据库的连接,服务中心的地址等等,当中信息变化的时候,我们可能面临手动一台一台修改的囧境。为了解决上述问题,我们能否借鉴 Git 的思想,有一个标准的配置,当我们配置修改,我们只需要同步刷新一下即可,不用手动搬运呢?答案是有的,我们可以通过 Spring Cloud Config 达到同步更新配置信息。