- 原理图
-
Eureka 服务注册中心
-
Feign 服务调用
-
Ribbon 负载均衡
-
Zuul / SpringCloud Gateway : 网关
接口过多,不能直接对外暴露(对于前端,接口过多),通过网关统一管理。 灰度发布 统一熔断 统一降级 统一限流 统一授权认证
-
(Hystrix/链路追踪/stream/其他组件,高可用)
Eureka原理
多级缓存 其实本质上也是 读写分离的思想。
本质就是http接口的调用
Feign 注解+动态代理,底层是http格式的请求
ribbon 负载均衡策略,先从Eureka拉取注册表信息,然后根据负载均衡选择一台机器 发送http请求调用接口。
zuul 如果请求到了网关,会通过配置找相应的服务。
SpringCloud与Dubbo优劣对比?
Dubbo 的RPC框架 调用速度会比springcloud http调用快
springcloud全家桶,功能齐全,网关,分布式配置中心,授权认证,服务链路追踪,Hystrix熔断 降级 资源隔离 中间件的封装等。
注册中心的选型? Eureka,zk
CAP:
C: 一致性
A:可靠性
P:分区容错性
Eureka :AP
可靠性可以保障,因为Eureka是peer模式,如果一个节点挂了,服务可以从其他的注册中心节点拉取服务,但是 这个节点和挂掉的节点可能会数据不一致(挂的节点可能刚好注册了一个服务还没来得及和其他节点同步),不能保证C,当心跳检测不到挂掉的节点时会重新注册到可用的节点,保障最终的一致性。
zk: CP
为了保障一致性,牺牲了可用性。当leader节点挂掉时(还没来得及同步新的服务),follower会选举新的leader,这时,为了保障C,就不能满足A,不可用一段时间,leader选举好了就可以继续写数据了,用来保障C一致性。
服务注册的时效性
zk时效性更好,注册和挂掉,(1)秒级感知
eureka,默认配置要几十秒 甚至 两三分钟。ribbon,心跳检测,缓存拉取,缓存更新都需要配置相应的参数(多少秒一次)
容量
Eureka和zk都难以支撑几千的机器实例。(几百最多1千)
服务上下线时,zk瓶颈为大量的网络带宽。Eureka实例同步需要接受所有请求,eureka实例多扛不住。
参数调优
一般生产都会关闭自我保护机制(如果有网络抖动,则不会下线所有服务)
关于时效性的eureka参数调优
都改成3秒 ,实例的心跳检测由90s改为6秒(服务不多的情况下可以设置为1S)
你们公司服务注册中心是怎么选型的?生产环境怎么优化?
eureka,zk,consul原理图
ap,cp,
服务注册的时效性。 eureka优化参数
注册中心能支撑多少实例?
一般都是用高配机器来搞:8核16G,16核32G,每台机器支撑每秒几千请求没有问题。
zuul网关核心功能
动态路由:服务增减机器,网关自动热感知
灰度发布:两台一样的服务 不同的版本。
授权认证
性能监控:成功率,QPS,接口耗时
限流熔断
几种网关:
zuul,Kong(Nginx+lua),OpenResty(Nginx+lua),自研网关
zuul:基于java,自己可以把控源码,但核心功能简单,灰度、动态路由、限流需要二次开发。高并发能力不强,需要部署到tomcat上去。
Kong:依托于Nginx,lua,OpenResty,现成的插件可以直接使用。可抗高并发,但是是用C语言写的。不利于底层二次开发。
自研: 一般大厂会 基于 java,Servlet,netty,自研高并发,高性能的网关。
zuul动态路由如何实现?
新建一张配置表,记录ip和路径等信息
搞一个界面对这个表增删改查。
网关启动的时候拉取配置中的数据和表中的数据,定时任务每隔5秒从数据库中拉取一次。
zuul网关如何抗10W+?
8核16G每秒抗1000+没问题。
上万服务实例,服务中心如何抗住?
分片,主从。
灰度发布
zuul进行二次开发。
创建一个url路径的配置表,是否启用灰度发布字段 0,1。
启用就走灰度发布逻辑(例如搞一个随机数 100以内,让seed==50的时候走灰度发布的url服务器。即1%的流量请求走灰度)
在config里配置一个实例版本。为灰度版本。
你们公司生产系统是怎么部署的?
大部分系统: 高峰几百,低峰几十请求。
网关: 配置要高一些: 8核16G 2台。 (4核8G 3-4台)
普通服务: 4核8G 每个服务实例两台机器。 一般可以抗 几百请求。上千也是OK的。 也可以多部署几台机器用来抗QPS 。
数据库 mysql 16核32G,物理机最佳。最多三四千。 如果达到三四千量级,网络负载 cpu使用率,磁盘IO都会很高。
如何访问量扩容10倍?
Nginx做负载,均匀分发给网关,扩10倍网关。其他机器水平扩容就OK了
mysql层 扩充物理机 32核128G 每秒 抗几千没问题
springCloud系统第一调用会超时,怎么解决?
因为ribbon的懒加载机制,第一次请求会加载一些组件。
上述参数配置完毕之后还会可能超时,zuul调用子系统超时,因为链路比较长,所以可以设置超时时间
幂等性如何保障?
核心接口,根据业务逻辑。 create操作可以利用唯一索引。update操作可以配合redis.
分布式事务如何保障?
订单、库存、积分 绑定在一起成为一个事务 用TCC(try,confirm,cancel)框架。
发货可以用消息中间件保障最终一致性。
阿里开源的分布式事务框架 seata. 支持dubbo,springcloud
引入分布式框架TCC有哪些瓶颈?能支撑高并发场景吗?
例如seata, seata-server会与其频繁的网络通信用于记录各种状态,还有就是记录一些日志落地到磁盘 mysql,file, 会造成性能开销。
高并发每秒上万,需要分库分表。 seata也得分库分表。
异步消息中间件对于分布式事务的原理图
没有rocketMq 就自己写一个服务 +rabbitMQ +mysql 实现 rocketmq这一套逻辑
分布式锁框架?
Redission
加锁 key value ,product_id_stock{xxxxx:id}
watchdog 循环 看客户端是否持有锁,有则更新过期时间。
别的加锁循环等待。
redis集群加锁后挂掉怎么办?
master-slave 会出现加两个锁的情况。 (很少)这就得改redis源码进行二次开发,在master和slave都写成功才加锁成功。