SpringCloud
时小浅
折腾数据.折腾代码.折腾规约.折腾架构.折腾需求.折腾服务.生命不息.折腾不止.
展开
-
认识Sentinel 流量规则模块
Sentinel 流量规则模块系统并发能⼒有限,⽐如系统A的QPS⽀持1个,如果太多请求过来,那么A就应该进⾏流量控制了,⽐如其他请求直接拒绝资源名:默认请求路径针对来源:Sentinel可以针对调⽤者进⾏限流,填写微服务名称,默认default(不区分来源)阈值类型/单机阈值QPS:(每秒钟请求数量)当调⽤该资源的QPS达到阈值时进⾏限流线程数:当调⽤该资源的线程数达到阈值的时候进⾏限流(线程处理请求的时候,如果说业务逻辑执⾏时间很⻓,流量洪峰来临时,会耗费很多线程资源,这些线程资源会堆积.原创 2020-10-07 15:48:24 · 170 阅读 · 0 评论 -
SCA Sentinel 分布式系统的流量防卫兵
Sentinel 介绍Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。替代Hystrix,针对问题:服务雪崩、服务降级、服务熔断、服务限流Hystrix:服务消费者(⾃动投递微服务)—>调⽤服务提供者(简历微服务)在调⽤⽅引⼊Hystrix—> 单独搞了⼀个Dashboard项⽬—>Turbine1)⾃⼰搭建监控平台 dashboard2)没有提供UI界⾯进⾏服务熔断、服务降级等配置(⽽是写代码,⼊侵了我们源程序环境)Sentinel: 1)独⽴可部署D原创 2020-10-03 15:09:59 · 147 阅读 · 0 评论 -
SCA Nacos 配置中⼼
之前:Spring Cloud Config + Bus1) Github 上添加配置⽂件2)创建Config Server 配置中⼼—>从Github上去下载配置信息3)具体的微服务(最终使⽤配置信息的)中配置Config Client—> ConfigServer获取配置信息有Nacos之后,分布式配置就简单很多Github不需要了(配置信息直接配置在Nacos server中),Bus也不需要了(依然可以完成动态刷新)接下来1、去Nacos server中添加配置信息2、改原创 2020-10-03 15:01:43 · 281 阅读 · 0 评论 -
SCA Nacos 服务注册
Nacos 介绍Nacos (Dynamic Naming and Configuration Service)是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。Nacos就是注册中⼼+配置中⼼的组合(Nacos=Eureka+Config+Bus)官⽹:https://nacos.io 下载地址:https://github.com/alibaba/NacosNacos功能特性服务发现与健康检查动态配置管理动态DNS服务服务和元数据管理(管理平台的⻆度,nacos也有⼀原创 2020-10-03 14:56:14 · 227 阅读 · 0 评论 -
Spring Cloud OAuth2 + JWT微服务统⼀认证⽅案
认证:验证⽤户的合法身份,⽐如输⼊⽤户名和密码,系统会在后台验证⽤户名和密码是否合法,合法的前提下,才能够进⾏后续的操作,访问受保护的资源微服务架构下统⼀认证场景分布式系统的每个服务都会有认证需求,如果每个服务都实现⼀套认证逻辑会⾮常冗余,考虑分布式系统共享性的特点,需要由独⽴的认证服务处理系统认证的请求微服务架构下统⼀认证思路基于Session的认证⽅式在分布式的环境下,基于session的认证会出现⼀个问题,每个应⽤服务都需要在session中存储⽤户身份信息,通过负载均衡将本地的请求分配到原创 2020-10-03 11:19:30 · 221 阅读 · 0 评论 -
分布式链路追踪技术适⽤场景和技术核⼼思想
分布式链路追踪技术适⽤场景(问题场景)场景描述为了⽀撑⽇益增⻓的庞⼤业务量,我们会使⽤微服务架构设计我们的系统,使得我们的系统不仅能够通过集群部署抵挡流量的冲击,⼜能根据业务进⾏灵活的扩展。那么,在微服务架构下,⼀次请求少则经过三四次服务调⽤完成,多则跨越⼏⼗个甚⾄是上百个服务节点。那么问题接踵⽽来:1)如何动态展示服务的调⽤链路?(⽐如A服务调⽤了哪些其他的服务—依赖关系)2)如何分析服务调⽤链路中的瓶颈节点并对其进⾏调优?(⽐如A—>B—>C,C服务处理时间特别⻓)3)如何快速进原创 2020-10-03 10:47:42 · 936 阅读 · 2 评论 -
Spring Cloud 各组件超时
在SpringCloud中,应⽤的组件较多,只要涉及通信,就有可能会发⽣请求超时。那么如何设置超时时间? 在 Spring Cloud 中,超时时间只需要重点关注 Ribbon 和 Hystrix 即可。Ribbon如果采⽤的是服务发现⽅式,就可以通过服务名去进⾏转发,需要配置Ribbon的超时。Ribbon的超时可以配置全局的ribbon.ReadTimeout和ribbon.ConnectTimeout。也可以在前⾯指定服务名,为每个服务单独配置,⽐如 user-service.ribbon.Re原创 2020-10-03 10:39:35 · 250 阅读 · 0 评论 -
Eureka 服务发现慢的原因,Spring Cloud 超时设置问题
问题场景上线⼀个新的服务实例,但是服务消费者⽆感知,过了⼀段时间才知道某⼀个服务实例下线了,服务消费者⽆感知,仍然向这个服务实例在发起请求这其实就是服务发现的⼀个问题,当我们需要调⽤服务实例时,信息是从注册中⼼Eureka获取的,然后通过Ribbon选择⼀个服务实例发起调⽤,如果出现调⽤不到或者下线后还可以调⽤的问题,原因肯定是服务实例的信息更新不及时导致的。Eureka 服务发现慢的原因Eureka 服务发现慢的原因主要有两个,⼀部分是因为服务缓存导致的,另⼀部分是因为客户端缓存导致的。服务原创 2020-10-03 10:38:49 · 2720 阅读 · 3 评论 -
断路监控仪表盘Hystrix Dashboard
正常状态是UP,跳闸是⼀种状态CIRCUIT_OPEN,可以通过/health查看,前提是⼯程中需要引⼊SpringBoot的actuator(健康监控),它提供了很多监控所需的接⼝,可以对应⽤系统进⾏配置查看、相关功能统计等。已经统⼀添加在⽗⼯程中<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</a原创 2020-09-18 11:17:29 · 106 阅读 · 0 评论 -
Hystrix⼯作流程原理
1)当调⽤出现问题时,开启⼀个时间窗(10s)2)在这个时间窗内,统计调⽤次数是否达到最⼩请求数?如果没有达到,则重置统计信息,回到第1步如果达到了,则统计失败的请求数占所有请求数的百分⽐,是否达到阈值?如果达到,则跳闸(不再请求对应服务)如果没有达到,则重置统计信息,回到第1步3)如果跳闸,则会开启⼀个活动窗⼝(默认5s),每隔5s,Hystrix会让⼀个请求通过,到达那个问题服务,看 是否调⽤成功,如果成功,重置断路器回到第1步,如果失败,回到第3步/** * 8秒钟内,请求次数达到2.原创 2020-09-18 11:11:48 · 113 阅读 · 1 评论 -
Hystrix舱壁模式(线程池隔离策略)
如果不进⾏任何设置,所有熔断⽅法使⽤⼀个Hystrix线程池(10个线程),那么这样的话会导致问题,这个问题并不是扇出链路微服务不可⽤导致的,⽽是我们的线程机制导致的,如果⽅法A的请求把10个线程都⽤了,⽅法2请求处理的时候压根都没法去访问B,因为没有线程可⽤,并不是B服务不可⽤为了避免问题服务请求过多导致正常服务⽆法访问,Hystrix 不是采⽤增加线程数,⽽是单独的为每⼀个控制⽅法创建⼀个线程池的⽅式,这种模式叫做“舱壁模式",也是线程隔离的⼿段。我们可以使⽤⼀些⼿段查看线程情况 @Get.原创 2020-09-18 11:08:56 · 1154 阅读 · 0 评论 -
容错机制 Hystrix熔断器
Hystrix(豪猪----->刺)宣⾔“defend your app”是由Netflix开源的⼀个延迟和容错库,⽤于隔离访问远程系统、服务或者第三⽅库,防⽌级联失败,从⽽提升系统的可⽤性与容错性。Hystrix主要通过以下⼏点实现延迟和容错。包裹请求:使⽤HystrixCommand包裹对依赖的调⽤逻辑。 ⾃动投递微服务⽅法(@HystrixCommand 添加Hystrix控制) ——调⽤简历微服务跳闸机制:当某服务的错误率超过⼀定的阈值时,Hystrix可以跳闸,停⽌请求该服务⼀段时原创 2020-09-18 11:03:01 · 110 阅读 · 0 评论 -
微服务中的雪崩效应
微服务中的雪崩效应什么是微服务中的雪崩效应呢?微服务中,⼀个请求可能需要多个微服务接⼝才能实现,会形成复杂的调⽤链路扇⼊:代表着该微服务被调⽤的次数,扇⼊⼤,说明该模块复⽤性好扇出:该微服务调⽤其他微服务的个数,扇出⼤,说明业务逻辑复杂扇⼊⼤是⼀个好事,扇出⼤不⼀定是好事在微服务架构中,⼀个应⽤可能会有多个微服务组成,微服务之间的数据交互通过远程过程调⽤完成。这就带来⼀个问题,假设微服务A调⽤微服务B和微服务C,微服务B和微服务C⼜调⽤其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某个微原创 2020-09-18 10:59:47 · 1027 阅读 · 0 评论 -
认识 Ribbon负载均衡
关于负载均衡负载均衡⼀般分为服务器端负载均衡和客户端负载均衡所谓服务器端负载均衡,⽐如Nginx、F5这些,请求到达服务器之后由这些负载均衡器根据⼀定的算法将请求路由到⽬标服务器处理。所谓客户端负载均衡,⽐如我们要说的Ribbon,服务消费者客户端会有⼀个服务器地址列表,调⽤⽅在请求前通过⼀定的负载均衡算法选择⼀个服务器进⾏访问,负载均衡算法的执⾏是在请求客户端进⾏。Ribbon是Netflix发布的负载均衡器。Eureka⼀般配合Ribbon进⾏使⽤,Ribbon利⽤从Eureka中读取到服务信息原创 2020-09-14 23:34:28 · 118 阅读 · 0 评论 -
Eureka Client注册服务 启动流程
启动过程:Eureka客户端在启动时也会装载很多配置类,我们通过spring-cloud-netflix-eureka-client-2.1.0.RELEASE.jar下的spring.factories⽂件可以看到加载的配置类使用了Springboot 的自动配置 重点关注:EurekaClientAutoConfiguration引⼊jar就会被⾃动装配,分析EurekaClientAutoConfiguration类头@AutoConfigureBefore 必须先把配置的bean装配完,原创 2020-09-14 23:25:41 · 1037 阅读 · 0 评论 -
初步认识Eureka Server服务接⼝暴露策略
在Eureka Server启动过程中主配置类注册了Jersey框架(是⼀个发布restful⻛格接⼝的框架,类似于我们的springmvc)启动时就要注册 Jersey filter /** * Register the Jersey filter * 启动时就要注册 Jersey filter */ @Bean public FilterRegistrationBean jerseyFilterRegistration( javax.ws.rs.core.Application原创 2020-09-14 22:52:18 · 137 阅读 · 0 评论 -
Eureka Server启动过程(详细的源码剖析)
⼊⼝:SpringCloud充分利⽤了SpringBoot的⾃动装配的特点观察eureka-server的jar包,发现在META-INF下⾯有配置⽂件spring.factoriesspringboot应⽤启动时会加载EurekaServerAutoConfiguration⾃动配置类EurekaServerAutoConfiguration类⾸先观察类头分析/** * @author Gunnar Hillert * @author Biju Kunjummen * @author原创 2020-09-13 22:31:17 · 471 阅读 · 0 评论 -
Eureka的那些细节
Eureka元数据Eureka的元数据有两种:标准元数据和⾃定义元数据。标准元数据:主机名、IP地址、端⼝号等信息,这些信息都会被发布在服务注册表中,⽤于服务之间的调⽤。⾃定义元数据:可以使⽤eureka.instance.metadata-map配置,符合KEY/VALUE的存储格式。这 些元数据可以在远程客户端中访问。instance: prefer-ip-address: true metadata-map: # ⾃定义元数据(kv⾃定义) cluster: cl1 region:原创 2020-09-13 21:37:52 · 129 阅读 · 0 评论 -
Eureka 服务注册中⼼组件
服务注册中⼼的⼀般原理、对⽐了主流的服务注册中⼼⽅案⽬光聚焦EurekaEureka 交互流程及原理Eureka 包含两个组件:Eureka Server 和 Eureka Client,Eureka Client是⼀个Java客户端,⽤于简化与Eureka Server的交互;Eureka Server提供服务发现的能⼒,各个微服务启动时,会通过Eureka Client向Eureka Server 进⾏注册⾃⼰的信息(例如⽹络信息),Eureka Server会存储该服务的信息;1)图中us原创 2020-09-13 21:28:50 · 123 阅读 · 0 评论 -
认识服务注册中⼼
关于服务注册中⼼注意:服务注册中⼼本质上是为了解耦服务提供者和服务消费者。对于任何⼀个微服务,原则上都应存在或者⽀持多个提供者(⽐如简历微服务部署多个实例),这是由微服务的分布式属性决定的。更进⼀步,为了⽀持弹性扩缩容特性,⼀个微服务的提供者的数量和分布往往是动态变化的,也是⽆法预先确定的。因此,原本在单体应⽤阶段常⽤的静态LB机制就不再适⽤了,需要引⼊额外的组件来管理微服务提供者的注册与发现,⽽这个组件就是服务注册中⼼。服务注册中⼼⼀般原理分布式微服务架构中,服务注册中⼼⽤于存储服务提供者地址信原创 2020-09-13 21:23:21 · 138 阅读 · 0 评论 -
进一步了解Spring Cloud
Spring Cloud 是什么Spring Cloud是⼀系列框架的有序集合。它利⽤Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中⼼、消息总线、负载均衡、断路器、数据监控等,都可以⽤ Spring Boot的开发⻛格做到⼀键启动和部署。Spring Cloud并没有重复制造轮⼦,它只是将前各家公司开发的⽐较成熟、经得起实际考验的服务框架组合起来,通过Spring Boot⻛格进⾏再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了⼀套简单易懂、易部署和易原创 2020-09-13 21:15:01 · 72 阅读 · 0 评论 -
认识微服务架构中的⼀些概念
服务注册与服务发现服务注册服务提供者将所提供服务的信息(服务器IP和端⼝、服务访问协议等)注册/登记到注册中⼼服务发现服务消费者能够从注册中⼼获取到较为实时的服务列表,然后根究⼀定的策略选择⼀个服务访问负载均衡负载均衡即将请求压⼒分配到多个服务器(应⽤服务器、数据库服务器等),以此来提⾼服务的性能、可靠性熔断熔断即断路保护。微服务架构中,如果下游服务因访问压⼒过⼤⽽响应变慢或失败,上游服务为了保护系统整体可⽤性,可以暂时切断对下游服务的调⽤。这种牺牲局部,保全整体的措施就叫做熔断。原创 2020-09-13 21:05:37 · 458 阅读 · 0 评论 -
微服务架构体现的思想及优缺点
微服务架构设计的核⼼思想就是“微”,拆分的粒度相对⽐较⼩,这样的话单⼀职责、开发的耦合度就会降低、微⼩的功能可以独⽴部署扩展、灵活性强,升级改造影响范围⼩。单体应⽤(1.7—>1.8)A(升级JDK) B C D E …微服务架构的优点: 微服务架构和微服务微服务很⼩,便于特定业务功能的聚焦 A B C D微服务很⼩,每个微服务都可以被⼀个⼩团队单独实施(开发、测试、部署上线、运维),团队合作⼀定程度解耦,便于实施敏捷开发微服务很⼩,便于重⽤和模块之间的组装微服务很独⽴,那么不同的微服原创 2020-09-13 20:50:34 · 476 阅读 · 0 评论 -
springcloud微服务实施整体架构方案梳理
整体方案架构图如下所示:平台服务2.1平台基础服务说明生产环境平台基础服务都需要保证高可用2.1.1 MySQL数据库MySQL5.5以上版本 或者 5.5.5-10.3.10-MariaDB数据库已经按业务领域进行了分库操作,不同的微服务对应独立的Database2.1.2 MongoDB数据库版本要求:4.0以上版本存储一些文档型数据,部分业务有用到2.1.3 业务Redis服务集群版本要求:5.0平台其他业务数据的缓存、分布式ID、 分布式锁相关业务此服务不需要持久化数据原创 2020-08-13 21:43:51 · 983 阅读 · 0 评论