Spring cloud alibaba面试题
Nacos1.x作为注册中心的原理？
底层基于netty实现。
集群数据同步使用distrio协议。
Nacos服务领域模型有哪些？
| 模型名称 | 解释 |
|---|---|
| Namespace | 实现环境隔离，默认值public，比方说DEV、SIT、UAT环境。 |
| Group | 一般用来表示某个项目。不同的service可以组成一个Group，默认值Default-Group， 同⼀个命名空间的不同分组微服务之间也是不能通信的。 如：交易分组：订单服务、支付服务 仓储分组：库存服务、物流服务 |
| Service | 服务名称 |
| DataId | 表示具体的配置文件 |
nacos集群节点数据同步问题
每个节点都维护了全量的数据，节点之间数据同步是基于distrio协议来完成的。
spring cloud config和nacos之间区别
修改了配置之后，config需要重启服务，nacos不需要。nacos有可视化的界面更加易于管理。而config是基于git来做的，没有可视化界面。
为什么Feign第一次调用耗时很长？
ribbon默认是懒加载的，只有第一次调用的时候才会生成ribbon对应的组件，这就会导致首次调用的会很慢的问题。
Feign的性能优化？
Feign底层默认是 JDK自带的HttpURLConnection，它是单线程发送HTTP请求的，不能配置线程池，我们使用Okhttp或者HttpClient来发送http请求，并且它们两个都支持线程池。
Feign怎样实现认证的传递？
实现RequestInterceptor接口重写apply方法，我们就能够对用户名和密码进行认证了。
谈谈Sentienl中使用的限流算法
1.计数器固定窗口算法，会存在临界值问题。
2.计数器滑动窗口算法，上面算法的改进，但是也不是完美的，因为具体将单位时间分为多少个格子不好说。
3.漏桶算法，不能应对突发流量。
4.令牌桶算法，可以应对一定的突发流量。
谈谈Sentienl服务熔断过程
服务熔断一般有三种状态：
熔断关闭状态（Closed）
服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制。
熔断开启状态（Open）
后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法。
半开状态（Half-Open）
尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。如果成功率达到预期，则
说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断关闭状态。
在Gateway中怎样实现服务平滑迁移？
使用Weight路由的断言工厂进行服务权重的配置，并将配置放到Nacos配置中心中，这样我们改了配置不用重启服务就能够实时生效。
spring:
cloud:
gateway:
routes:
- id: weight_high
uri: https://weighthigh.org
predicates:
- Weight=group1, 8
- id: weight_low
uri: https://weightlow.org
predicates:
- Weight=group1, 2
以上的配置说明当请求经过gateway网关的时候，会有80%的流量走 https://weighthigh.org，剩下20%的流量走https://weightlow.org。
在灰度发布的时候用的比较多。
Seata支持那些事务模式
Seata 是一款阿里巴巴开源的分布式事务解决方案。
Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
请简述2PC流程以及优缺点
下来找个视频看看吧
2PC实际项目开发中用的比较多，3PC用的少一点。
XA、TCC、AT、SAGA都是2PC(两阶段提交)
优点： 尽量保证了数据的强一致，实现成本较低，在各大主流数据库都有自己实现，对于MySQL是
从5.5开始支持(XA)。
缺点：
单点问题:事务管理器在整个流程中扮演的角色很关键，如果其宕机，比如在第一阶段已经完
成，在第二阶段正准备提交的时候事务管理器宕机，资源管理器就会一直阻塞，导致数据库无法
使用。
同步阻塞:在准备就绪之后，资源管理器中的资源一直处于阻塞，直到提交完成，释放资源。
数据不一致:两阶段提交协议虽然为分布式数据强一致性所设计，但仍然存在数据不一致性的可
能，比如在第二阶段中，假设协调者发出了事务commit的通知，但是因为网络问题该通知仅被
一部分参与者所收到并执行了commit操作，其余的参与者则因为没有收到通知一直处于阻塞状
态，这时候就产生了数据的不一致性。
Seata中xid怎样通过Feign进行全局传递
全局事务id通过Feign的header进行传递。底层是一个map结构，说白了就是将xid放到了map中去了。
分布式事务应用的典型场景
多服务
多数据源（分库分表）
请说一下CAP和BASE理论
CAP和BASE是分布式必备理论基础
这个定理的内容是指的是在一个分布式系统中、Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。要不是AP,就是CP.
BASE是Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）三个短语的缩写。BASE理论是基于CAP理论演化而来的。
BASE理论的核心思想是：**即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。****
简述Seata的AT模式两阶段过程
一阶段：开启全局事务、注册分支事务、储存全局锁、业务数据和回滚日志(undoLog)进行提交
二阶段：事务协调者根据所有分支的情况，决定本次全局事务是Commit还是Rollback (二阶段是完全异步删除undolog日志，全局事务、分支事务、储存的全局锁）。
结合代码讲解：
@GlobalTransactional // 开启全局事务,生成xid
@Transactional(rollbackFor = Exception.class) // 分支事务
public void placeOrder(String userId, String commodityCode, Integer count) {
BigDecimal orderMoney = new BigDecimal(count).multiply(new BigDecimal(5));
Order order = new Order().setUserId(userId).setCommodityCode(commodityCode).setCount(count).setMoney(
orderMoney);
orderDAO.insert(order);
stockFeignClient.deduct(commodityCode, count);
}
@Transactional(rollbackFor = Exception.class) // 分支事务
public void deduct(String commodityCode, int count) {
if (commodityCode.equals("product-2")) {
throw new RuntimeException("异常:模拟业务异常:stock branch exception");
}
QueryWrapper<Stock> wrapper = new QueryWrapper<>();
wrapper.setEntity(new Stock().setCommodityCode(commodityCode));
Stock stock = stockDAO.selectOne(wrapper);
stock.setCount(stock.getCount() - count);
stockDAO.updateById(stock);
}
简述Eureka自我保护机制
Eureka服务端会检查最近15分钟内所有Eureka 实例正常心跳占比，如果低于85%就会触发自我保护机制。触发了保护机制，Eureka将暂时把这些失效的服务保护起来，不让其过期，但这些服务也并不是永远不会过期。Eureka在启动完成后，每隔60秒会检查一次服务健康状态，如果这些被保护起来失效的服务过一段时间后（默认90秒）还是没有恢复，就会把这些服务剔除。如果在此期间服务恢复了并且实例心跳占比高于85%时，就会自动关闭自我保护机制。
简述Eureka集群架构
Register(服务注册)：把自己的 IP 和端口注册给 Eureka。
Renew(服务续约)：发送心跳包，每 30 秒发送一次。告诉 Eureka 自己还活着。
Cancel(服务下线)：当 provider 关闭时会向 Eureka 发送消息，把自己从服务列表中删除。防
止 consumer 调用到不存在的服务。
Get Registry(获取服务注册列表)：获取其他服务列表。
Make Remote Call(远程调用)：完成服务的远程调用。
Replicate(集群中数据同步)：eureka 集群中的数据复制与同步。
注意：Eureka集群中每个实例并不保存全量的数据。
从Eureka迁移到Nacos的解决方案
pom文件中添加nacos的依赖。
然后修改yaml配置
最后将启动类上的注解进行修改@EnabledEurekaClient 改为 @EnabledDiscoveryClient.
Zuul有几种过滤器类型?分别是?
zuul 有四种过滤器类型，分别是：
1、Pre：过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求
的微服务、记录调试信息等；
2、Routing：过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用
Apache HttpClient或Netfilx feign请求微服；
3、Post：过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收
集统计信息和指标、将响应从微服务发送给客户端；
4、Error：在其他阶段发生错误时执行该过滤器。除了默认的过滤器类型微服务；
总结：路由之前、路由中、路由后、发生错误。
标签：面试题,调用,服务,Spring,事务,Eureka,路由,过滤器,cloud From： https://www.cnblogs.com/dongyaotou/p/18406566