一站式微服务解决方案-SpringCloud微服务（上）

微服务架构可以说是SOA架构的⼀种拓展，这种架构模式下它拆分粒度更⼩、服务更独⽴。把应⽤拆分成为⼀个个微⼩的服务，不同的服务可以使⽤不同的开发语⾔和存储，服务之间往往通过Restful等轻量级通信。微服务架构关键在于微⼩、独⽴、轻量级通信。

微服务是在 SOA 上做的升华粒度更加细致，微服务架构强调的⼀个重点是“业务需要彻底的组件化和服务化”。

微服务架构的优点: 微服务架构和微服务
1、微服务很⼩，便于特定业务功能的聚焦 A B C D
2、微服务很⼩，每个微服务都可以被⼀个⼩团队单独实施（开发、测试、部署上线、运维），团队合作⼀定程度解耦，便于实施敏捷开发
3、微服务很⼩，便于重⽤和模块之间的组装
4、微服务很独⽴，那么不同的微服务可以使⽤不同的语⾔开发，松耦合
5、微服务架构下，我们更容易引⼊新技术
6、微服务架构下，我们可以更好的实现DevOps开发运维⼀体化；
微服务架构的缺点
1、微服务架构下，分布式复杂难以管理，当服务数量增加，管理将越加复杂；
2、微服务架构下，分布式链路跟踪难等；

Spring Cloud 是什么？

[百度百科] Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等，都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。Spring Cloud并没有重复制造轮⼦，它只是将⽬前各家公司开发的⽐较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot⻛格进⾏再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了⼀套简单易懂、易部署和易维护的分布式系统开发⼯具包。

Spring Cloud 解决什么问题

Spring Cloud 规范及实现意图要解决的问题其实就是微服务架构实施过程中存在的⼀些问题，⽐如微服务架构中的服务注册发现问题、⽹络问题（⽐如熔断场景）、统⼀认证安全授权问题、负载均衡问题、链路追踪等问题。

Spring Cloud 架构

Spring Cloud是⼀个微服务相关规范，这个规范意图为搭建微服务架构提供⼀站式服务，采⽤组件（框架）化机制定义⼀系列组件，各类组件针对性的处理微服务中的特定问题，这些组件共同来构成Spring Cloud微服务技术栈。

Spring Cloud 核⼼组件
Spring Cloud ⽣态圈中的组件，按照发展可以分为第⼀代 Spring Cloud组件和第⼆代 Spring Cloud组件。

Spring Cloud中的各组件协同⼯作，才能够⽀持⼀个完整的微服务架构。⽐如

• 注册中⼼负责服务的注册与发现，很好将各服务连接起来
• API⽹关负责转发所有外来的请求
• 断路器负责监控服务之间的调⽤情况，连续多次失败进⾏熔断保护。
• 配置中⼼提供了统⼀的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息

Spring Cloud 与 Dubbo 对⽐

Dubbo是阿⾥巴巴公司开源的⼀个⾼性能优秀的服务框架，基于RPC调⽤，对于⽬前使⽤率较⾼的Spring Cloud Netflix来说，它是基于HTTP的，所以效率上没有Dubbo⾼，但问题在于Dubbo体系的组件不全，不能够提供⼀站式解决⽅案，⽐如服务注册与发现需要借助于Zookeeper等实现，⽽Spring Cloud Netflix则是真正的提供了⼀站式服务化解决⽅案，且有Spring⼤家族背景。
前些年，Dubbo使⽤率⾼于SpringCloud，但⽬前Spring Cloud在服务化/微服务解决⽅案中已经有了⾮常好的发展趋势。

Spring Cloud 与 Spring Boot 的关系
Spring Cloud 只是利⽤了Spring Boot 的特点，让我们能够快速的实现微服务组件开发，否则不使⽤Spring Boot的话，我们在使⽤Spring Cloud时，每⼀个组件的相关Jar包都需要我们⾃⼰导⼊配置以及需要开发⼈员考虑兼容性等各种情况。所以Spring Boot是我们快速把Spring Cloud微服务技术应⽤起来的⼀种⽅式。

第⼀代 Spring Cloud 核⼼组件

1 Eureka服务注册中⼼
工作原理图：

分布式微服务架构中，服务注册中⼼⽤于存储服务提供者地址信息、服务发布相关的属性信息，消费者通过主动查询和被动通知的⽅式获取服务提供者的地址信息，⽽不再需要通过硬编码⽅式得到提供者的地址信息。消费者只需要知道当前系统发布了那些服务，⽽不需要知道服务具体存在于什么位置，这就是透明化路由。
1）服务提供者启动
2）服务提供者将相关服务信息主动注册到注册中⼼
3）服务消费者获取服务注册信息：
pull模式：服务消费者可以主动拉取可⽤的服务提供者清单
push模式：服务消费者订阅服务（当服务提供者有变化时，注册中⼼也会主动推送
更新后的服务清单给消费者
4）服务消费者直接调⽤服务提供者
另外，注册中⼼也需要完成服务提供者的健康监控，当发现服务提供者失效时需要
及时剔除；

交互流程和原理图：

2 Ribbon负载均衡
负载均衡⼀般分为服务器端负载均衡和客户端负载均衡。
所谓服务器端负载均衡，⽐如Nginx、F5这些，请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。
所谓客户端负载均衡，⽐如我们要说的Ribbon，服务消费者客户端会有⼀个服务器地址列表，调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问，负载均衡算法的执⾏是在请求客户端进⾏。
Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤，Ribbon利⽤从Eureka中读取到服务信息，在调⽤服务提供者提供的服务时，会根据⼀定的算法进⾏负载。
@LoadBalanced 通过添加注解即可。

3 Hystrix熔断器
Hystrix主要通过以下⼏点实现延迟和容错。

• 包裹请求：使⽤HystrixCommand包裹对依赖的调⽤逻辑。 ⾃动投递微服务⽅法（@HystrixCommand 添加Hystrix控制） ——调⽤简历微服务
• 跳闸机制：当某服务的错误率超过⼀定的阈值时，Hystrix可以跳闸，停⽌请求该服务⼀段时间。
• 资源隔离：Hystrix为每个依赖都维护了⼀个⼩型的线程池(舱壁模式)（或者信号量）。如果该线程池已满， 发往该依赖的请求就被⽴即拒绝，⽽不是排队等待，从⽽加速失败判定。
• 监控：Hystrix可以近乎实时地监控运⾏指标和配置的变化，例如成功、失败、超时、以及被拒绝 的请求等。
• 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执⾏回退逻辑。回退逻辑由开发⼈员 ⾃⾏提供，例如返回⼀个缺省值。
• ⾃我修复：断路器打开⼀段时间后，会⾃动进⼊“半开”状态。

Hystrix⼯作流程

4 Feign远程调⽤组件

Feign是Netflix开发的⼀个轻量级RESTful的HTTP服务客户端（⽤它来发起请求，远程调⽤的），是以Java接⼝注解的⽅式调⽤Http请求，⽽不⽤像Java中通过封装HTTP请求报⽂的⽅式直接调⽤，Feign被⼴泛应⽤在Spring Cloud 的解决⽅案中。类似于Dubbo，服务消费者拿到服务提供者的接⼝，然后像调⽤本地接⼝⽅法⼀样去调⽤，实际发出的是远程的请求。

• Feign可帮助我们更加便捷，优雅的调⽤HTTP API：不需要我们去拼接url然后调⽤restTemplate的api，在SpringCloud中，使⽤Feign⾮常简单，创建⼀个接⼝（在消费者–服务调⽤⽅这⼀端），并在接⼝上添加⼀些注解，代码就完成了
• SpringCloud对Feign进⾏了增强，使Feign⽀持了SpringMVC注解（OpenFeign）

本质：封装了Http调⽤流程，更符合⾯向接⼝化的编程习惯，类似于Dubbo的服务调⽤

5 GateWay⽹关组件

⽹关在架构中的位置
Spring Cloud GateWay天⽣就是异步⾮阻塞的，基于Reactor模型⼀个请求—>⽹关根据⼀定的条件匹配—匹配成功之后可以将请求转发到指定的服务地址；⽽在这个过程中，我们可以进⾏⼀些⽐较具体的控制（限流、⽇志、⿊⽩名单）

• 路由（route）： ⽹关最基础的部分，也是⽹关⽐较基础的⼯作单元。路由由⼀个ID、⼀个⽬标URL（最终路由到的地址）、⼀系列的断⾔（匹配条件判断）和Filter过滤器（精细化控制）组成。如果断⾔为true，则匹配该路由。
• 断⾔（predicates）：参考了Java8中的断⾔java.util.function.Predicate，开发⼈员可以匹配Http请求中的所有内容（包括请求头、请求参数等）（类似于nginx中的location匹配⼀样），如果断⾔与请求相匹配则路由。
• 过滤器（filter）：⼀个标准的Spring webFilter，使⽤过滤器，可以在请求之前或者之后执⾏业务逻辑。

GateWay⼯作过程

GateWay核⼼逻辑：路由转发+执⾏过滤器链

6 Spring Cloud Config 分布式配置中⼼

Spring Cloud Config是⼀个分布式配置管理⽅案，包含了 Server端和 Client端两个部分。

• Server 端：提供配置⽂件的存储、以接⼝的形式将配置⽂件的内容提供出去，通过使⽤@EnableConfigServer注解在 Spring boot 应⽤中⾮常简单的嵌⼊
• Client 端：通过接⼝获取配置数据并初始化⾃⼰的应⽤

7 Spring Cloud Stream消息驱动组件

Spring Cloud Stream 消息驱动组件帮助我们更快速，更⽅便，更友好的去构建消息驱动微服务的。

当时定时任务和消息驱动的⼀个对⽐。（消息驱动：基于消息机制做⼀些事情）
MQ：消息队列/消息中间件/消息代理，产品有很多，ActiveMQ RabbitMQ RocketMQ Kafka

Stream解决的痛点问题：

MQ消息中间件⼴泛应⽤在应⽤解耦合、异步消息处理、流量削峰等场景中。

不同的MQ消息中间件内部机制包括使⽤⽅式都会有所不同，⽐如RabbitMQ中有Exchange（交换机/交换器）这⼀概念，kafka有Topic、Partition分区这些概念，MQ消息中间件的差异性不利于我们上层的开发应⽤，当我们的系统希望从原有的RabbitMQ切换到Kafka时，我们会发现⽐较困难，很多要操作可能重来（因为应⽤程序和具体的某⼀款MQ消息中间件耦合在⼀起了）。
Spring Cloud Stream进⾏了很好的上层抽象，可以让我们与具体消息中间件解耦合，屏蔽掉了底层具体MQ消息中间件的细节差异，就像Hibernate屏蔽掉了具体数据库（Mysql/Oracle⼀样）。如此⼀来，我们学习、开发、维护MQ都会变得轻松。⽬前Spring Cloud Stream⽀持RabbitMQ和Kafka。

本质：屏蔽掉了底层不同MQ消息中间件之间的差异，统⼀了MQ的编程模型，降低了学习、开发、维护MQ的成本

传统MQ模型与Stream消息驱动模型