Spring Cloud 技术栈简介

前置概念：微服务
本质：一种架构模式 / 一种架构风格
内容：提倡将单一应用程序划分成一组小的服务，进程独立，业务协调
缘由：解耦
实现：Spring Cloud, Dubbo 等

前置概念：落地维度
本质：架构实现细节的考虑
内容：1 服务治理 2 服务注册 3 服务调用 4 负载均衡 5 服务监控

前置概念： CAP理论
本质：分布式系统的特性
内容：Consistency 一致性，Availability 可用性， Partition Tolerance 分区容错性

落地实现的可选技术：

服务开发：Spring Boot & Spring MVC
服务的配置与管理： Netfix 公司的 Archaius，阿里的 Diamond 等
服务的注册与发现组件： Eureka, Consul, Zookeeper 等
服务间调用方式：Rest, GRPC, RPC
服务间调用组件： Feign, RestTemplate + Ribbon
服务熔断器：Hystrix, Envoy 等
负载均衡：Ribbon, Nginx
消息队列：Kafka, RabbitMQ, ActiveMQ 等
服务配置中心管理：Spring Cloud Config, Chef 等
服务路由(API网关)：Zuul 等
服务监控：Zabbix, Nagios, Metrics, Spectator 等
全链路追踪：Zipkin, Brave, Dapper 等
服务部罟：Docker, Open Stack, Kubernetes 等
数据流操作开发包：Spring Cloud Stream
事件消息总线：Spring Cloud Bus

部分常用技术 (每项都可以单独拿出来作长篇大论)：

Spring Boot

可看作 Spring Cloud 的基本组成单元

Spring Boot 三大魔法：

自动配置：自动提供常用应用和组件的相关配置
起步依赖：通过starter和依赖管理解决依赖问题
内嵌容器：由应用启动 Tomcat 而非 Tomcat 启动应用

Eureka

Spring Cloud 首选的服务注册与发现组件

特性：Eureka 遵守 AP (Zookeeper 遵守 CP)，表现在：

各节点平等

自我保护

  - 15 分钟内，85% 节点没有正常心跳，Eurekas就认为客户端与注册中心出现了网络故障

  - Eureka不再从注册列表中移除因长时间没收到心跳而应该过期的服务

  - 够接受新服务的注册和査询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)

  - 网络稳定时,当前实例新的注册信息会被同步到其它节点中

Hystrix

作用：
在高并发场景下,服务的阻塞意味着线程的阻塞,服务器的线程全部阻塞,导致服务器崩溃,由于服务之间的调用关系是同步的,会对整个微服务系统造成服务雪崩,这就需要进行服务熔断和服务降级处理
方式：
相当于保险丝，一旦发生服务雪崩的,就会熔断整个服务,通过维护一个自己的线程池,当线程达到阈值的时候就启动服务降级,如果其他请求继续访问就直接返回fallback的默认值
具体通过隔离服务之间的访问点、停止级联失败和提供回退选项实现

Hystrix 的设计原则

防止任何单个依赖项耗尽所有容器（如Tomcat）用户线程

甩掉包袱，快速失败而不是排队

在任何可行的地方提供回退，以保护用户不受失败的影响

使用隔离技术（如隔离板、泳道和断路器模式）来限制任何一个依赖项的影响

通过近实时的度量、监视和警报来优化发现时间

通过配置的低延迟传播来优化恢复时间

支持对 Hystrix 的大多数方面的动态属性更改，允许使用低延迟反馈循环进行实时操作修改

避免在整个依赖客户端执行中出现故障，而不仅仅是在网络流量中

Hystrix 的实现手段

用一个HystrixCommand 或者 HystrixObservableCommand （这是命令模式的一个例子）包装所有的对外部系统（或者依赖）的调用，典型地它们在一个单独的线程中执行

调用超时时间比你自己定义的阈值要长。有一个默认值，对于大多数的依赖项你是可以自定义超时时间的

为每个依赖项维护一个小的线程池(或信号量)；如果线程池满了，那么该依赖性将会立即拒绝请求，而不是排队

调用的结果有这么几种：成功、失败（客户端抛出异常）、超时、拒绝

在一段时间内，如果服务的错误百分比超过了一个阈值，就会触发一个断路器来停止对特定服务的所有请求，无论是手动的还是自动的

当请求失败、被拒绝、超时或短路时，执行回退逻辑近实时监控指标和配置变化

原则与实现手段摘录自CSDN