手机算命网站建设,网站开发的平台,珠海网站建设策划,承德项目网前言
什么是微服务#xff1f;
微服务是一种面向服务的架构(SOA)风格#xff0c;其中#xff0c;应用程序被构建为多个不同的小型服务的集合而不是单个应用程序。与单个程序不同的是#xff0c;微服务让你可以同时运行多个独立的应用程序#xff0c;而这些独立的应用…前言
什么是微服务
微服务是一种面向服务的架构(SOA)风格其中应用程序被构建为多个不同的小型服务的集合而不是单个应用程序。与单个程序不同的是微服务让你可以同时运行多个独立的应用程序而这些独立的应用程序可以使用不同的编码或编程语言来创建。庞大而又复杂的应用程序可以由多个可自行执行的简单而又独立的程序所组成。这些较小的程序组合在一起可以提供庞大的单程序所具备的所有功能。
什么是分布式服务
分布式结构就是将一个完整的系统按照业务功能拆分成一个个独立的子系统在分布式结构中每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中它们之间通过RPC方式通信。
分布式服务与微服务的区别
1微服务的各个服务都是独立的组件存在。
2独立的组件形式方便模块改造优化或集群部署部署用于应对高并发。
3系统之间的耦合度降低非常容易扩展。
4复用性强。
介绍
Spring Cloud是一个基于Spring Boot实现的云应用开发工具也是微服务系统架构的一站式解决方案。它为基于JVM的云应用开发中的服务发现注册 、配置中心 、消息总线 、负载均衡 、断路器 、数据监控 等操作提供了一种简单的开发方式。通俗地讲Spring Cloud 就是用于构建微服务开发和治理的框架集合。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HMAx7fmZ-1684303939304)(/Users/zhaoyanhong/Library/Application Support/typora-user-images/image-20220906153940245.png)]
微服务的特征
1微服务单元按照数据结构特性或者领域来划分
2微服务通过HTTP来通讯数据格式为json或者xml。
3微服务的数据库相对独立
4微服务的自动化部署。可使用jenkins、Docker、Kubernetes
5服务集中管理。Eureka、Zookeeper、Consul、Nacos、Etcd服务注册发现组件
6分布式架构集群部署。
7熔断机制/防止雪崩。Hystrix
8链路跟踪。Sleuth 、Skywalking
9完整的安全机制。用户验证、权限验证、资源保护等
10完整的实时日志。
Zookeeper/Eureka/nacos服务注册与发现
**服务注册中心本质上是为了解耦服务提供者和服务消费者。**对于任何一个微服务原则上都应存在或者支持多个提供者这是由微服务的分布式属性决定的。更进一步为了支持弹性扩缩容特性一个微服务的提供者的数量和分布往往是动态变化的也是无法预先确定的。因此原本在单体应用阶段常用的静态LB机制就不再适用了需要引入额外的组件来管理微服务提供者的注册与发现而这个组件就是服务注册中心。
服务注册需要具备的能力
服务提供者把自己的协议地址注册到Nacos server服务消费者需要从Nacos Server上去查询服务提供者的地址根据服务名称Nacos Server需要感知到服务提供者的上下线的变化服务消费者需要动态感知到Nacos Server端服务地址的变化 Zookeeper
Zookeeper 是分布式应用程序协调服务, 用于维护配置信息、命名、提供分布式同步和提供组服务。客户端注册是服务自身要负责注册与注销的工作。**当服务启动后向注册中心注册自身当服务下线时注销自己期间还需要和注册中心保持心跳。**心跳不一定要客户端来做也可以由注册中心负责这个过程叫探活。这种方式的缺点是注册工作与服务耦合在一起不同语言都要实现一套注册逻辑。
Zookeeper数据模型的结构类似文件系统。
Zookeeper提供了什么服务
1文件系统
每个子目录项如 NameService 都被称作为znode和文件系统一样我们能够自由的增加、删除znode在一个znode下增加、删除子znode唯一的不同在于znode是可以存储数据的。 有四种类型的znode 1、PERSISTENT-持久化目录节点 客户端与zookeeper断开连接后该节点依旧存在 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点 客户端与zookeeper断开连接后该节点依旧存在只是Zookeeper给该节点名称进行顺序编号 3、EPHEMERAL-临时目录节点 客户端与zookeeper断开连接后该节点被删除 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点 客户端与zookeeper断开连接后该节点被删除只是Zookeeper给该节点名称进行顺序编号
2通知机制。
客户端注册监听它关心的目录节点当目录节点发生变化数据改变、被删除、子目录节点增加删除时zookeeper会通知客户端。
功能特性
1.命名服务 2.配置管理 3.集群管理 4.分布式锁 5.队列管理
命名服务
在zookeeper的文件系统里创建一个目录即有唯一的path。在我们使用tborg无法确定上游程序的部署机器时即可与下游程序约定好path通过path即能互相探索发现。
配置管理
服务配置通常变动大利用zookeeper特性保存在 Zookeeper 的某个目录节点中然后所有相关应用程序对这个目录节点进行监听一旦配置信息发生变化每个应用程序就会收到 Zookeeper 的通知然后从 Zookeeper 获取新的配置信息应用到系统无需代码变更。
Zookeeper集群管理
Zookeeper内部可以组成集群。一个Zookeeper集群通常由一组机器构成组成Zookeeper集群的而每台机器都会在内存中维护当前服务器状态并且每台机器之间都相互通信。集群是选举机制第一次启动选举机制、非第一次启动选举机制/任意服务器故障股适合安装奇数服务器至少3台。
分布式锁
Zookeeper 是基于临时顺序节点以及 Watcher 监听器机制实现分布式锁的且它的每个节点的变更都是原子性的。它的每一个节点都是一个天然的顺序发号器。ZooKeeper 节点的递增有序性可以确保锁的公平。ZooKeeper 的节点监听机制可以保障占有锁的传递有序而且高效。ZooKeeper 的节点监听机制能避免羊群效应。
队列管理
两种类型的队列 1、同步队列当一个队列的成员都聚齐时这个队列才可用否则一直等待所有成员到达。 2、队列按照 FIFO 方式进行入队和出队操作。 和分布式锁服务中的控制时序场景基本原理一致入列有编号出列按编号。 分布式与数据复制
Zookeeper作为一个集群提供一致的数据服务自然它要在所有机器间做数据复制。数据复制的好处 1、容错一个节点出错不致于让整个系统停止工作别的节点可以接管它的工作 2、提高系统的扩展能力 把负载分布到多个节点上或者增加节点来提高系统的负载能力 3、提高性能让客户端本地访问就近的节点提高用户访问速度。 从客户端读写访问的透明度来看数据复制集群系统分下面两种 1、写主(WriteMaster) 对数据的修改提交给指定的节点。读无此限制可以读取任何一个节点。这种情况下客户端需要对读与写进行区别俗称读写分离 2、写任意(Write Any)对数据的修改可提交给任意的节点跟读一样。这种情况下客户端对集群节点的角色与变化透明。 对zookeeper来说它采用的方式是写任意。通过增加机器它的读吞吐能力和响应能力扩展性非常好而写随着机器的增多吞吐能力肯定下降这也是它建立observer的原因而响应能力则取决于具体实现方式是延迟复制保持最终一致性还是立即复制快速响应。 Zookeeper工作原理
Zookeeper 的核心是原子广播这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式它们分别是恢复模式选主和广播模式同步。当服务启动或者在领导者崩溃后Zab就进入了恢复模式当领导者被选举出来且大多数Server完成了和 leader的状态同步以后恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 **为了保证事务的顺序一致性zookeeper采用了递增的事务id号zxid来标识事务。**所有的提议proposal都在被提出的时候加上了zxid。实现中zxid是一个64位的数字它高32位是epoch用来标识leader关系是否改变每次一个leader被选出来它都会有一个新的epoch标识当前属于那个leader的统治时期。低32位用于递增计数。
如何实现服务注册与发现
服务提供方(用户服务)启动成功后将服务信息注册到Zookeeper服务信息包括实例的 ip、端口等元信息。注册成功 Zookeeper 还可以通过心跳监测来动态感知实例变化。
服务消费方(订单服务)需要调用用户服务的接口但因为不知道实例的 ip、端口等信息只能从 Zookeeper 中获取调用地址列表然后进行调用这个过程成为服务的订阅。
订阅成功后服务消费方可以将调用列表缓存在本地这样不用每次都去调用 Zookeeper 获取。一旦 Zookeeper感知到用户服务实例变化后就会通知给服务消费方服务消费方拿到结果后就会更新本地缓存这个过程称之为通知。
Zookeeper的重点特性
1集群只能一个领导多个跟随者 奇数 并且只要半数以上节点存活集群就才能正常服务
2全局数据一致每个server保存一份相同的数据副本
3同一个Client更新请求顺序执行
4数据更行原子性
5树状目录结构
6实时性。一定时间访问内客户端读到最新数据
7持久节点。即使断开连接节点也不会被删除
8持久有序节点。注册节点的时候存在序号
9临时节点注册之后与Zookeeper服务端断开连接后该节点被删除
10节点监听机制用于消息通知。 Eureka
Eureka 就是 Netflix 的 服务发现框架 。Eureka是一个基于REST的服务用于定位服务以实现云端中间层服务发现和故障转移。服务注册与发现对于微服务架构来说是非常重要的有了服务发现与注册只需要使用服务的标识符就可以访问到服务而不需要修改服务调用的配置文件了。
服务发现其实就是一个“中介”整个过程中有三个角色服务提供者(卖房子出租房子的)、服务消费者(租客买主)、服务中介(房屋中介)。
服务提供者 就是提供一些自己能够执行的一些服务给外界。
服务消费者 就是需要使用一些服务的“用户”。
服务中介 其实就是服务提供者和服务消费者之间的“桥梁”服务提供者可以把自己注册到服务中介那里而服务消费者如需要消费一些服务(使用一些功能)就可以在服务中介中寻找注册在服务中介的服务提供者。
基础概念
服务注册 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秒(3个续约周期)没有向Eureka服务器发送服务续约即心跳Eureka服务器会将该服务实例从服务注册列表删除即服务剔除。 续约机制 1服务注册。客户端要向服务端注册时需提供自身的元数据IP、端口等 2服务续约。每隔30秒发送一次心跳来进行服务续约。缓冲 3获取服务注册列表。从服务器获取服务列表并缓冲到本地 4服务下线。客户端关闭时向服务端发送下线请求服务做下线处理 5服务剔除。客户端连续90秒如果没有向服务端进行续约就会被剔除。 Eureka的保护模式
当新的Server出现从相邻peer节点读取所有服务实例如果从相邻peer获取信息失败会尝试从其他peer节点获取。
server拥有所有的服务实例后会根据配置设置服务续约的阈值。在任何时间如果接收到的服务续约低于该值配置的百分比默认15分钟百分比为85%就开启自我保护模式不在剔除注册服务的信息。
选择的原因完全开源、而且跟其他组件很容易实现服务注册、负载均衡、熔断、路由等功能。
服务端配置
另外还需要在启动类中设置 EnableEurekaServer 注解开启 Eureka 服务
eureka:instance:hostname: xxxxx # 主机名称prefer-ip-address: true/false # 注册时显示ipserver:enableSelfPreservation: true # 启动自我保护renewalPercentThreshold: 0.85 # 续约配置百分比客户端配置
eureka:client:register-with-eureka: true/false # 是否向注册中心注册自己fetch-registry: # 指定此客户端是否能获取eureka注册信息service-url: # 暴露服务中心地址defaultZone: http://xxxxxx # 默认配置instance:instance-id: xxxxx # 指定当前客户端在注册中心的名称Nacos
Nacos 致力于发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集帮助快速实现动态服务发现、服务配置、服务元数据及流量管理。是Spring Cloud A 中的服务注册发现组件类似于Consul、Eureka同时它又提供了分布式配置中心的功能这点和Consul的config类似支持热加载。
实现原理
服务注册时在服务端本地会通过轮询注册中心集群节点地址进行服务得注册在注册中心上即Nacos Server上采用了Map保存实例信息当然配置了持久化的服务会被保存到数据库中在服务的调用方为了保证本地服务实例列表的动态感知Nacos与其他注册中心不同的是采用了 Pull/Push同时运作的方式。
四大功能
1服务发现与服务健康检查
Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent 注册 Service 后服务消费者可以使用DNS或HTTPAPI查找和发现服务。
Nacos 提供对服务的实时的健康检查阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层(如 HTTP、MySQL、用户自定义的健康检查。对于复杂的云环境和网络拓扑环境中如 VPC、边缘网络等服务的健康检查Nacos提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos还提供了统一的健康检查仪表盘帮助您根据健康状态管理服务的可用性及流量。
2动态配置管理
动态配置服务允许在所有环境中以几种和动态的方式管理所有服务的配置Nacos消除了在更新配置时重新部署应用程序这种配置的更改更加高效和灵活。
动态配置服务可以以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单让服务按需弹性扩展变得更容易。
Nacos 提供了一个简洁易用的UI帮助管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
3动态DNS服务
Nacos服务支持权重路由可以用于实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以DNS 协议为基础的服务发现以帮助消除耦合到厂商私有服务发现 API 上的风险。
Nacos 提供了一些简单的 DNS APIs 帮助管理服务的关联域名和可用的 IP:PORT 列表.
4服务和元数据管理
可以从微服务平台建设的视角管理数据中心的所有服务及元数据包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的SLA 以及最首要的 metrics 统计数据。 Nacos原理
Nacos注册中心分为server与clientserver采用Java编写为client提供注册发现服务与配置服务。而client可以用多语言实现client与微服务嵌套在一起nacos提供sdk和openApi如果没有sdk也可以根据openApi手动写服务注册与发现和配置拉取的逻辑。 Nacos注册概括来说有6个步骤 0、服务容器负责启动加载运行服务提供者。 1、服务提供者在启动时向注册中心注册自己提供的服务。 2、服务消费者在启动时向注册中心订阅自己所需的服务。 3、注册中心返回服务提供者地址列表给消费者如果有变更注册中心将基于长连接推送变更数据给消费者。 4、服务消费者从提供者地址列表中基于软负载均衡算法选一台提供者进行调用如果调用失败再选另一台调用。 5、服务消费者和提供者在内存中累计调用次数和调用时间定时每分钟发送一次统计数据到监控中心。 Nacos 服务注册与订阅的完整流程
Nacos 客户端进行服务注册有两个部分组成一个是将服务信息注册到服务端另一个是像服务端发送心跳包这两个操作都是通过 NamingProxy 和服务端进行数据交互的。
Nacos 客户端进行服务订阅时也有两部分组成一个是不断从服务端查询可用服务实例的定时任务另一个是不断从已变服务队列中取出服务并通知 EventListener 持有者的定时任务。服务消费方是通过RestTemplate调用提供方的服务。 心跳检测 1服务注册的策略的是每5秒向nacos server发送一次心跳心跳带上了服务名服务ip服务端口等信息。 2 nacos server也会向client 主动发起健康检查支持tcp/http检查。如果15秒内无心跳且健康检查失败则认为实例不健康如果30秒内健康检查失败则剔除实例。 服务领域模型
Nacos服务领域模型主要分为命名空间、集群、服务。
1在服务级别保存了健康检查开关、元数据、路由机制、保护阈值等设置
2集群保存了健康检查模式、元数据、同步机制等数据
3命名空间/实例保存了该实例的ip、端口、权重、健康检查状态、下线状态、元数据、响应时间。
其他
1Nacos中的负责均衡底层是如何实现的?
通过内置的Ribbon实现的,nacos(部分版本)默认的负载均衡策略是轮询,然后基于这些算法从服务实例中获取一个实例为消费方法提供服务
2Ribbon 内置的负载策略都有哪些?
8种,可以通过查看IRule接口的实现类进行分析
3LoadBalanced的作用是什么
用于告诉Spring框架在使用RestTempalte进行服务调用时这个调用过程会被一个拦截器进行拦截,然后在拦截器内部,启动负载均衡策略。
4我们可以自己定义负载均衡策略吗
可以基于IRule接口进行策略定义,也可以参考NacosRule进行实现
小结
Nacos除了服务的注册发现之外还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单让服务按需弹性扩展变得更容易。一句话概括就是Nacos Spring Cloud注册中心 Spring Cloud配置中心。 服务发现产品对比
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SNdDbcNh-1684303939306)(/Users/zhaoyanhong/Library/Application Support/typora-user-images/image-20230516113253459.png)]
Eureka 符合AP原则 为了保证了可用性Eureka 不会等待集群所有节点都已同步信息完成它会无时无刻提供服务。Zookeeper 符合CP原则 为了保证一致性在所有节点同步完成之前是阻塞状态的。Nacos与eureka都支持服务注册和服务拉取以及提供者心跳方式做健康检测。Nacos 集群默认采用 AP 方式当集群中存在非临时实例时采用 CP 模式 Eureka 采用 AP 方式
Ribbon基于客户端的负载均衡组件。
前言
Ribbon是Netflix发布的负载均衡器他有助于控制http和TCP客户端的行为为Ribbon配置服务提供者的地址列表后ribbon就可基于某种负载均衡算法自动的帮助服务消费者去请求。
Ribbon默认为我们提供了很多的负载均衡算法例如轮询、随机等我们也可为ribbon实现自定义的负载均衡算法。在spring cloud中当ribbon与eureka/nacos配合使用时ribbon可自动获取服务提供者的地址列表并基于负载均衡算法请求其中一个服务提供者的实例为了服务的可靠性一个微服务可能部署多个实例。
RestTemplate是Spring Resource中一个访问第三方RESTful API接口的网络请求框架。可以说RestTemplate就是用来消费REST服务的。 负载均衡指的是将负载分摊到多个执行单元上。常见的负载均衡有两种方式 1是独立进程单元通过负载均衡将请求转发到不同的执行单元上简单理解就是将所有请求都集中起来然后再进行负载均衡。例如Nginx 2是将负载均衡以代码的形式封装到服务消费者的客户端的进程里。消费服务的客户端有服务提供的信息列表就可以根据负载均衡测罗将请求分摊到多个服务提供者 例如Ribbon。 底层分析
可以说Ribbon的负载均衡是属于客户端级别以及消费者的负载均衡它主要是通过LoadBalancerClient来实现的。而LoadBalancerClient的具体是交给了ILoadBalancer来处理ILoadBalancer通过配置IRule策略、IPing 进行负载均衡。
RestTemplate加上LoadBalancer就可以实现远程调用负载均衡。RestTemplate接口能实现主要是添加了拦截器只要是LoadBalancer的就交给Ribbon的负载均衡器进行处理。
Ribbon 的几种负载均衡算法
负载均衡不管 Nginx 还是 Ribbon 都需要其算法的支持 Nginx 使用的是 轮询和加权轮询算法。而在 Ribbon 中有更多的负载均衡调度算法其默认是使用的 RoundRobinRule 轮询策略。
RoundRobinRule轮询策略。Ribbon 默认采用的策略。若经过一轮轮询没有找到可用的 provider其最多轮询 10 轮。若最终还没有找到则返回 null。RandomRule: 随机策略从所有可用的 provider 中随机选择一个。RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider若获取失败则在指定的时限内重试。默认的时限为 500 毫秒。
当然在 Ribbon 中你还可以自定义负载均衡算法你只需要实现 IRule 接口然后修改配置文件或者自定义 Java Config 类。
客户端负载均衡
多可用区多地域的生产环境
地域简称Region是指物理的数据中心。可用区简称Zone是指在同一地域内电力和网络互相独立的物理区域。同一个地域内的可用区之间使用低时延链路相连。 若client/server所处的可用区/地域不同网络延时也不同 同一可用区内的网络延时最低可忽略不计同一地域下不同可用区之间的网络延时可以达到~1ms级别具体看可用区之间的物理距离不同地域之间的网络延时可以达到几十ms级别具体看地域之间的物理距离 出于容灾考虑大部分互联网公司的业务会部署在多个可用区甚至多个地域。所以一个完善的负载均衡机制必须考虑多可用区地域的运行环境尽最大可能保证网络调用发生在同一个可用区以达到最小的网络延时。
高可用性
微服务架构下Server可能由于各种原因而不可用比如网络问题服务过载依赖服务不可用导致的级联故障等等。出于可用性考虑负载均衡要能够及时过滤不可用的Server。
源码分析
Ribbon的核心模块主要有4个
Rule表示负载均衡的具体规则或策略比如round robinPing负责健康检测Health Check的模块ribbon会启动一个后台线程执行健康检测ServerList静态或者动态的服务器列表如果是动态列表ribbon会启动一个后台线程定期从指定数据源比如eureka更新服务器列表LoadBalancer整合以上模块提供完整的负载均衡服务
ILoadBalancer
ILoadBalancer接口定义了所有LoadBalancer子类需要实现的方法列表。其中最重要的就是chooseServer方法也是负载均衡的核心。
BaseLoadBalancer
BaseLoadBalancer是ILoadBalancer的一个basic实现允许用户自定义健康检测机制(IPing IPingStrategy)和负载均衡策略IRule。
IRule
IRule接口表示负载均衡的规则或者策略比如round robin或response time based等等。IRule的接口定义比较简单. 目前IRule的常用实现类有 RoundRobinRule经典的round robin策略它通常被用作默认规则或更高级规则的后备规则AvailabilityFilteringRule在round robin的基础上剔除不可用的节点可用的定义参见下文源码分析WeightedResponseTimeRule根据response time赋予不同Server不同的权重从而实现weighted round robin IPing
IPing定义了Health Check子类必须实现的接口。 IPing的常用实现类有 DummyPing: 什么也不做PingUrl根据配置的url发起http请求是标准的health check模式NIWDiscoveryPing依赖服务发现机制比如eureka的in-memory cache判断server是否alive。相比PingUrlNIWDiscoveryPing效率更高因为并不需要发起实际的http请求 IPingStrategy
IPingStrategy接口定义的是给定IPing和Server列表如何检测所有Server列表。
其他
以后补充…
Nginx
**Nginx是一个免费、开源、高性能、轻量级的 HTTP 和反向代理服务器也是一个电子邮件IMAP/POP3代理服务器其特点是占有内存少并发能力强。**Nginx 可以作为静态页面的 web 服务器同时还支持 CGI 协议的动态语言比如 perl、php 等但是不支持 java。Java 程序一般都通过与 Tomcat 配合完成。
核心模块
HTTP 模块、EVENT 模块和 MAIL 模块
基础模块
HTTP Access 模块、HTTP FastCGI 模块、HTTP Proxy 模块和 HTTP Rewrite 模块
第三方模块
HTTP Upstream Request Hash 模块、Notice 模块和 HTTP Access Key 模块及用户自己开发的模块
为什么使用反向代理
保护和隐藏原始资源服务器加密和SSL加速通过缓存静态资源加速Web请求实现负载均衡
Load Balance
Open Feign(接口调用
微服务之间通过rest接口通讯springcloud提供fegin框架来支持rest的调用fegin使得不同进程的rest接口调用得以用优雅的方式进行这种优雅表现的就像同一个进程调用一样简化微服务的通信过程。
**feign采用的是基于接口的注解 feign整合了ribbon具有负载均衡的能力整合了Hystrix具有熔断的能力。**feign被设计成插拔式可以注入其他组件一起使用常和Ribbon实现负载均衡。
Fegin是个伪 Http客户端Fegin不做任何的请求处理。通过处理注解生成定制的Request模版从而简化http开发。Client组件是负责发送Request请求和接收响应的。
Open Feign类似采用映射方式域名和 IP 地址的映射可以将被调用的服务代码映射到消费者端。也就是说OpenFeign 是运行在消费者端的也可以使用 Ribbon 进行负载均衡通过LoadBalancer启用负载均衡。所以 OpenFeign 直接内置了 Ribbon。
实现过程
1首先通过EnableFeignClients注解开启FeignClient的功能只有这个注解的存在才会在程序启动的时候开启对FeignClient注解的包的扫描。
2根据Feign规则实现接口并在接口上添加FeignClient注解。
3程序启动会把该注解下的类注入到IOC容器中当接口调用时生成RequestTemplate模版对象再生成Request对象。
4交由Client去处理最后的被封装到LoadBalanceClient类这个类可以结合Ribbon做到负载均衡加负载均衡的注解LoadBalancer。
源码分析
Feign 是通过定义接口并且在接口方法上使用注解定义请求模板然后通过 Feign.builder() 进行构建后即可像使用本地接口方法调用Http请求。
Feign 使用详解
接口注解
注解目标用法RequestLine方法定义请求 的HttpMethod。用大括号括起来的Expression使用它们对应的带注释的参数来解析。Param参数定义一个模板变量其值将用于解析相应的模板Expression按作为注释值提供的名称提供Headers方法、接口定义一个请求头模板其中可以使用大括号括起来的表达式将使用 Param 注解的参数解析标注在方法上只针对某个请求标注在类上表示作用的所有的请求上QueryMap参数定义Map名称-值对或 POJO以扩展为查询字符串。HeaderMap参数定义一个Map名称-值对展开成 请求头Body方法类似于一个 URI 模板他使用 Param 注解的参数来解析模板中的表达式
模板和表达式
**Feign 是由 URI 模板 Expressions 定义的简单字符串表达式并且使用 Param 注解的方法参数进行解析。**表达式必须用大括号括起来{}并且可以包含正则表达式模式用冒号分隔: 以限制解析值。 示例 owner必须是字母。{owner:[a-zA-Z]*}
请求参数扩展
RequestLine和QueryMap模板遵循URI模板 规范该规范指定以下内容
未解析的表达式被省略。所有文字和变量值都经过 pct-encoded 编码如果尚未encoded通过Param注释编码或标记。
请求头扩展
在Feign 中可以通过 Headers 和HeaderMap 两个注解来扩展请求头并且遵循以下规则
未解析的表达式被忽略如果请求头的值为空这删除整个请求头。不执行pct-encoded 编码
Headers
Headers 注解可以标注到 api 方法上也可以标注到客户端即接口上标注在接口上表示对所有的请求都起作用标注在 方法上 只对所标注的方法起作用。
HeaderMap
Headers 虽然也能动态设置头信息但是当请求头的键和个数不确定时Headers 就不能满足了此时我们可以使用 HeaderMap 注解的 方法参数来更灵活的动态指定请求头。
请求正文扩展
Body 模板遵循与请求参数扩展相同的扩展但有一下更改
未解析的表达式被省略扩展值在放置在正文之前不会被 Encoder 进行编码Content-Type 请求头必须设置
解码器
在实际开发中服务端返回的数据可能是个JSON字符串或者字节数组在 Feign 中可以通过指定解码器把响应数据解析为你想要的数据类型。一般都是默认使用feign-gson 进行解码的。
请求客户端扩展
Feign 底层默认使用的是 JDK 自带的 URLConnection 实现的网络请求。在Feign 中也可以在构建时指定自定的底层网络请求工具比如常用的OkHttp 和 Apache HttpClient 等。Feign 也已经实现了 这两个客户端只需要引入依赖就可以直接使用。
小结
Feign 是一个很好的框架工具把繁琐的 Http 请求抽象为以接口加注解的方式实现也使开发者很好的面向接口编程。在目前微服务盛行的当下Spring 也对 Feign 进行了封装即OpenFeign 。这里把最底层、最基础的Feign的用法梳理一下能够更好的理解 Spring 封装的 OpenFeign。
Hystrix容错框架
前言
在分布式环境中不可避免地会有许多服务依赖项中的某些失败。Hystrix 是一个库可通过添加等待时间容限和容错逻辑来帮助控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点停止服务之间的级联故障并提供后备选项来实现此目的所有这些都可以提高系统的整体弹性。
总体来说 Hystrix 就是一个能进行 熔断 和 降级 的库通过使用它能提高整个系统的弹性。 为什么请求阻塞会崩溃 因为这些请求会消耗占用系统的线程、IO 等资源消耗完了这个系统服务器就会崩了。 介绍
所谓 熔断 就是服务雪崩的一种有效解决方案。当指定时间窗内的请求失败率达到设定阈值时系统将通过 断路器 直接将此请求链路断开。熔断 就是指的 Hystrix 中的 断路器模式 你可以使用简单的 HystrixCommand 注解来标注某个方法这样 Hystrix 就会使用 断路器 来“包装”这个方法每当调用时间超过指定时间时(默认为 1000ms)断路器将会中断对这个方法的调用。
而降级是为了更好的用户体验当一个方法调用异常时通过执行另一种代码逻辑来给用户友好的回复。对照着Hystrix 的 后备处理模式。可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。
另外Hystrix有提供 Hystrix 仪表盘它是用来实时监控 Hystrix 的各项指标信息的 什么是舱壁模式 在不使用舱壁模式的情况下服务 A 调用服务 B这种调用默认的是使用同一批线程来执行的而在一个服务出现性能问题的时候就会出现所有线程被刷爆并等待处理工作同时阻塞新请求最终导致程序崩溃。而舱壁模式会将远程资源调用隔离在他们自己的线程池中以便可以控制单个表现不佳的服务而不会使该程序崩溃。 **在SpringCloud框架里熔断机制通过Hystrix实现Hystrix会监控微服务间调用的状况当失败的调用到一定阈值缺省是5秒内调用20次如果失败就会启动熔断机制。**服务降级一般是从整体负荷考虑。就是当某个服务熔断之后服务器将不再被调用此时客户端可以自己准备一个本地的fallback回调返回一个缺省值。这样做虽然水平下降但好歹可用比直接挂掉强。 设计原则 1防止单个服务的故障耗尽整个服务的Servlet容器的线程资源 2快速失败机制如果某个服务出现了故障则调用该服务的请求快速失败而不是线程等待。 3提供回退方案在请求故障时提供社会定好的回退方案。 4使用熔断机制防止故障扩散的服务。资源一直被占用其他请求得不到资源会导致服务故障更多。 5提供熔断器的监控组件HystrixDashboard,可以实时监控熔断器的状态。 Hystrix的工作机制
当服务的某个API接口的失败次数在一定时间内小于设定的阈值缺省是5秒内调用20次熔断器处于关闭状态如果失败次数大于阈值就会判定API接口出现了故障会打开熔断器。之后会执行设置的快速失败逻辑不执行业务逻辑请求线程就不会处于阻塞的状态。而处于打开状态的熔断器在一段时间会处于半打开的状态将一定的数量执行正常逻辑其余的快速失败。若是执行业务逻辑成功则熔断器关闭。
工作流程
构建HystrixCommand或者HystrixObservableCommand对象执行命令是否有Response缓存是否断路器打开是否线程池或者队列或者信号量被消耗完HystrixObservableCommand.construct() or HystrixCommand.run()计算链路的健康情况获取fallback逻辑返回成功的Respons
Sentinel 轻量级高可用流量控制组件
Sentinel 是阿里中间件团队开源的面向分布式服务架构的轻量级高可用流量控制组件主要以流量为切入点从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。
Sentinel特征
丰富的应用场景Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景例如秒杀即突发流量控制在系统容量可以承受的范围、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。完备的实时监控Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据甚至 500 台以下规模的集群的汇总运行情况。广泛的开源生态Sentinel 提供开箱即用的与其它开源框架/库的整合模块例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。完善的 SPI 扩展点Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性 Sentinel 分为两个部分:
核心库Java 客户端
不依赖任何框架/库能够运行于所有 Java 运行时环境同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
控制台Dashboard
基于 Spring Boot 开发打包后可以直接运行不需要额外的 Tomcat 等应用容器。
核心功能
流量控制
Sentinel作为一个调配器可以根据需要把随机的请求调整成合适的形状。
熔断降级
当检测到调用链路中某个资源出现不稳定的表现例如请求响应时间长或异常比例升高的时候则对这个资源的调用进行限制让请求快速失败避免影响到其它的资源而导致级联故障。
Sentinel的规则
流量控制规则流控模式为QPS
若设置触发流控执行阈值为1那么接口访问1次就被限流
熔断降级规则
降级规则的熔断策略有3种分别是慢调用比例、异常比例、异常数。
系统保护规则
访问控制规则gateway规则配置
热点规则
热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据并对其访问进行限制。
Sentinel 适配了 Feign 组件
大概使用步骤如下
1需要在服务调用方加入依赖
2服务调用方配置文件中开启Feign支持 sentinel
3实现降级处理方案。
3-1创建指定类用于实现熔断之后后置处理方案不同接口不同的异常处理预案。实现fallbackFactory接口。
3-2在接口的注解上指定降级处理类用于一类统一处理预案。
Zuul 微服务网关
前言
API 网关提供路由转发、请求过滤等功能。可以做认证、监控、流量监控等。网关的角色是作为一个 API 架构用来保护、增强和控制对于 API 服务的访问。
API 网关是一个处于应用程序或服务提供 REST API 接口服务之前的系统用来管理授权、访问控制和流量限制等这样 REST API 接口服务就被 API 网关保护起来对所有的调用者透明。 因此隐藏在 API 网关后面的业务系统就可以专注于创建和管理服务而不用去处理这些策略性的基础设施。
**服务网关内置了19中过滤器工厂服务网关分为网关过滤器Zuul/Gateway和全局过滤器(实现 GlobalFilter 和 Ordered)。**网关过滤器通过配置文件作用到所有路由上。
常见的限流算法计数器算法、漏桶算法、令牌桶算法。
介绍
Zuul网关是是Netflflix开源的微服务网关它可以和Eureka、Ribbon、Hystrix等组件配合使用Zuul的底层基于Servlet本质上就是一系列的filter过滤器也是它的核心。Zuul2是采用Netty实现异步IO。 这些过滤器可以完成
动态路由动态将请求路由到不同后端集群
压力测试逐渐增加指向集群的流量以了解性能
负载分配为每一种负载类型分配对应容量并弃用超出限定值的请求
静态响应处理边缘位置进行响应避免转发到内部集群
身份认证和安全: 识别每一个资源的验证要求并拒绝那些不符的请求。
Zuul网关过滤器
Zuul的路由功能实现了统一处理外部请求的功能负责将外部请求转发到具体的微服务实例上是实现外部访问统一入口的基础。zuul还提供过滤器功能负责对请求的处理过程进行干预是实现请求校验、服务聚合等功能的基础。
只需自定义一个filter类并继承ZuulFilter重写四个方法即可定义一个zuul过滤器类
Zuul提供一个RequstContext上下文对象它内部采用ThreadLocal保存每个请求的一些信息包括请求路由、错误信息、HttpServletRequest、HttpServletResponse这使得一些操作是十分可靠的它还扩展了ConcurrentHashMap目的是为了在处理过程中保存任何形式的信息
Zuul的工作原理
Zuul是通过Servlet来实现的Zuul通过自定义的Servlet来对请求进行控制。Zuul的核心是一系列的过滤器Zuul采用了动态读取、编译和运行这些过滤器这些过滤器之间不能互相通讯只能通过RequestContext对象来共享数据。用设计模式的角度来说是采用了策略模式。 四个过滤器 1PRE过滤器可以做安全认证 比如身份验证、参数验证。 2ROUTING过滤器将请求路由到具体的微服务实例。默认使用HTTP请求 3POST 过滤器用作收集统计信息、指标以及将响应传到客户端。 4ERROR过滤器在其他过滤器发生错误时进行执行。 过滤器的类型 type决定了过滤器在请求的哪个阶段起作用例如 pre post。 Execution Order:过滤器的执行次序越小越先执行 Criteria:过滤器执行所需的条件。 Action如果符合执行条件则执行Action即逻辑代码。 servlet就是一个组件要求需要符合servlet规范并且需要部署到servlet容器里面才能运行。 注**容器符合相应的规范提供组件运行环境的程序。**比如Tomcat就是比较有名的servlet容器。jetty jboss weblogic都是servlet容器。这些servlet把网络相关的问题已经全部处理好我们写servlet只需要关注业务逻辑即可。 如何写一个servlet 1写一个java类需要实现Servlet接口或者继承HttpServlet类。 2编译。 3打包将这个java类变成servlet组件 一个请求的执行过程
进入到网关先进入pre filter进行一些列的验证、操作、判断。交给routing filter进行路由转发转发到具体的服务实例进行逻辑处理当处理完又post filter进行处理该处理完将Respose返回给客户端。
Gateway网关
Spring Cloud Gateway基于 Spring 5.0Spring Boot 2.0 和 Project Reactor 等技术开发的网关它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。基于 Filter 链的方式提供了网关基本的功能例如安全监控/指标和限流。底层使用了高性能的通信框架Netty,提供了异步支持提供了抽象负载均衡提供了抽象流控并默认实现了RedisRateLimiter。
Spring Cloud Gateway 使用的是reactor-netty响应式编程组件Reactor线程模型底层使用了Netty通讯框架Netty 是高性能中间件的通讯底座。与Zuul最大的区别是底层的通讯框架上但是Zuul2.0也采用Netty做通讯底座区别就相对小一点。 Springcloud Zuul 是基于servlet之上的一个阻塞式处理模型即spring实现了处理所有request请求的一个servletDispatcherServlet并由该servlet阻塞式处理处理。所以Springcloud Zuul无法摆脱servlet模型的弊端。虽然Zuul 2.0开始使用了Netty并且已经有了大规模Zuul 2.0集群部署的成熟案例但是Springcloud官方已经没有集成改版本的计划了。 SpringCloud Gateway 特征
1基于 Spring Framework 5Project Reactor 和 Spring Boot 2.0
2可集成 Hystrix 、Sentinel实现熔断降级
3集成 Spring Cloud DiscoveryClient
4Predicates 和 Filters 作用于特定路由易于编写的 Predicates 和 Filters
5具备一些网关的高级功能动态路由、限流、路径重写
术语说明
Filter过滤器使用它拦截和修改请求并且对上游的响应进行二次处理
Route路由
网关配置的基本组成模块和Zuul的路由配置模块类似。一个Route模块由一个 ID一个目标 URI一组断言和一组过滤器定义。如果断言为真则路由匹配目标URI会被访问。
Predicate断言
这是一个 Java 8 的 Predicate可以使用它来匹配来自 HTTP 请求的任何内容例如 headers 或参数。断言的输入类型是一个 ServerWebExchange
Spring Security
Spring Security是什么
Spring Security 是Spring Resouurce社区的一个安全组件可以在Controller、Service、DAO层等以加注解的方式来保护应用程序的安全。**提供了细粒度的权限控制**可以精细到每个API接口、每个业务的方法、每个操作数据库的DAO层。Security提供的是应用层的安全解决方案但是一个系统还需要考虑传输层、系统层的安全例如Http协议、服务器部署防火层、服务器集群隔离部署等。
向服务单元提供了用户验证、权限认证。一般组合OAuth2.0JWT一起使用。
**在安全方面主要有两个领域一个是认证、而是授权。**认证是认证主体的过程通常是可以在应用程序中执行操作的用户、设备或者其他系统。授权是指决定是否允许已认证的主体执行某一操作。Spring Security采用注解的方式控制权限容易上手。Spring Security支持很多种认证方式自带和第三方的。
原理分析
SpringSecurity本质是用一个Filter链实现认证的功能利用过滤器过滤需要认证的Request然后进行认证。然而SpringSecurity并不是直接把所有Filter直接注册到服务容器比如Tomcat上。而是使用了一个DelegatingFilterProxy 的Filter代理类。 使用代理的好处是 一方面可以让Security的Filter交给spring管理进而spring的一些功能Filter注册肯定要在Listener调用前完成而spring是通过ContextLoaderListener 加载Bean的使用代理的话可以延迟加载才不会在spring ioc没加载前使用它。另外一方面可以将Spring的Filter和其他Filter隔离开来。 由于DelegatingFilterProxy 是一个普通Filter如果通过延迟加载所有 Filter 那也太麻烦了而且不好弄如果让一个注册到spring中的代理去操作具体的Filter而DelegatingFilterProxy 就只需要延迟加载这个代理直接写死在配置文件中通过读取配置security的web配置文件然后从server中拿。而这个被用来代理处理具体和spring交互的就是 FilterChainProxy 。FilterChainProxy 杂负责拿到SecurityFilterChain并负责调用。 实际上可以不止一个FilterChain比如要根据不同的服务划分不同的验证流程就可以使用不同的Chain处理。FilterChainProxy根据请求路径调用匹配到的SecurityFilterChain。比如对外采用不同的模式进行认证
SecurityContextHolderSecurityContextHolderStrategy
SecurityContextHolder从名字就知道它是用来放SecurityContext的。在认证成功后AbstractAuthenticationProcessingFilter 会将认证成功的Authentication 放到SecurityContext当中。可以从它获取到Authentication由他得到用户的认证得到的信息做进一步处理。在Web环境下默认情况下SecurityContextHolder使用ThreadLocal来保存这些信息。 可以设置不同的SecurityContextHolderStrategy有三种模式可选: SecurityContextHolder.MODE_THREADLOCAL只有当前线程可以访问SecurityContextHolder.MODE_INHERITABLETHREADLOCAL继承关系创建的新线程也可以访问适用于开放平台SecurityContextHolder.MODE_GLOBAL 全局非Web应用可能使用这个内对 权限控制的实现
通过注解
一般不使用因为不够灵活而且要把权限写死。
通过ExpressionInterceptUrlRegistry进行配置
SpringSecurity会把ExpressionInterceptUrlRegistry中配置的权限控制规则转换成SecurityMetadataSource。FilterSecurityInterceptor 利用SecurityMetadataSource 来进行权限的校验。FilterSecurityInterceptor 是默认SecurityFilterChain最后一个Filter负责访问权限的判断。具体就是从SecurityContextHolder中获取Authentication对象然后比对用户拥有的权限和资源所需的权限具体见FilterSecurityInterceptor 的父类 AbstractSecurityInterceptor中的beforeInvocation方法。授权失败抛出AccessDeniedException 。
FilterSecurityInterceptor 有一个属性observeOncePerRequest 控制一个请求是不是只进行一次鉴权。有时候一个请求并不止调用Filter链一次因为能是forward过来的请求。BasicAuthenticationFilter通过继承 OncePerRequestFilter 强制一个请求只通过一次。而FilterSecurityInterceptor 是可以通过observeOncePerRequest 控制它的行为。有时候需要每次都进行鉴权就要将其设为false。
它父类**AbstractSecurityInterceptor 有一个属性alwaysReauthenticate 可以控制是否每次都重新鉴权**。在使用session保存context时如果同一个session的请求再次到来它是不用再鉴权的。如果将alwaysReauthenticate 设为true那当来到FilterSecurityInterceptor 的时候会调用AuthenticationManager的一个实例它独立的一个AuthenticationManager重新鉴权。
异常处理
AbstractAuthenticationProcessingFilter 使用模板模式共同代码实现关于认证留下一个attemptAuthentication的hook。子类要实现这个方法的认证功能。而它抛出的AuthenticationException 都是由AbstractAuthenticationProcessingFilter 处理。
ExceptionTranslationFilter 它是SecurityFilterChain中倒数第二个Filter负责转换异常其实转换的是FilterSecurityInterceptor 抛出的异常并不是前面的一些Filter抛出的异常更不是全局异常处理器这一点很多人都弄错了。
如果该过滤器检测到AuthenticationException则将会交给内部的AuthenticationEntryPoint去处理如果检测到AccessDeniedException需要先判断当前用户是不是匿名用户如果是匿名访问则和前面一样运行AuthenticationEntryPoint否则会委托给AccessDeniedHandler去处理而AccessDeniedHandler的默认实现是AccessDeniedHandlerImpl。
可以通过自定义AuthenticationEntryPoint实现授权失败执行的逻辑一般是直接响应401带上一些信息。
事件
在认证过程中SpringSecurity会发布一些事件。件分为两大类认证事件和授权事件。
事件发布
如果你要让SpringSecurity发布认证事件你要注册一个AuthenticationEventPublisher 的bean默认实现是DefaultAuthenticationEventPublisher 而关于授权事件你要注册一个AuthorizationEventPublisher 的bean默认实现是SpringAuthorizationEventPublisher。然后你就可以使用EventListener监听对应事件。
使用默认的DefaultAuthenticationEventPublisher认证成功会发布AuthenticationSuccessEvent 失败时会发AbstractAuthenticationFailureEvent 。默认的DefaultAuthenticationEventPublisher 将会为下面的异常事件发布AbstractAuthenticationFailureEvent 事件。
异常与事件说明
如果你想改变事件发布这一行为可以用setAdditionalExceptionMappings 设置例子见官方文档。或者你也可以自定义事件一个发布器。
异常事件描述BadCredentialsExceptionAuthenticationFailureBadCredentialsEvent凭证错误UsernameNotFoundExceptionAuthenticationFailureBadCredentialsEvent用户名Not FoundAccountExpiredExceptionAuthenticationFailureExpiredEvent用户过期ProviderNotFoundExceptionAuthenticationFailureProviderNotFoundEvent找不到ProviderDisabledExceptionAuthenticationFailureDisabledEvent用户disableLockedExceptionAuthenticationFailureLockedEvent用户被lockAuthenticationServiceExceptionAuthenticationFailureServiceExceptionEvent系统错误CredentialsExpiredExceptionAuthenticationFailureCredentialsExpiredEvent凭证过期InvalidBearerTokenExceptionAuthenticationFailureBadCredentialsEvent无效令牌
授权成功后发布AuthorizationGrantedEvent 事件不过我没发现有哪里会发布这个事件这个类时版本5.7加入的有事件再测一下。我发现源码中发布的是 AuthorizedEvent 事件。
授权失败时会有AuthorizationDeniedEvent事件。
OAuth2.0
为什么都有了Spring Security了为什么还要Spring Security OAuth2.0
OAuth认证流程简单理解就是允许我们将之前实现的认证和授权的过程交由一个独立的第三方来进行担保。而OAuth协议就是用来顶故意如何让这个第三方的担保有效且双方可信。 而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
介绍
**OAuth2.0是一个标准的授权协议允许不同的客户端通过认证和授权的方式来访问被其保护起来的资源。**主要包含3个角色服务提供者、资源持有者、客户端。 大致流程如下认证、授权 1用户资源持有者打开客户端客户端询问用户授权 2用户同意授权 3客户端向授权服务器申请授权。 4授权服务器向客户端进行认证也包括用户信息的认证认证成功后授权给予令牌。 5客户端获取令牌携带令牌向资源服务器请求资源。 6资源服务器确认令牌正确无误向客户端释放资源。 **OAuth2.0分为两部分分别是OAuth2 Provider和OAuth2 Client。**OAuth2 Provider负责公开被OAuth2保护起来的资源。OAuth2 Provider通过管理和验证OAuth2令牌来控制客户端是否有权限访问被其保护的资源。另外还为用户提供认证API接口。
**OAuth2 Provider角色分为资源服务和授权服务。可能一个授权服务对多个资源服务。**Spring OAuth2.0需配合Spring Security一起使用所有请求经过控制器处理并进过一些列的Spring Security过滤器。**Spring Security过滤器链中有2个节点用于获取验证和授权的。**如果资源服务和授权服务不在同一个服务中则需要做额外的配置。
其他
请查看分布式认证授权篇
JWT
Spring Security OAuth2 保护了微服务系统但是有个缺陷每次请求都需要经过Uaa服务验证Token的合法性并且需要查询该Token对应的用户的权限。针对此问题可以加入JWT的方式Uaa服务只需要验证一次返回JWT用户的所有信息包括用户权限。
介绍
JWT是一种开放的标准定义了一种紧凑且自包含的标准该标准将各个主体的信息包装为JSON对象。主体信息是通过数字签名进行加密和验证的常使用HMAC算法和RSA算法对JWT进行签名安全性很高。
但是存在一个缺点**权限变更之后需要重新登录获取新的Token。**之前的token如果没有过期的话还是可以正常使用的。一种改进方式是登录成功之将token缓存到网关如果权限发生变更将网关的缓存Token删除当请求经过网关判断token在缓存中是否存在不存在就提示重新登录。
JWT由3部分组成Header头、Payload有效负载、Signature签名
使用场景
1认证登录成功获取JWT后续每个请求都携带JWT。
2信息交换JWT的在各方之间安全传输信息的一种方式。使用HeaderPayload计算签名的时候还可以验证内容是否被篡改。
JWT认证过程
浏览器 ---------------》登录 ------------------》服务器------------》用密匙创建JWT -------------》返回JWT给浏览器 -------------》在header添加JWT---------------》检查JWT解密、获取用户信息-----------》给客户响应。
Config分布式配置管理。
有客户端、服务端。服务端读取本地、服务端配置客户端读取服务端配置来达到同一管理。
在Spring Cloud中有分布式配置中心组件spring cloud config 它支持配置服务放在配置服务的内存中即本地也支持放在远程Git仓库中。在spring cloud config 组件中分两个角色一是config server二是config client。
Config Server是一个可横向扩展、集中式的配置服务器它用于集中管理应用程序各个环境下的配置默认使用Git存储配置文件内容也可以使用SVN存储或者是本地文件存储。Config Client是Config Server的客户端用于操作存储在Config Server中的配置内容。微服务在启动时会请求Config Server获取配置文件的内容请求到后再启动容器。
Config Server支持从GIT仓库读取配置文件。配置变更后通过Bus去数据库刷新配置/bus/refresh。也可以将配置存储到mysql数据库。
其他
也有其他组件实现配置管理原理大致相同只是底层结构不一样并且动态配置
Sleuth/Skywalking 服务链条/链路跟踪
Spring Cloud Sleuth为Spring Cloud实现了分布式跟踪解决方案兼容Zipkin、HTrace等其它基于日志的追踪系统例如ELK。目前主流的链路追踪工具Google的Dapper阿里的鹰眼大众点评的CATTwitter的ZipkinLINE的pinpoint国产的skywalking。 · Zipkin********Twitter开源的调用链分析工具目前基于springcloud sleuth得到了广泛的使用特点是轻量使用部署简单。Zipkin是通过RabbiitMQ来传输链路数据的并可以将数据存储到数据库也可以存储到ES上面。 · Pinpoint韩国人开源的基于字节码注入的调用链分析以及应用监控分析工具。特点是支持多种插件UI功能强大接入端无代码侵入。 · Skywalking国产的优秀APM组件是一个基于字节码注入的调用链分析对JAVA分布式应用程序集群的业务运行情况进行追踪、告警和分析的系统。特点是支持多种插件UI功能较强接入端无代码侵入。目前已加入Apache孵化器。 · CAT大众点评开源的基于编码和配置的调用链分析应用监控分析日志采集监控报警等一系列的监控平台工具。 Sleuth特性
探针的性能
主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提高。 skywalking的探针对吞吐量的影响最小zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显。
collector的可扩展性
能够水平扩展以便支持大规模服务器集群。 zipkin支持多个实例订阅MQ异步消费监控信息。skywalking支持单机和集群模式使用gRPC通信。
全面的调用链路数据分析
提供代码级别的可见性以便轻松定位失败点和瓶颈。 zipkin的链路监控粒度到接口级别。skywalking 支持众多的中间件、框架、类库。pinpoint数据分析最完备提供代码级别的可见性以便轻松定位失败点和瓶颈。
对于开发透明容易开关
添加新功能而无需修改代码容易启用或者禁用。 Zipkin它要求在需要时修改代码。skywalking和pinpoint基于字节码增强的方式不需要修改代码并且可以收集到字节码中的更多精确的信息 。
完整的调用链应用拓扑
自动检测应用拓扑帮助你搞清楚应用的架构。 pinpoint界面显示的更加丰富具体到调用的DB名zipkin的拓扑局限于服务于服务之间 。
Skywalking是一个可观测性分析平台和应用性能管理系统它也是基于OpenTracing规范、开源的AMP 系统。Skywalking提供分布式跟踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。支持 Java .Net Core, PHP, NodeJS, Golang, LUA, c代理。支持Istio 特使服务网格访问官方提供的控制台。
xxljob远程调度任务
XXL-JOB是一个分布式任务调度平台其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线开箱即用。在众多XXL-Job平台的特征中有如下几条需要关注的
1、使用简单支持通过Web页面对任务配置降低操作任务的难度
2、动态支持动态修改任务状态、启动/停止任务以及终止运行中任务即时生效
3、调度中心HA中心式调度采用中心式设计“调度中心”自研调度组件并支持集群部署可保证调度中心HA
4、执行器HA分布式任务分布式执行任务”执行器”支持集群部署可保证任务执行HA
5、注册中心: 执行器会周期性自动注册任务, 调度中心将会自动发现注册的任务并触发执行。同时也支持手动录入执行器地址
6、弹性扩容缩容一旦有新执行器机器上线或者下线下次调度时将会重新分配任务
7、触发策略提供丰富的任务触发策略包括Cron触发、固定间隔触发、固定延时触发、API事件触发、人工触发、父子任务触发
Stream构建消息驱动的微服务应用程序的框架。
Spring Cloud Stream 在 Spring Cloud 体系内用于构建高度可扩展的基于事件驱动的微服务其目的是为了简化消息在 Spring Cloud 应用程序中的开发。
Bus消息代理的集群消息总线。
Spring Cloud Bus 使用轻量级的消息代理来连接微服务架构中的各个服务。可以将其用于广播状态更改(例如配置中心配置更改)或其他管理指令 通常会使用消息代理来构建一个主题,然后把微服务架构中的所有服务都连接到这个主题上去,当我们向该主题发送消息时,所有订阅该主题的服务都会收到消息并进行消费。 使用Spring Cloud Bus 可以方便地构建起这套机制,所以 Spring Cloud Bus 又被称为消息总线。常用于MQ扩展
问题
问题一 分布式事务问题一般如何解决 具体内部是怎么实现的
常使用Seata方式来解决。底层是通过二阶段/三阶段提交。Seata有多种模式常用于项目中都是采用AT/TCC模式XA模式需要实现XA的数据源代理。而是SEATA提供的长事务解决方案适用于流程化的长事务场景例如DDD领域驱动架构中的事务管理。
简单可以这么来说一台机器在执行本地事务的时候无法知道其他机器中的本地事务的执行结果。所以他也就不知道本次事务到底应该commit还是 roolback。常规的解决办法就是引入一个“协调者”的组件来统一调度所有分布式节点的执行。
但是AT模式也不能完整的保证事务的一致性有可能在第三阶段提交失败。TCC模式就是解决为了这种场景它有补偿方案。同时AT是引入性小易上手。而TCC因为补偿方案则侵入性非常大每个涉及到分布式事务的接口都需要提供补偿方案。 **两阶段提交主要保证了分布式事务的原子性即所有结点要么全做要么全不做)。所谓的两个阶段是指第一阶段准备阶段(投票阶段)和第二阶段提交阶段执行阶段)。**二阶段无法解决的问题协调者再发出commit消息之后宕机而唯一接收到这条消息的参与者同时也宕机了。 三阶段引入超时机制 (同时在协调者和参与者中都引入超时机制);在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的;也就是说除了引入超时机制之外3PC把2PC的准备阶段再次一分为二这样三阶段提交就有CanCommit、PreCommit、DoCommit三个阶段。3PC主要解决的单点故障问题并减少阻塞因为一旦参与者无法及时收到来自协调者的信息之后他会默认执行commit而不会一直持有事务资源并处于阻塞状态。 用mysql事务视图Read View的角度来讲 同时查询到了一组数据。他们为什么隔离。因为mvcc是通过每个线程拿到自己的事务视图。这个事务视图。是私有的。在同一个事务里。再次查询下都是查询自身的事务视图。在提交前。都不会影响到数据库。自然不会影响到其他事务 查询的数据。都在自己的版本视图里。不会对其他事务造成影响。当提交的时候。如果发现有比自己的事务id更大的。代表有其他事务修改了。那自然就不能修改成功了。而协调者的作用主要用于通知双方进行回滚/提交。 问题二分布式服务与微服务拆分原则 分布式服务是根据业务进行切分 微服务主要是根据数据结构特性、DDD领域作为切分点。通过数据分析服务的划分边界和划分粒度。 文章转载自： http://www.morning.mjkqj.cn.gov.cn.mjkqj.cn http://www.morning.mhlkc.cn.gov.cn.mhlkc.cn http://www.morning.qsy38.cn.gov.cn.qsy38.cn http://www.morning.mfmbn.cn.gov.cn.mfmbn.cn http://www.morning.gkdqt.cn.gov.cn.gkdqt.cn http://www.morning.msgcj.cn.gov.cn.msgcj.cn http://www.morning.ymrq.cn.gov.cn.ymrq.cn http://www.morning.bsqbg.cn.gov.cn.bsqbg.cn http://www.morning.sxbgc.cn.gov.cn.sxbgc.cn http://www.morning.qfbzj.cn.gov.cn.qfbzj.cn http://www.morning.zfxrx.cn.gov.cn.zfxrx.cn http://www.morning.qztsq.cn.gov.cn.qztsq.cn http://www.morning.nzsx.cn.gov.cn.nzsx.cn http://www.morning.hxwrs.cn.gov.cn.hxwrs.cn http://www.morning.yxwrr.cn.gov.cn.yxwrr.cn http://www.morning.snktp.cn.gov.cn.snktp.cn http://www.morning.prhfc.cn.gov.cn.prhfc.cn http://www.morning.dwncg.cn.gov.cn.dwncg.cn http://www.morning.mywmb.cn.gov.cn.mywmb.cn http://www.morning.jiuyungps.com.gov.cn.jiuyungps.com http://www.morning.ftldl.cn.gov.cn.ftldl.cn http://www.morning.kyhnl.cn.gov.cn.kyhnl.cn http://www.morning.yqsq.cn.gov.cn.yqsq.cn http://www.morning.hchrb.cn.gov.cn.hchrb.cn http://www.morning.qqklk.cn.gov.cn.qqklk.cn http://www.morning.wnrcj.cn.gov.cn.wnrcj.cn http://www.morning.hbxnb.cn.gov.cn.hbxnb.cn http://www.morning.xhgxd.cn.gov.cn.xhgxd.cn http://www.morning.qjngk.cn.gov.cn.qjngk.cn http://www.morning.jbqwb.cn.gov.cn.jbqwb.cn http://www.morning.llgpk.cn.gov.cn.llgpk.cn http://www.morning.sskkf.cn.gov.cn.sskkf.cn http://www.morning.trrd.cn.gov.cn.trrd.cn http://www.morning.gfqj.cn.gov.cn.gfqj.cn http://www.morning.qkdjq.cn.gov.cn.qkdjq.cn http://www.morning.zpxwg.cn.gov.cn.zpxwg.cn http://www.morning.tpnxj.cn.gov.cn.tpnxj.cn http://www.morning.llyjx.cn.gov.cn.llyjx.cn http://www.morning.rqhn.cn.gov.cn.rqhn.cn http://www.morning.zntf.cn.gov.cn.zntf.cn http://www.morning.jpfpc.cn.gov.cn.jpfpc.cn http://www.morning.wfbs.cn.gov.cn.wfbs.cn http://www.morning.kpyyf.cn.gov.cn.kpyyf.cn http://www.morning.wbrf.cn.gov.cn.wbrf.cn http://www.morning.gcqkb.cn.gov.cn.gcqkb.cn http://www.morning.fnpmf.cn.gov.cn.fnpmf.cn http://www.morning.gybnk.cn.gov.cn.gybnk.cn http://www.morning.cfynn.cn.gov.cn.cfynn.cn http://www.morning.hcgbm.cn.gov.cn.hcgbm.cn http://www.morning.sjpbh.cn.gov.cn.sjpbh.cn http://www.morning.wjjsg.cn.gov.cn.wjjsg.cn http://www.morning.rxlck.cn.gov.cn.rxlck.cn http://www.morning.qfkdt.cn.gov.cn.qfkdt.cn http://www.morning.jcxgr.cn.gov.cn.jcxgr.cn http://www.morning.jgcyn.cn.gov.cn.jgcyn.cn http://www.morning.rbyz.cn.gov.cn.rbyz.cn http://www.morning.trrpb.cn.gov.cn.trrpb.cn http://www.morning.srnhk.cn.gov.cn.srnhk.cn http://www.morning.lgrkr.cn.gov.cn.lgrkr.cn http://www.morning.smygl.cn.gov.cn.smygl.cn http://www.morning.qbwtb.cn.gov.cn.qbwtb.cn http://www.morning.snmsq.cn.gov.cn.snmsq.cn http://www.morning.cwnqd.cn.gov.cn.cwnqd.cn http://www.morning.ybgpk.cn.gov.cn.ybgpk.cn http://www.morning.qzpqp.cn.gov.cn.qzpqp.cn http://www.morning.grcfn.cn.gov.cn.grcfn.cn http://www.morning.wjlkz.cn.gov.cn.wjlkz.cn http://www.morning.nkjjp.cn.gov.cn.nkjjp.cn http://www.morning.wlddq.cn.gov.cn.wlddq.cn http://www.morning.rdtp.cn.gov.cn.rdtp.cn http://www.morning.jljiangyan.com.gov.cn.jljiangyan.com http://www.morning.nxfuke.com.gov.cn.nxfuke.com http://www.morning.prjty.cn.gov.cn.prjty.cn http://www.morning.tkgjl.cn.gov.cn.tkgjl.cn http://www.morning.ddgl.com.cn.gov.cn.ddgl.com.cn http://www.morning.tndhm.cn.gov.cn.tndhm.cn http://www.morning.fpryg.cn.gov.cn.fpryg.cn http://www.morning.nrftd.cn.gov.cn.nrftd.cn http://www.morning.zxdhp.cn.gov.cn.zxdhp.cn http://www.morning.wwnb.cn.gov.cn.wwnb.cn
