作者:fjfzfisher | 来源:互联网 | 2023-07-11 05:50
一、SpringCloud相关知识1.SpringCloud架构图2.Eureka原理答:Eureka两大核心功能:服务的发现与注册、心跳和故障。3.
一、SpringCloud 相关知识
1. Spring Cloud 架构图
2. Eureka 原理
答:Eureka两大核心功能:服务的发现与注册、心跳和故障。
3. Eureka 集群原理
答:Eureka集群是peer to peer模式,也就是说集群中的每个Eureka实例是平等的,每个实例都可以进行服务的发现和注册,这点与ZooKeeper是不同的。
4. Eureka和ZooKeeper的区别
答:
- 集群模式不同:Eureka是peer to peer模式,ZooKeeper是leader - follower模式。
- 一致保障性不同:
什么是CAP?
答:C是一致性,A是可用性,P是分区容错性。
Eureka可以保障AP,ZooKeeper可以保障CP。
当Eureka集群中一台机器“死掉”时,调用者仍可在Eureka其他节点中获取注册表,但是这个注册表可能不是最新的数据。因为假设当服务A向Eureka-1注册时,Eureka-1死掉了,它还没来及将服务A的数据同步给其他Eureka节点,所以调用者从其他Eureka节点中可能获取不到服务A。所以,Eureka集群保障了可用性,但是强一致性没法保障。
当ZooKeeper集群中的leader“死掉”时,整个ZooKeeper集群将不可用,直到选举出新的leader并同步完数据后,ZooKeeper集群才可以对外使用。所以,ZooKeeper集群保障了一致性,却无法保障始终可用。
- 服务注册感知的时效性
Eureka默认配置速度比较慢,甚至能达到两三分钟。而ZooKeeper感知速度很快,秒级感知。
5. Eureka 参数优化(必须)
答:因为如果使用Eureka默认参数配置,服务的注册和发现会很慢,不符合生产使用。所以,必须手动配置参数。
以下为调整后的参数:
参数 | 说明 |
---|
eureka.server.responseCacheUpdateintervalMs= 3000(单位毫秒) | Eureka server刷新readCacheMap的时间,注意,client读取的是readCacheMap,这个时间决定了多久会把readWriteCacheMap的缓存更新到readCacheMap上(默认30秒) |
eureka.client.registryFetchintervalSeconds=3(单位秒) | 从Eureka服务器注册表中获取注册信息的时间间隔(s),默认为30秒 |
eureka.client.leaseRenewalintervalSeconds=3 | Eureka客户需要多长时间发送心跳给eureka服务器,表明它仍然活着,默认为30 秒 |
eureka.server.evictionintervalTimerinMs=3000 | 过期实例应该启动并运行的时间间隔,单位为毫秒,默认为60 * 1000 |
eureka.instance.leaseExpirationDurationinSeconds=3 | Eureka服务器在接收到实例的最后一次发出的心跳后,需要等待多久才可以将此实例删除,默认为90秒 |
经过调整后,服务发现变为秒级。
6. 生产机器选择
答:
服务注册中心部署个2台机器,每台机器就是4核8G,每台机器每秒钟轻松抗几百请求,上千请求也是可以的,高可用冗余,任何一台机器死掉,不会影响系统的运行。
微服务通常来说,如果每秒钟的并发在1000以内的话,每个服务部署2台机器,每台机器4核8G,每台机器每秒抗个几百请求,一点问题都没有
大部分的系统,高峰期每秒几百请求,低峰期每秒几十请求,甚至几个请求。
网关系统,4核8G的机器,一台机器抗每秒几百请求,部署3~4台机器,保证可以网关系统每台机器的压力比较小,进一步保证网关系统可靠性。
MySQL数据库,16核32G,物理机最佳,最多抗个每秒钟几千请求问题不大,平时抗个每秒钟几百或者几十请求。
7. 如何统计QPS、接口请求数等
答:
做一个简单的metric统计机制,AtomicLong,原子性,并发下数据统计准确,不会错误,每个接口被调用的时候,一个是可以对每个接口每分钟都做一个Metric统计。
对每个接口每天的请求使用一个AtomicLong做一个计数,统计出来每天的请求次数。
8. 如何实现幂等性
答:插入新数据保障订单字段是唯一索引,更新数据先查再更新。
9. 分布式事务如何实现
答:常用TCC和可靠消息一致性。前者需要使用TCC框架,给需要保持事务的接口多写一个回滚接口,这样如果发生异常,TCC框架会调用回滚接口,保障事务。可靠消息一致性则需要使用消息中间件。