Spring Boot
让我们从繁琐的配置文件中解脱了出来,而 Spring Cloud
,它我们提供了一整套的微服务解决方案,大大的降低了微服务开发的门槛,同时也减少了开发成本。
Spring Cloud
并不是特指某个框架,它其实是一系列成熟框架的组合,通过 Spring Boot
风格的封装,屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂、容易部署的分布式系统开发工具包。
我们知道,在微服务开发中,以下的基础设施是很有必要的:
以下是 Spring Cloud
体系所包含的框架示意图:
服务注册与发现是 Spring Cloud
中最核心的组件之一,整个系统中所有的服务都可以注册到注册中心,然后由注册中心进行统一调度,方便后续的水平扩展以及故障转移等。 Spring Cloud
体系中的注册中心有很多的实现方式(参考上图),后续教程会一一介绍。
随着服务的不断增多,同时每个服务也会有多个环境(开发环境、测试环境、生产环境等),每个环境的配置文件又会有所不同,但是其中又有许多配置是可以共用的,如果每个服务自己去管理这些配置,会给维护带来很大的麻烦,这时候,我们就需要引入配置中心去统一管理这些配置。 Spring Cloud
提供了 Spring Cloud Config
来完成这项任务,但是也有社区提供的比较好的实现,如携程提供的 Apollo 。但是,配置更新后怎样通知到具体服务,这又是个问题,所以 Spring Cloud
还提供了 Spring Cloud Bus
组件,来进行服务间的通讯。
既然是微服务架构,那服务间的调用肯定是无法避免的, Spring Cloud
提供了 Ribbon
组件,它可以用来进行服务间的调用,同时,它还支持客户端的负载均衡。但是,直接使用 Ribbon
不是很方便,所以, Spring Cloud
基于 Netflix Feign
,并整合了 Ribbon
,这就有了 Spring Cloud OpenFeign
,它实现了声明式的服务调用客户端,使得编写 web 服务客户端更加方便。
在微服务架构中,通常会有多个服务之间相互调用的情况,一旦某些基础服务出现故障,则可能造成整个系统的不可用,称之为服务雪崩,为了避免这种情况的发生,我们需要在服务出现故障时实现故障隔离和服务降级。针对这种情况, Spring Cloud
使用了 Hystrix
来实现服务的容错。
网关为系统提供了路由、鉴权、监控、负载均衡等功能。 Spring Cloud
为此提供了两个解决方案: Zuul
以及 Spring Cloud Gateway
。
在微服务架构中,服务之间的调用链会随着服务的增多越来越复杂,当我们在排查某些问题以及监控服务间通讯的指标时,服务的追踪就变得非常重要。 Spring Cloud
提供的实现是: Spring Cloud Sleuth
。
因为微服务架构的特性,每个服务都可能依赖其它的服务,而不同的服务可能是由不同的团队去维护的,这样当我们在测试某个服务时,需要将它依赖的服务都部署起来,成本非常大;而如果只是使用单元测试,需要 mock 非常多的数据,而且一旦依赖的服务接口改变了,单纯只通过单元测试是无法感知的。所以有人就提出了 CDC (Consumer-Driver Contracts) 即 消费者驱动契约 的方式来进行测试。 Spring Cloud Contract
就是 CDC
的一种实现。