Spring Cloud微服务治理框架深度解析

 在学习一个技术之前,首先我们要了解它是做什么的,我们为什么要用它。不然看再多资料都理解不了,因此我们先来讲解下Spring Cloud

Spring Cloud是一套微服务治理框架,几乎考虑到了微服务治理的方方面面。那么接下来具体说下 Spring Cloud在微服务框架中都起到了什么作用,提供了什么便利

首先我们来看看互联网架构的发展过程:

传统架构发展史

单体架构

单体结构在微小企业比较常见,典型代表就是一个应用,一个数据库、一个Web就可以跑起来了

以下情况可能会选用单体架构:

1.在企业发展初期,为了保证快速上线,采用此方案较为简单灵活。

2.传统企业中垂直度较高,访问压力小的业务。这种模式下对技术要求较低,方便各层次开发人员接手,也能满足客户需求。

单体架构中,技术选型灵活,优先满足快速上线的要求

垂直架构

在单体架构发展一段时间后,公司的业务模式得到了认可,交易量也慢慢的变大了,这时候企业为了应对更大的流量,就会对原有业务进行拆分,比如说:后台系统,前端系统,交易系统等

在这个阶段往往会将系统分为不同层级,每个层级有对应的职责,UI层负责和用户进行交互,业务逻辑层负责具体业务功能,数据库层负责和上层进行数据交换和存储

这个阶段其实就是我们常说的三层,UI层、业务逻辑层、数据层

服务化架构

随着公司再进一步的做大,垂直子系统会越来越多,系统和系统之间的调用关系不断上升

这种情况下,很多公司都会考虑服务的SOA(Service Oriented Architecture)化。

SOA代表面向服务的架构,将应用程序按照不同的职责划分为不同的模块,不同的模块直接通过特定的协议和接口进行交互。

这样将整个系统切分成很多单个组件服务来完成请求,当流量过大时通过水平扩展相应的组件来支撑,所有组件通过交互来满足整体的业务需求。

服务化架构是一套松耦合的架构,服务的拆分原则是服务内部高内聚,服务之间低耦合。

这个阶段一般使用Web Service或者Dubbo来服务治理。

SOA和微服务的区别

服务化架构已经可以解决大部分企业的需求了,那么为什么我们还要研究微服务呢?

它们的区别有如下几点:

1.微服务架构强调业务系统需要彻底的组件化和服务化,一个组件就是一个产品,可以单独对外提供服务

2.微服务不再强调传统SOA架构里面比较重要的ESB企业服务总线

3.微服务强调每个微服务都有自己独立的运行空间,包括数据库资源。

4.微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调HTTP Rest API的方法进行

5.微服务的切分粒度会更小。

总结:微服务架构是SOA架构思想的一种扩展,更加强调服务个体的独立性、拆分粒度更小

所以说了这么多,为什么用Spring Cloud呢?

因为Spring Cloud不能说是微服务框架里最好的技术,也能说是最周全的技术了

Spring Cloud的特性

1.分布式/版本化配置

2.服务注册和发现

3.路由

4.服务和服务之间的调用

5.负载均衡

6.断路器

7.分布式消息传递

这些特性都是由不同的组件来完成

微服务架构

Spring Cloud解决的第一个问题就是:服务与服务之间的解耦。公司在业务高速发展的同时,服务组件也会相应的不断增加。

服务和服务之间有着复杂的互相调用关系,经常有服务A调用服务B,服务B调用服务C和服务D。。。。,随着服务化组件越来越多,它们之间的调用关系也在成指数级别增长,极端情况下如下图:

这样最容易导致的情况就是牵一发而动全身,经常出现由于某个服务更新而没有通知到其他服务,导致上线后惨案频发。

这时就应该进行服务治理,将服务之间的直接依赖转化为服务对服务中心的依赖。

Spring Cloud核心组件 Eureka就可以解决这类问题。

Eureka

Eureka是Netflix开源的一款提供服务注册和发现的产品,它提供了完整的Service Registry和Service Discovery实现。它也是Spring Cloud体系中最重要的核心组件之一。

简单来说,Eureka就是一个服务中心,将所有的可以提供的服务都注册到它这里来管理,调用者需要的时候去注册中心获取,然后再进行调用,避免了服务之间的直接调用,方便后续的水平扩展、故障转移等。

当然如果服务中心挂掉了,那就是影响全部服务,因此需要搭建Eureka集群来保持高可用性,生存中建议最少两台。

随着系统的流量不断增加,需要根据情况来扩展某个服务,Eureka内部已经提供了均衡负载的功能,只需要增加相应的服务端实例即可。

那么系统运行中某个实例挂了怎么办?

Eureka内容有一个心跳检测机制,如果某个实例在规定时间内没有进行通讯则自动被剔除掉,避免了某个实例挂掉而影响服务。

因此使用Eureka就自动具备了注册中心、负载均衡、故障转移等功能。

Hystrix

在微服务的架构中通常会有多个服务层调用,一个服务的故障可能会导致级联故障,最终造成整个系统不可用的情况,这种现象被称为服务雪崩效应。

服务雪崩效应是一种因 “服务提供者” 的不可用导致 “服务消费者” 的不可用,并将不可用逐步扩大的过程

例如:A是服务提供者,B是A的服务消费者,C和D是B的服务消费者。A不可用引发了B的不可用,B又引发了C和D的不可用,然后就像滚雪球一样,雪崩效应就形成了。

在这种情况下就需要整个服务机构具有故障隔离的功能,避免某一个服务挂掉影响全局。在Spring Cloud中Hystrix组件就扮演了这个角色

Hystrix会在某个服务连续调用N次没有响应的情况下,立刻通知调用端调用失败,避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务,如果服务恢复将继续提供服务。

这种机制被称为服务隔离或服务熔断。

当熔断发生时需要迅速的响应来解决问题,避免故障进一步扩散,那么对熔断的监视就变得非常重要。

熔断的监视现在有两款工具:Hystrix-dashboard和Turbine。

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具,通过Hystrix Dashboard 我们可以直观地看到各个Hystrix Command的请求响应时间,请求成功率等数据。

但是只使用Hystrix Dashboard的话,你只能看到单个应用内的服务信息,这是不够的。

这时我们需要一个汇总系统内多个服务数据,并显示的Hystrix Dashboard上,这个工具就是Turbine。

效果如下:

配置中心

随着微服务不断的增多,每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境,因此每个微服务至少三个环境的配置文件。

这么多的配置文件,如果需要修改某个公共服务的配置信息,如:缓存、数据库等,难免会产生混乱,这个时候就需要引入Spring Cloud 另一个组件:Spring Cloud Config。

Spring Cloud Config

Spring Cloud Config 是一个解决分布式系统的配置管理系统。它包含了Client和Server两个部分,Server提供配置文件的存储、以接口的方式将配置文件的内容提供出去,Client通过接口获取数据,并依据此数据初始化自己的应用。

具体实现是Server端将所有配置文件服务化,需要配置文件的服务实例去Config Server获取对应的数据。将所有配置文件统一整理,避免了配置文件碎片化。

如果服务运行期间改变配置文件,服务不会得到最新配置信息,需要解决这个问题就要引入Refresh。它可以在服务的运行期间重新加载配置文件

当所有的配置文件都存储在配置中心时,配置中心就变成了一个非常重要的组件。如果配置中心出问题就会导致很严重的后果,因此在生产中建议对配置中心做集群,来支持配置中心高可用性。

Spring Cloud Bus

上面的Refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题,但是在真正的实践生产中,可能会有N多个服务需要重新配置。

每次都手动Refresh将是一个巨大的工作量,这时就需要另一个解决方案 Spring Cloud Bus

Spring Cloud Bus 是通过轻量消息代理连接各个分布的节点。一般会用在广播状态变化(例如配置变化)或者其他的消息指令中

Spring Cloud Bus 的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展,也可以用来创建一个或多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道

Spring Cloud Bus 是轻量级的通讯组件,也可以用在其他类似的场景中。有了Spring Cloud Bus之后,当我们改变配置文件提交到版本库中时,会自动触发对应实例的Refresh 

服务网关

在微服务架构模式下,后端服务的实例数一般是动态的,对于客户端而言很难发现动态改变的服务实例的访问地址信息。

因此在基于微服务的项目中为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网管,同时API Gateway中也会实现相关的认证逻辑,从而简化了内部服务之间相互调用的复杂度。

Spring Cloud 体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微软服务架构中不可或缺的一部分,提供动态路由,监控,弹性,安全等边缘服务。

Zuul是Netflix出品的一个基于JVM路由的服务端的负载均衡。

他的具体作用就是服务转发,接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口,同时也可以在网关做一些权限校验等类似的功能。

链路跟踪

随着服务数量越来越多,对调用链的分析会越来越复杂,如服务之间的调用关系,某个请求对应的调用链,调用之间消费的时间等,对这些信息进行监控就成了问题

在实际的使用中,我们需要监控服务和服务之间通讯的各项指标,这些数据将是我们改进系统架构的主要依据。

因此分布式的链路跟踪就变的非常重要,Spring Cloud也给出了具体的解决方案:Spring Cloud Sleuth和Zipkin。

Spring Cloud Sleuth 为服务之间调用提供链路跟踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长时间。从而让我们可以很方便的理清各个微服务之间的调用关系。

Zipkin 是 Twitter 的一个开源项目,允许开发者收集Twitter各个服务上的监控数据,并提供查询接口

总结

我们从整体上来看一下Spring Cloud各个组件如何来配套使用

  • Eureka 负责服务的注册与发现,很好地将各服务连接起来。

  • Hystrix 负责监控服务之间的调用情况,连续多次失败进行熔断保护。

  • Hystrix dashboard,Turbine 负责监控 Hystrix 的熔断情况,并给予图形化的展示。

  • Spring Cloud Config 提供了统一的配置中心服务。

  • 当配置文件发生变化的时候,Spring Cloud Bus 负责通知各服务去获取最新的配置信息。

  • 所有对外的请求和服务,我们都通过Zuul来进行转发,起到 API 网关的作用。

  • 最后我们使用 Sleuth+Zipkin 将所有的请求数据记录下来,方便我们进行后续分析。

你可能感兴趣的:(大数据)