快速了解SpringCloud

爱看话本的狐狸
22 阅读7分钟

什么是SpringCloud

【SpringCloud官网】spring.io/cloud

它是一套管理多个微服务架构的解决方案，它依赖于SpringBoot，简单通俗的说就是用来管理多个微服务一起运行的模式，协调各个微服务之间的运行、服务发现、事件等等。它不是具体的框架，是一种管理手段——管理微服务的。

SpringBoot可以离开SpringCloud独立使用，开发项目，但SpringCloud离不开SpringBoot，属于依赖关系；

SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局的服务治理框架；

它解决的问题

  • 服务很多，客户端怎么访问
  • 这么多服务，服务之间怎么通信
  • 这么多服务，如何治理
  • 服务挂了，怎么办

服务间的耦合

随着单个微服务的增加(服务A调用服务B，服务B调用服务C和服务D……)服务和服务之间的调用关系就会越来越复杂，且随着服务化组件的不断增多，服务之间的调用关系在后期会成指数级别的增长。

最终导致——牵一发而动全身。经常出现由于某个服务更新而没有通知到其它服务，导致上线后惨案频发。

为了解决它，SpringCloud将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka以及后来的nacos都是解决该类问题的，他们实现了服务的注册与发现。

繁多的配置

每个微服务都有自己对应的配置文件。随着微服务不断的增多，配置文件也会越来越多，再加上在研发过程中有测试环境、预发布环境、生产环境等，配置文件的数量便是n*m。如此多的配置文件，如果要修改某个公共配置，一不小心就会产生混乱。这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。

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

与客户端的调用

微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会很麻烦且存在诸多问题：向每个独立服务都发起一个请求，会大大增加服务之间通信的复杂度跟开销、多次调用容易受到攻击、容易受到故障和服务中断的影响、且服务之间的扩展性会非常差...

为解决它，因此简化了前端的调用逻辑，引入API Gateway作为服务网关，它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。同时也可以在网关做一些权限校验等类似的功能。客户端访问时就变成了如下的情况：

  1. 用户发起请求：用户通过浏览器或其他客户端发起请求
  2. API Gateway接收到请求后，会进行一些预处理（如检查请求的合法性、进行身份验证和授权等）
  3. API Gateway将处理后的请求转发到具体的微服务，它们进行处理
  4. 服务执行完业务逻辑后，会将结果返回给API Gateway
  5. API Gateway接收到结果后，会将结果返回给用户

在SpringCloud中网关的实现有两种——Zuul和Gateway。

Zuul是基于Servlet实现的，属于阻塞式编程。

而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具有更好的性能！

服务间的治理

面向不同业务域的微服务越来越多，微服务集群的规模增长迅速。之前只需要对单体应用进行监控管理的情况，现在则要面对的是几十甚至上百个微服务的监控管理，同时为了避免单个服务出现过载的情况，提高系统的可靠性跟稳定性。因此需要升级服务监控功能，同时进行负载均衡，进行所谓的服务间的治理。

它调用提供链路追踪。例如可以通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。而使用Ribbon则能够轻松实现微服务之间调用的负载均衡。

服务的崩溃

微服务架构中通常会有多个服务层之间的相互调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，该现象可以称为服务雪崩或者叫雪崩效应。再加上网络是不可靠的，便让这种情况的出现几率更大了。

为了减低它的几率，SpringCloud提供了服务-故障隔离功能。也就是所谓的熔断机制——当微服务系统的某个微服务不可用或响应时间太长时,为了保护系统的服务整体可用性,熔断器会暂时切断对该服务的请求调用,并快速返回一个友好的错误响应信息。这种熔断状态不是永久的,在经历了一定时间后,熔断器会再次检测该微服务是否恢复正常,若恢复正常则恢复调用链路。

其中Hystrix以及后来的Sentinel就是所谓的熔断降级组件。

它能做什么

  • Distributed/versioned configuration 分布式/版本控制配置
  • Service registration and discovery 服务注册与发现
  • Routing 路由
  • Service-to-service calls 服务到服务的调用
  • Load balancing 负载均衡配置
  • Circuit Breakers 断路器
  • Distributed messaging 分布式消息管理
  • ....

一句话：将多个微服务整合起来，运行大型且复杂的项目

它的优缺点

优点

  • 单一职责原则；
  • 每个服务足够内聚，足够小，代码容易理解，这样能聚焦一个指定的业务功能或业务需求；
  • 开发简单，开发效率高，一个服务可能就是专一的只干一件事；
  • 微服务能够被小团队单独开发，这个团队只需2-5个开发人员组成；
  • 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的；
  • 微服务能使用不同的语言开发；
  • 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins，Hudson，bamboo；
  • 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值；
  • 微服务允许利用和融合最新技术；
  • 微服务只是业务逻辑的代码，不会和HTML，CSS，或其他的界面混合;
  • 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库；

缺点

  • 开发人员要处理分布式系统的复杂性；
  • 多服务运维难度，随着服务的增加，运维的压力也在增大；
  • 系统部署依赖问题；
  • 服务间通信成本问题；
  • 数据一致性问题；
  • 系统集成测试问题；
  • 性能和监控问题；

五大组件

  • 服务注册与发现——Netflix Eureka

  • 分布式配置——Spring Cloud Config

  • 服务网关——Netflix Zuul

  • 负载均衡：

    • 客户端负载均衡——Netflix Ribbon
    • 服务端负载均衡：——Feign(其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service 接口)

  • 断路器——Netflix Hystrix

自学参考资料

avatar
文章
阅读
粉丝