Spring Cloud学习
2019-12-09 13:20:13 5 举报AI智能生成
登录查看完整内容
值得拥有的一份SpringBoot学习路径-思维导图
作者其他创作
大纲/内容
Spring Cloud
Eureka 注册中心
什么是Eureka
Eureka WIKI
超链接
Eureka是Netflix开源的一个RESTful服务，主要用于服务的注册发现。Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。
吸引力
开源
可以探究原理以及修改代码
可靠
经过Netflix多年的生产环境考验，使用比较省心
功能齐全
不但提供了完整的注册发现服务，还有 Ribbon等配合使用的服务
功能
Register：服务注册
当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。
Renew：服务续约
Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。
Fetch Registries：获取注册列表信息
Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。
Cancel：服务下线
Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容： DiscoveryManager.getInstance().shutdownComponent()；
Eviction：服务剔除
在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。
客户端负载均衡(Ribbon)
背景
微服务之前
对于大型应用系统负载均衡(LB:Load Balancing)是首要被解决一个问题。在微服务之前LB方案主要是集中式负载均衡方案，在服务消费者和服务提供者之间又一个独立的LB，LB通常是专门的硬件，如F5，或者是基于软件的，如VS、HAproxy等。LB上有所有服务的地址映射表，当服务消费者调用某个目标服务时，它先向LB发起请求，由LB以某种策略（比如：Round-Robin）做负载均衡后将请求转发到目标服务。
微服务之后
而微服务的出现，则为LB的实现提供了另外一种思路：把LB的功能以库的方式集成到服务消费方的进程内，而不是由一个集中的设备或服务器提供。这种方案称为软负载均衡（Soft Load Balancing）或者客户端负载均衡。在Spring Cloud中配合Eureka的服务注册功能，Ribbon子项目则为REST客户端实现了负载均衡。
负载策略
RoundRobinRule
轮询策略，Ribbon以轮询的方式选择服务器，这个是默认值。所以示例中所启动的两个服务会被循环访问;
RandomRule
随机选择，也就是说Ribbon会随机从服务器列表中选择一个进行访问;
BestAvailableRule
最大可用策略，即先过滤出故障服务器后，选择一个当前并发请求数最小的;
WeightedResponseTimeRule
带有加权的轮询策略，对各个服务器响应时间进行加权处理，然后在采用轮询的方式来获取相应的服务器;
AvailabilityFilteringRule
可用过滤策略，先过滤出故障的或并发请求大于阈值一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选出一个;
ZoneAvoidanceRule
区域感知策略，先使用主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例清单，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数（默认1）和最小过滤百分比（默认0），最后对满足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。
流程
1、Ribbon首先根据其所在Zone优先选择一个负载较少的Eureka Server;
@Service
在业务逻辑层（Service层）使用
2、定期从Eureka Server更新并过滤服务实例列表;
3、根据指定的负载均衡策略，从可用的服务器列表中选择一个服务实例的地址;
4、然后通过RestClient进行服务调用。
声明式服务调用(Feign)
什么是Feign
Feign是一个声明式的Web Service客户端，它的目的就是让Web Service调用更加简单。Feign提供了HTTP请求的模板，通过编写简单的接口和插入注解，就可以定义好HTTP请求的参数、格式、地址等信息。而Feign则会完全代理HTTP请求，我们只需要像调用方法一样调用它就可以完成服务请求及相关处理。
Feign整合了Ribbon和Hystrix(关于Hystrix我们后面再讲)，可以让我们不再需要显式地使用这两个组件。
Feign特性
可插拔的注解支持，包括Feign注解和JAX-RS注解;
支持可插拔的HTTP编码器和解码器;
支持Hystrix和它的Fallback;
支持Ribbon的负载均衡;
支持HTTP请求和响应的压缩。
遇到的问题
与Swagger集成冲突
微服务容错保护(Hystrix)
我们在实践微服务架构时，通常会将业务拆分成一个个微服务，微服务之间通过网络进行通信，进行互相调用，造成了微服务之间存在依赖关系。我们知道由于网络原因或者自身的原因，服务并不能保证服务的100%可用，如果单个服务出现问题，调用这个服务就会出现网络延迟甚至调用失败，而调用失败又会造成用户刷新页面并再次尝试调用，再加上其它服务调用，从而增加了服务器的负载，导致服务瘫痪，最终甚至会导致整个服务“雪崩”。
什么是Hystrix
Netflix为解决这个问题根据断路器模式创建了一个名为Hystrix的库。“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应（FallBack），而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
Hystrix容错原理简析
请求封装
不论是HystrixCommand还是HystrixObervableCommand从类命名上可以看到Hystrix其实是使用了\"命令模式\"，通过命令模式实现对服务调用操作的封装，将每个命令在一个独立线程中进行执行；
跳闸机制
资源隔离
Hystrix为每一个服务依赖都维护了一个小型线程池，如果该线程池已满，那么发往该服务的请求就会立即被拒绝，而不是排队等候，从而加速服务失败的判定；
服务监控
Hystrix可以近乎实时地监控运行指标和配置的变化，例如对请求的成功、失败、超时以及拒绝等；
回退机制
当请求失败、超时、被拒绝、或当断路器打开时，执行相应的回退逻辑;
自我修复
当断路器打开一段时间后，Hystrix会进入\"半开\"状态，断路器会允许一个请求尝试对服务进行请求，如果该服务可以调用成功，则关闭断路器，否则将继续保持断路器打开。
Hystrix监控
每秒执行的请求数、成功数等
待完善
Hystrix Dashboard
默认集群监控
通过http://turbine-hostname:port/turbine.stream开启，实现对默认集群的监控;
指定集群监控
通过http://turbine-hostname:port/turbine.stream?cluster=[clusterName]开启，实现对指定clusterName集群的监控;
单机应用监控
通过http://hystrix-app:port/hystrix.stream开启，实现对某个服务实例的监控。
API服务网关(Zuul) 上
微服务场景下，每一个微服务对外暴露了一组细粒度的服务。客户端的请求可能会涉及到一串的服务调用，如果将这些微服务都暴露给客户端，那么客户端需要多次请求不同的微服务才能完成一次业务处理，增加客户端的代码复杂度。另外，对于微服务我们可能还需要服务调用进行统一的认证和校验等等。微服务架构虽然可以将我们的开发单元拆分的更细，降低了开发难度，但是如果不能够有效的处理上面提到的问题，可能会造成微服务架构实施的失败。
什么是Zuul
Zuul参考GOF设计模式中的Facade模式，将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，那么整个服务只需要暴露一个api，对外屏蔽了服务端的实现细节，也减少了客户端与服务器的网络调用次数。这就是API服务网关(API Gateway)服务。我们可以把API服务网关理解为介于客户端和服务器端的中间层，所有的外部请求都会先经过API服务网关。因此，API服务网关几乎成为实施微服务架构时必须选择的一环。Spring Cloud Netflix的Zuul组件可以做反向代理的功能，通过路由寻址将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。
动态路由
监控和审查
身份认证与安全
压力测试
逐渐增加某一个服务集群的流量，以了解服务性能;
金丝雀测试
服务迁移
负载剪裁
为每一个负载类型分配对应的容量，对超过限定值的请求弃用;
静态应答处理
Zuul 过滤器
Type: 定义在请求执行过程中何时被执行;
Execution Order: 当存在多个过滤器时，用来指示执行的顺序，值越小就会越早执行;
Criteria: 执行的条件，即该过滤器何时会被触发;
Action: 具体的动作。
过滤器之间并不会直接进行通信，而是通过RequestContext来共享信息，RequestContext是线程安全的。
分布式链路跟踪(Sleuth)
当我们进行微服务架构开发时，通常会根据业务来划分微服务，各业务之间通过REST进行调用。一个用户操作，可能需要很多微服务的协同才能完成，如果在业务调用链路上任何一个微服务出现问题或者网络超时，都会导致功能失败。随着业务越来越多，对于微服务之间的调用链的分析会越来越复杂。
什么是Sleuth
Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。
耗时分析
通过Sleuth可以很方便的了解到每个采样请求的耗时，从而分析出哪些服务调用比较耗时;
可视化错误
对于程序未捕捉的异常，可以通过集成Zipkin服务界面上看到;
链路优化
对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。
整合Zipkin服务
简介
Zipkin是一个致力于收集分布式服务的时间数据的分布式跟踪系统。
功能组件
collector
数据采集
storage
数据存储
search
数据查询
UI
数据展示
采样率
在生成环境中，由于业务量比较大，所产生的跟踪数据可能会非常大，如果全部采集一是对业务有一定影响，二是对存储压力也会比较大，所以采样变的很重要。一般来说，我们也不需要把每一个发生的动作都进行记录。
统一配置中心(Config)
对于配置的重要性，我想我不用进行任何强调，大家都可以明白其重要性。在普通单体应用，我们常使用配置文件(application(*).properties(yml))管理应用的所有配置。这些配置文件在单体应用中非常胜任其角色，并没有让我们感觉到有头疼的地方。但随着微服务框架的引入，微服务数量就会在我们产品中不断增加，之前我们重点考虑的是系统的可伸缩、可扩展性好，但随之就是配置管理的问题就会一一暴露出来。起初微服务器各自管各自的配置，在开发阶段并没什么问题，但到了生产环境管理就会很头疼，如果要大规模更新某项配置，困难就可想而知。
简述
在分布式系统中，Spring Cloud提供一个Config子项目，该项目核心就是配置中心，通过一个服务端和多个客户端实现配置服务。我们可使用配置服务器集中的管理所有服务的各种环境配置文件。配置服务中心默认采用Git的方式进行存储，因此我们很容易部署修改，并可以对环境配置进行版本管理。Spring Cloud Config具有中心化、版本控制、支持动态更新和语言独立等特性。
特点
提供服务端和客户端支持(Spring Cloud Config Server和Spring Cloud Config Client);
集中式管理分布式环境下的应用配置;
基于Spring环境，实现了与Spring应用无缝集成;
可用于任何语言开发的程序;
默认实现基于Git仓库(也支持SVN)，从而可以进行配置的版本管理;
配置中心的服务端承担的作用
拉取配置时更新Git仓库副本，保证是配置为最新;
支持从yml、json、properties等文件加载配置;
配合Eureke可实现服务发现，配合Cloud Bus(这个后面我们在详细说明)可实现配置推送更新;
默认配置存储基于Git仓库(可以切换为SVN)，从而支持配置的版本管理.
Spring项目配置加载顺序
这里是列表文本命令行参数
SPRING_APPLICATION_JSON 参数
从java:comp/env 加载 JNDI 属性
Java系统属性 （System.getProperties()）
操作系统环境变量
如果有使用 random.* 属性配置，则使用 RandomValuePropertySource 产生
外部特定应用配置文件 例如：application-{profile}.properties 或者 YAML variants
内部特定应用配置文件 例如：application-{profile}.properties 或者 YAML variants
外部应用配置文件 例如：application.properties 或者 YAML variants
内部应用配置文件 例如：application.properties 或者 YAML variants
加载@Configuration类的 @PropertySource 或者 @ConfigurationProperties 指向的配置文件
默认配置，通过SpringApplication.setDefaultProperties 设置
Config Client从Config Server中获取配置数据的流程
Config Client启动时，根据bootstrap.properties中配置的应用名称(application)、环境名(profile)和分支名(label)，向Config Server请求获取配置数据;
Config Server根据Config Client的请求及配置，从Git仓库(这里以Git为例)中查找符合的配置文件;
Config Server将匹配到的Git仓库拉取到本地，并建立本地缓存;
Config Server创建Spring的ApplicationContext实例，并根据拉取的配置文件，填充配置信息，然后将该配置信息返回给Config Client;
Config Client获取到Config Server返回的配置数据后，将这些配置数据加载到自己的上下文中。同时，因为这些配置数据的优先级高于本地Jar包中的配置，因此将不再加载本地的配置。
基于消息驱动开发(Stream)
基于消息驱动的开发几乎成了微服务架构下必备开发方式之一。这是因为，第一原来传统单体架构开发中的接口调用开发已经在微服务架构下不存在；第二微服务架构的开发要求降低各微服务直接的依赖耦合，一旦我们在某个微服务中直接调用另外一个微服务，那么这两个微服务就会通过依赖产生了强耦合；第三微服务的自治原则也强烈要求各微服务之间不能够互相调用。因此，在微服务架构开发中基于消息驱动的开发成为了一种必然趋势。
场景
Mall-Web微服务要求能够实现自治，尽量降低对商品微服务（Procuct-Service）的依赖;
Mall-Web微服务为了能够保障服务的效率，开发小组决定对商品数据进行缓存，这样只需要第一次加载的时候远程调用商品微服务，当用户下次在请求该商品的时候就可以从缓存中获取，从而提升了服务效率（至于使用内存方式还是Redis来实现缓存，这个由你决定）。
消息总线(Bus)
科普
ESB(Enterprise Service Bus)
企业服务总线（Enterprise Service Bus，ESB）的概念是從服務導向架構(Service Oriented Architecture， SOA)發展而來。SOA描述了一种IT基础设施的应用集成模型；其中的软构件集是以一种定义清晰的层次化结构来相互耦合。一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。
在企业计算领域，企业服务总线是指由中间件基础设施产品技术实现的、 通过事件驱动和基于XML消息引擎，为更复杂的面向服务的架构提供的软件架构的构造物。企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。
企业服务总线提供可靠消息传输，服务接入，协议转换，数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置，协议和数据格式。
企业服务总线通常在企业消息系统上提供一个抽象层，使得集成架构师能够不用编码而是利用消息的价值完成集成工作。 通俗一点来讲就是企业服务总线是架构在消息中间件之上的另外一个抽象层，使得我们可以不用关心消息相关的处理就可以完成业务逻辑的处理。
Spring的时间机制
观察者/消费者模式
好处
应用模块之间的解耦
对同一种事件可以根据需要定义多种处理方式
对主线应用不干扰，是一个极佳的开闭原则(OCP)实践
特性
基于版本的分布式配置管理
服务注册与发现
路由
服务之间调用（依赖）
负载均衡
断路器
全局锁（分布式锁）
选主以及集群状态管理
分布式消息服务
中文社区
https://springcloud.cc/
收藏
0 条评论
回复 删除
下一页
