1.在Zuul中如何做限流
方式一:可以通过继承ZuulFilter抽象类自定义pre过滤器,加上限流算法,来实现
方式二:可以通过hystrix的资源隔离模式,设置线程池最大连接数或者最大信号量来实现
方式三:常用,Ratelimit,使用令牌桶算法。。。
2.配置中心解决什么问题
在分布式系统中,服务数量很多,而每个服务都有自己的配置文件,管理起来很麻烦。配置中心是个好东西,可以帮我们集中管理配置文件,它支持本地配置文件,也支持将配置文件放到远程仓库如git集中管理。
3.EureakServer的搭建流程
第一步,导入eureka-server依赖,以及springboot的web环境依赖。
第二布,主启动类上打注解,@EnableEurekaServer,开启eureka服务端功能
第三步,yml配置文件中,配置注册中心的端口号,主机名,注册中心地址
4.Ribbon的整合流程
第一步,导入ribbon依赖
第二部,给RestTemplate的Bean定义方法上,加上注解@LoadBalanced,让这个restTemplate有负载均衡的功能
第三步,修改restTemplate调用服务的url,将目标主机名换成目标服务名
5.Feign的整合流程
第一步,导入openfeign依赖
第二部,主配置类加注解,@EnableFeignClients,开启feign支持
第三步,定义feign客户端接口,并加上注释@FeignClient("目标服务名"),接口中定义方法,该方法与目标服务的对应方法的方法名,返回值类型,形参列表,url路径要一致
6.Hystrix的整合流程
第一步,导入hystrix依赖
第二部,主启动类加注解,@EnableCircuitBreaker,开启熔断功能
第三步,在需要开启熔断功能的方法上,加注解@HystrixCommand(fallbackMethod="xxx"),xxx是降级方法
第四步,定义降级方法,方法名需要和fallbackMethod的值一致,形参列表和返回值类型需要和目标方法一致
7.Zuul的整合流程
第一步,导入zuul依赖
第二步,主启动类上加注解@EnableZuulProxy,开启zuul功能
第三步,yml中配置,统一访问前缀prefix,禁用通过服务名方式访问服务ignoredServices,配置路由routes指定某个服务使用某个路径来访问
8.ConfigServer的整合流程
配置中心服务端配置:
第一步,导入config-server依赖
第二步,主启动类加注解,@EnableConfigServer,开启配置中心
第三步,配置文件中,配置远程仓库地址,仓库账号密码
客户端配置:
第一步,导入config-client依赖
第二步,创建bootstrap.yml配置文件,配置中心地址config.uri,要拉取的配置文件名name,环境名profile
9.你们微服务项目的技术栈描述一下
前端门户系统:HTML + JQuery + CSS
前端管理系统:VUE + ElementUI
后端系统:基于SpringCloud微服务框架(Eureka+OpenFeign+Hystrix+Zuul+Config)
+MyBatisPlus+SpringMVC+Redis+ElasticSearch+RabbitMQ+AlicloudOSS
10.浏览器发起一个请求,在你的微服务项目中的怎么
去执行的
浏览器发起的所有请求首先通过Nginx,通过负载均衡算法,路由给zuul集群,然后通过zuul前置过滤,作登录校验后,它会从配置中心拉取的通讯地址中,根据url匹配到对应的服务,然后使用ribbon发起restful调用。微服务间也可以通过feign相互调用,最终执行完任务,返回浏览器
1.说下Ribbonz和Feign的区别呢
Ribbon和Feign都是SpringCloud Netflix中实现负载均衡的组件,不同点在于
Ribbon是需要我们手动构建http请求,根据目标服务名通过负载均衡算法直接调用目标服务,
Feign是采用接口的方式,将需要调用的目标服务方法定义成抽象方法,路径,服务名,形参列表,返回值类型需要保持一致。我们只需要调用接口中的方法就可以了。它会自动帮我们生成jdk动态代理,为每个方法生成RequestTemplate并封装url和请求参数,使用负载均衡算法发起调用
Ribbon的实现方式,一般配合RestTemplate发起http请求,我们需要在注册RestTemplate的Bean的方法上加@LoadBalanced,使它具有负载均衡的能力
Feign的实现方式,是在主启动类上加@EnableFeignClients,在客户端接口上加注解@FeignClient
2.Spring,SpringBoot和SpringCloudl的关系以及区别
Spring是一个开源的轻量级控制反转和面向切面编程的容器框架。轻量级是说它开发使用简单,功能强大。控制反转是指将对象的创建,销毁控制交给ioc容器,方便解耦合,降低维护难度,面向切面编程是指将相同的逻辑横向抽取出来,可以对一些通用业务如事务,日志进行集中管理。
Springboot是一个基于spring的框架,对spring做了大量简化,使开发流程更快,更高效。比如它大量简化maven依赖,基于注解配置(JavaConfig)无需XML,内嵌Tomcat,部署流程简单,打包和部署更加灵活,允许独立运行
SpringCloud是基于SpringBoot实现的,用于微服务架构中管理和协调服务的,它是一系列框架的有序集合,它为开发者提供了一系列工具,例如服务发现与注册,配置中心,网关,负载均衡,熔断器,链路追踪等等,让微服务架构落地变得更简单
3.什么是分布式事务
分布式事务,指的是在分布式环境中,一个请求可能涉及到对多个数据库的写操作,要保证多数据库的一致性就需要用到分布式事务
4.分布式事务你知道哪些解决方案?这些方案如何选型
常见的分布式事务解决方案,2PC,TCC,可靠消息最终一致性,最大努力通知
2PC,它将整个事务流程分为两个阶段,P指的是准备阶段,C指的是提交阶段。它是一个阻塞协议,不适用于并发较高,事务生命周期长的分布式事务。
TCC,它是基于补偿性事务的AP系统的一种实现,补偿也就是说先按照预定方案执行,如果失败了就走补偿方案。它可以自己定义数据操作的粒度,但是对应用的侵入性强,可以用在登录送积分,送优惠券等等场景
可靠消息最终一致性,指的是当事务发起方执行完本地事务后,就发出一条消息通知其他参与方,并且他们一定能接收到消息并处理事务。适合执行周期长,并且实时性要求不高的场景
最大努力通知,是在不影响主业务的情况下,尽可能的保证数据的一致性,它适用于一些最终一致性敏感度低的业务,比如支付结果通知
5.什么是2pc
2PC,是将整个事务流程分为两个阶段,P指的是准备阶段,C指的是提交阶段。它常见的标准有XA,JTA,Seata
由DTP模型定义事务管理器TM和资源管理器RM之间通讯的接口规范叫做XA,它规定的交互方式是酱紫的:应用程序AP通过TM提交和回滚事务,TM通过XA接口来通知RM数据库事务的开始,结束,提交,回滚
2PC能保证分布式事务的原子性,但是也有很多缺陷
比如,在第一阶段,如果参与者迟迟不回复协调者,就会造成事务的阻塞,性能不好
比如,在第二阶段,如果事务协调者发出提交事务指令后宕机,一部分参与者收到消息提交了事务,另一部分没有收到消息没有提交事务,这就会导致数据不一致
再比如,在第二阶段,如果事务协调者发出提交事务指令后宕机,收到指令的参与者也宕机了,我们就不能确定事务的执行结果,究竟有没有提交
6.Seata相比传统2PC有什么区别,以及优点
Seata是由阿里中间件团队发起的开源项目Fescar更名而来,是一个开源的分布式事务框架,它通过对本地关系数据库的分支事务协调,来驱动完成全局事务
Seata的主要优点是性能好,不会长时间占用链接资源,对业务零入侵
与传统的2PC的区别主要两方面
在架构层次方面,传统的2PC方案的RM本质就是数据库自身,而Seata的RM是以jar包形式作为中间件层部署在应用程序上
在两阶段提交上方面,传统2PC方案是在第二阶段完成才释放资源,而Seata是在第一阶段就将本地事务提交,提高了效率
7.Seata的TC,TM,RM的含义,以及作用
TC:事务协调器,它是独立的中间件,需要独立部署运行,它维护全局事务的运行状态,接收TM指令发起全局事务的提交与回滚,负责与RM通信协调各各分支事务的提交或回滚
TM:事务管理器,TM需要嵌入应用程序中工作,它负责开启一个全局事务,并最终向TC发起全局提交或全局回滚的指令
RM:控制分支事务,负责分支注册、状态汇报,并接收事务协调器TC的指令,驱动分支事务的提交和回滚
8.你知道TCC吗,它有什么样的优缺点
TCC是基于补偿型事务的AP系统的一种实现。补偿指的先按照事先预定的方案去执行,如果失败了就走补偿方案
它的优点是异步执行效率高,它能对分布式事务中的各个资源分别锁定,分别提交与释放
它的缺点是对应用的侵入性强,改动成本高,实现难度大
9.解释一下Seatal的工作原理
Seata有三个角色:
TM任务管理器,负责开启,提交,回滚事务的发起,
TC事务协调器 ,接收TM的指令通知RM提交或者回滚事务
RM资源管理器,控制着分支事务的提交和回滚
假设有服务A需要调用服务B,且两个服务都需要修改各自的数据库,A服务作为程序入口充当TM和RM,B服务控制着分支事务充当RM。
A服务的TM向TC申请开启一个全局事务,全局事务创建成功并生成一个全局唯一的XID
A服务的RM向TC注册分支事务,并将其纳入XID对应全局事务的管辖
A服务执行分支事务,写undolog日志,向TC上报事务状态
当调用B服务时,B服务的RM向TC注册分支事务,该分支事务执行,然后写undolog,向TC上报事务状态
服务执行完毕A服务的TM向TC发送commit或者rollback指令
TC接收到指令,向参与事务的RM发送指令
事务参与者RM受到commit指令,删除undolog日志。 如果是rollback指令就根据undolog回滚
10.你能简单描述一下你在项目中是如何集成Seata的吗
事务协调器:安装并启动Seata客户端
主业务端:
第一步,导入Seata依赖
第二步,yml中配置事务组名,同时需要添加配置文件file.conf,registry.conf,需要注意yml中事务组名与file.comf中的事务组名一致
第三步,配置DataSource,需要适用Seata对DataSource进行代理
第四步,数据库中添加undo log日志表
第五步,业务方法上加注解@GlobalTransactional(rollbackFor = Exception.class)注解
事务参与者:
前四步与主业务端相同,第五步不需要了
没有Seata或者TCC这些事务框架,你可以怎么处理事务?
不用框架就要自己实现,如果业务要求强一致性这个不太好做,需要协调多个数据库的同时提交和回滚.如果是业务不要求强一致性,我可以参照TCC思想 ,可以考虑自己实现异步写数据库方案,如果失败可以做补偿.当然这个要根据业务特性来,很多大公司都是自己封装事务框架.
11.Nacos,原理
Nacos是一个开源的动态服务发现、配置管理和服务管理平台,支持多种运行环境跨语言的服务和应用。Nacos提供了一套简单易用的UI界面对微服务进行配置管理、服务治理等,并支持客户端的动态发现和配置更新。Nacos具有高可扩展性、高可用性、高性能和卓越的扩展性等特点。
Nacos基于三个基本功能:服务发现、配置管理和服务管理。其中,服务发现是指服务提供方将自己的服务注册到Nacos,服务消费方从Nacos上根据服务名称、IP、端口号等关键信息查询所需服务的地址列表,然后实现动态负载均衡;配置管理是指将配置文件信息存储在Nacos中,程序运行时从Nacos中动态加载配置信息;服务管理是指在Nacos中管理各个服务,包括服务的监控、统计、追踪等。
Nacos的架构包括三个核心模块:命名服务、配置服务和分布式存储服务。其中,命名服务是服务注册与发现的基础,配置服务是配置管理的基础,分布式存储服务则是保证高可用和扩展性的基础。
Nacos的原理是基于Raft协议实现的共识算法,确保各个节点的数据一致性。同时,在服务注册和发现方面,以数据持久化的方式实现,支持多种存储方式。Nacos服务发现、配置管理和服务管理等功能的实现,主要借助于大规模的集群架构,并且使用ACID事务模型和MVCC并发控制模型。
简单来说,Nacos能够实现动态服务发现、配置管理和服务管理,借助大规模的集群架构来保证高可用和并发控制。