SpringCloud系列：1.认识SpringCloud

一、微服务

微服务（Microservice Architecture）是近几年流行的一种架构思想，它将单个应用程序作为一套小型服务进行开发。每个应用程序（服务）可被独立部署，他们都在自己的进程中运行，并使用轻量级机制（通常是HTTP资源API）进行通信。

随着互联网的发展，单体服务渐渐无法满足企业庞大复杂业务的需求，于是诞生了微服务，微服务很好的填补了单体服务的不足，其明显的特点就是可独立部署，方便灵活扩展，同时做到了服务解耦，资源的有效隔离。

独立部署，灵活扩展

传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。下图中左边是单体架构的集群，右边是微服务集群。

资源的有效隔离

微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。

当然，微服务也存在一些缺点，例如由于服务的拆分，项目数量的增多，增加了开发和测试的复杂度，另外，服务的拆分也是一大难题，糟糕的拆分会使的不同服务间关系错综复杂，会使得开发和维护变得更加艰难，此外，微服务随着分布式的引入，事务一致性，异步补偿机制、日志监控等对于项目组来说都是一项新的挑战。

目前主流的微服务框架：Dubbo、 SpringCloud、thrift、Hessian等，而SpringCloud作为Spring以核心的微服务框架，开箱即用，方便简洁，越来越受到企业和开发者的关注。

二、Spring Cloud

springCloud是基于SpringBoot的一整套微服务框架。他提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。

由于SpringBoot旨在简化创建产品级的 Spring 应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，约定优于配置，使得微服务的开发变得简单而清晰。

SpringCloud服务治理

服务治理是Spring Cloud的核心，在实现上其提供了两个选择，即Consul和Netflix的Eureka。Eureka本身是Netflix开源的服务治理产品，SpringCloud对其进行二次封装，形成了Spring Netflix子项目。Eureka提供了服务注册中心，服务发现客户端以及注册服务的UI界面。在Eureka的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机，Eureka客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。

SpringCloud客户端负载均衡

Spring Cloud通过对Netflix微服务开源项目中的Ribbon再次封装，实现了客户端负载均衡。Ribbon默认与Eureak进行无缝整合，当客户端启动的时候，从Eureka服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时，Ribbon就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。

此外，通常在微服务调用时通过RestTemplate进行调用，这时需要开发者处理参数、调用路径等，Spring Cloud通过集成Netflix的Feign项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认Feign项目集成了Ribbon，使得声明式调用也支持客户端负载均衡功能。

SpringCloud服务容错和降级

微服务容错、降级旨在为微服务架构提供更大的弹性，在Spring Cloud中，将再一次拥抱Netflix，通过集成其下子项目Hystrix，通过所提供的@HystrixCommand注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外，Hystrix也默认集成到Feign子项目中。

Hystrix是根据“断路器”模式而创建。当Hystrix监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（fallback），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。

而Hystrix的仪表盘项目（Dashboard）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。

SpringCloud服务网关

Spring Cloud通过集成Netflix中的Zuul实现API服务网关功能，提供对请求的路由和过滤两个功能，其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。通过Zuul，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个API接口，屏蔽了服务端的实现细节。通过Zuul的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。

此外，Zuul默认会与Eureka服务器进行整合，自动从Eureka服务器中获取所有注册的服务并进行路由映射，实现API服务网关自动配置。

Spring Cloud与分布式配置中心

针对微服务架构下的配置文件管理需求，Spring Cloud提供了一个Config子项目。Spring Cloud Config具有中心化、版本控制、支持动态更新和语言独立等特性。在Config子项目中将微服务应用分为两种角色：配置服务器（Config Server）和配置客户端（Config Client）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到Git、SVN等具有版本管理仓库中，也可以存放在文件系统中。默认采用Git的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。

SpringCloud消息中间件

现代应用中对消息中间件的依赖也越来越重，开发时很多应用功能常借助消息方式来完成。Kafka和RabbitMQ等消息中间件也逐渐成为开发者应用中的一部分，使用这些中间件进行消息的收发处理是一件非常烦琐的事情，更别说在生产环境下更换消息中间件了。Spring Cloud为简化基于消息的开发，提供了Stream子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与Kafka和RabbitMQ等消息中间件进行集成。

此外，Spring Cloud Bus基于Stream进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。比如Spring Cloud Config借助Bus，可以实现配置的动态刷新处理。

Spring Cloud与微服务链路追踪

Spring Cloud中的Sleuth子项目为开发者提供了微服务之间调用的链路追踪。Sleuth核心思想就是通过一个全局的ID将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。因此，通过Sleuth可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。

三、为何选择Spring Cloud

Spring Cloud作为Spring Boot的传承，遵循约定优于配置的原则，在使用时不需要复杂的配置就可以运行起来，开箱即用，采用自动化配置机制，学习容易，使用简单。

Spring Cloud属于Spring大家族，而Spring是进行企业级开发的首选框架，因此在项目中引入Spring Cloud的技术成本比较低。

Spring Cloud抛弃了传统的RPC通信，采用了基于HTTP的REST方式，使得微服务接口更为灵活，服务提供者和消费者之间的依赖只需要一纸契约即可，而不存在代码级别的强依赖，这对快速演化的微服务架构更合适。

Spring Cloud并没有限制所使用的环境，可以与异构系统进行整合。同时对于所提供的各组件服务既可单独部署，又可集中部署，方便了运维和管理。