客户关系管理的重要性,网站seo培训,百度指数人群画像,wordpress站点演示1、什么是Spring Cloud#xff1f; Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序#xff0c;提供与外部系统的集成#xff0c;更专注于服务治理。Spring cloud Task#xff0c;一个生命周期短暂的微服务框架#xff0c;用于快速构建执行有限数… 1、什么是Spring Cloud Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序提供与外部系统的集成更专注于服务治理。Spring cloud Task一个生命周期短暂的微服务框架用于快速构建执行有限数据处理的应用程序。 2、Spring Cloud和Dubbo的区别 Dubbo关注的领域是Spring Cloud的一个子集。Dubbo专注于服务治理其在服务治理、灰度发布、流量分发方面比Spring Cloud更全面。Spring Cloud覆盖整个微服务架构领域。Dubbo使用RPC调用效率高一些Spring Cloud使用HTTP调用效率低使用更简单。3、REST和RPC的区别 REST风格的系统交互更方便RPC调用服务提供方和调用方式之间依赖太强。REST调用系统性能较低RPC调用效率比REST高。REST的灵活性可以跨系统跨语言调用RPC只能在同语言内调用。REST可以和Swagger等工具整合自动输出接口API文档。4、SpringCloud如何实现服务的注册和发现 服务在发布时 指定对应的服务名服务名包括了IP地址和端口 将服务注册到注册中心eureka或者zookeeper。这一过程是springcloud自动实现 只需要在main方法添加EnableDisscoveryClient 同一个服务修改端口就可以启动多个实例。调用方法传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用ribbon和feign对应的服务。5、什么是服务熔断和服务降级 熔断机制是应对雪崩效应的一种微服务链路保护机制。当某个微服务不可用或者响应时间太长时会进行服务降级进而熔断该节点微服务的调用快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现Hystrix会监控微服务间调用的状况当失败的调用到一定阈值缺省是5秒内调用20次如果失败就会启动熔断机制。服务降级一般是从整体负荷考虑。就是当某个服务熔断之后服务器将不再被调用此时客户端可以自己准备一个本地的fallback回调返回一个缺省值。这样做虽然会出现局部的错误但可以避免因为一个服务挂机而影响到整个架构的稳定性。
Hystrix相关注解
EnableHystrix开启熔断HystrixCommand(fallbackMethod”XXX”)声明一个失败回滚处理函数XXX当被注解的方法执行超时默认是1000毫秒就会执行fallback函数返回错误提示。6、项目中zuul常用的功能 提供动态路由提供安全、鉴权处理跨域处理全局动态路由的hystrix(熔断、降级、限流)处理7、服务网关的作用 简化客户端调用复杂度统一处理外部请求。数据裁剪以及聚合根据不同的接口需求对数据加工后对外。多渠道支持针对不同的客户端提供不同的网关支持。遗留系统的微服务化改造可以作为新老系统的中转组件。统一处理调用过程中的安全、权限问题。
Spring Cloud中的网关有Zuul和Spring Cloud Gateway最新版本中推荐使用后者。 8、ribbon和feign区别 Ribbon添加maven依赖 spring-starter-ribbon 使用RibbonClient(value服务名称) 使用RestTemplate调用远程服务对应的方法。feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口 调用方使用 在接口上使用FeignClient(指定服务名)
Ribbon和Feign的区别
Ribbon和Feign都是用于调用其他服务的不过方式不同。
启动类使用的注解不同Ribbon用的是RibbonClientFeign用的EnableFeignClients。服务的指定位置不同Ribbon是在RibbonClient注解上声明Feign则是在定义抽象方法的接口中使用FeignClient声明。调用方式不同Ribbon需要自己构建http请求模拟http请求然后使用RestTemplate发送给其他服务步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进采用接口的方式将需要调用的其他服务的方法定义成抽象方法即可
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。 9、ribbon的负载均衡策略 RoundRobinRule: 轮询策略Ribbon以轮询的方式选择服务器这个是默认值。所以示例中所启动的两个服务会被循环访问;RandomRule: 随机策略也就是说Ribbon会随机从服务器列表中选择一个进行访问;BestAvailableRule: 最大可用策略即先过滤出故障服务器后选择一个当前并发请求数最小的;WeightedResponseTimeRule: 带有加权的轮询策略对各个服务器响应时间进行加权处理然后在采用轮询的方式来获取相应的服务器;AvailabilityFilteringRule: 可用过滤策略先过滤出故障的或并发请求大于阈值的一部分服务实例然后再以线性轮询的方式从过滤后的实例清单中选出一个;ZoneAvoidanceRule: 区域感知策略先使用主过滤条件区域负载器选择最优区域对所有实例过滤并返回过滤后的实例清单依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤判断最小过滤数默认1和最小过滤百分比默认0最后对满足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。10、简述什么是CAP,并说明Eureka包含CAP中的哪些? CAP理论一个分布式系统不可能同时满足C (一致性),A(可用性),P(分区容错性).由于分区容错性P在分布式系统中是必须要保证的,因此我们只能从A和C中进行权衡.
Eureka 遵守 AP
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,神域的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka 注册或查询是如果发现连接失败,则会自动切换至其他节点只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查的信息可能不最新的不保证强一致性)。11、Eureka和zookeeper都可以提供服务注册与发现的功能请说说两个的区别 Zookeeper保证了CPC一致性P分区容错性Eureka保证了APA高可用
当向注册中心查询服务列表时我们可以容忍注册中心返回的是几分钟以前的信息但不能容忍直接down掉不可用。也就是说服务注册功能对高可用性要求比较高但zk会出现这样一种情况当master节点因为网络故障与其他节点失去联系时剩余节点会重新选leader。问题在于选取leader时间过长30 ~ 120s且选取期间zk集群都不可用这样就会导致选取期间注册服务瘫痪。在云部署的环境下因网络问题使得zk集群失去master节点是较大概率会发生的事虽然服务能够恢复但是漫长的选取时间导致的注册长期不可用是不能容忍的。Eureka保证了可用性Eureka各个节点是平等的几个节点挂掉不会影响正常节点的工作剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败则会自动切换到其他节点只要有一台Eureka还在就能保证注册服务可用只是查到的信息可能不是最新的。除此之外Eureka还有自我保护机制如果在15分钟内超过85%的节点没有正常的心跳那么Eureka就认为客户端与注册中心发生了网络故障此时会出现以下几种情况
Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。Eureka仍然能够接受新服务的注册和查询请求但是不会被同步到其他节点上即保证当前节点仍然可用。当网络稳定时当前实例新的注册信息会被同步到其他节点。
因此Eureka可以很好的应对因网络故障导致部分节点失去联系的情况而不会像Zookeeper那样使整个微服务瘫痪。 12、链路跟踪Sleuth 当我们项目中引入Spring Cloud Sleuth后每次链路请求都会添加一串追踪信息格式是[server-name, main-traceId,sub-spanId,boolean]
server-name服务结点名称。main-traceId一条链路唯一的ID为TraceID。sub-spanId链路中每一环的ID为SpanID。boolean是否将信息输出到Zipkin等服务收集和展示。
Sleuth的实现是基于HTTP的为了在数据的收集过程中不能影响到正常业务Sleuth会在每个请求的Header上添加跟踪需求的重要信息。这样在数据收集时只需要将Header上的相关信息发送给对应的图像工具即可图像工具根据上传的数据按照Span对应的逻辑进行分析、展示。
