File tree Expand file tree Collapse file tree 7 files changed +106
-0
lines changed Expand file tree Collapse file tree 7 files changed +106
-0
lines changed Original file line number Diff line number Diff line change 190
190
- [ 14、平时除了使用外,有研究过Spring Cloud的底层架构原理么?] ( /docs/distributed-system/springCloud-study-theory.md )
191
191
- [ 15、从底层实现原理的角度,对比一下Dubbo和Spring Cloud的优劣!] ( /docs/distributed-system/dubbo-vs-springCloud.md )
192
192
- [ 16、作业:自己独立画出Spring Cloud的架构原理图,RPC框架架构设计图!] ( /docs/distributed-system/springCloud-and-rpc-framework.md )
193
+ - [ 17、面试官:你们的服务注册中心进行过选型调研吗?对比一下各种服务注册中心!] ( /docs/distributed-system/registration-center-%20guide.md )
194
+ - [ 18、画图阐述一下你们的服务注册中心部署架构,生产环境下怎么保证高可用?] ( /docs/distributed-system/register-high-availability.md )
195
+ - [ 19、你们系统遇到过服务发现过慢的问题吗?怎么优化和解决的?] ( /docs/distributed-system/service-register-discovery.md )
196
+ - [ 20、作业:说一下自己公司的服务注册中心怎么技术选型的?生产环境中应该怎么优化?] ( /docs/distributed-system/register-production-optimize.md )
193
197
194
198
195
199
### 第二季-高并发
Original file line number Diff line number Diff line change
1
+
2
+ #### 分布式系统架构的
3
+
4
+ ** 服务注册中心,eureka、zk、consul,原理画图画清楚**
5
+
6
+ ** 数据一致性,CP、AP**
7
+
8
+ 服务注册、故障 和发现的时效性是多长时间
9
+
10
+ 注册中心最大能支撑多少服务实例
11
+
12
+ 如何部署的,几台机器,每台机器的配置如何,会用比较高配置的机器来做,8核16G,16核32G的高配置机器来搞,基本上可以做到每台机器每秒钟的请求支撑几千绝对没问题
13
+
14
+ 可用性如何来保证
15
+
16
+ ** 有没有做过一些优化,服务注册、故障以及发现的时效性,是否可以优化一下,用eureka的话,可以尝试一下,配合我们讲解的那些参数,优化一下时效性,服务上线、故障到发现是几秒钟的时效性**
17
+
18
+ ** zk,一旦服务挂掉,zk感知到以及通知其他服务的时效性,服务注册到zk之后通知到其他服务的时效性,leader挂掉之后可用性是否会出现短暂的问题,为了去换取一致性**
19
+
20
+
21
+ ** 所以希望大家好好完成每天的作业,我布置的大量作业,就是为了帮你锻造出这种能力**
22
+
23
+ ** 学习课程以及完成作业的过程中,大家一定会有很多的问题,可以到专栏的评论区去提问**
24
+
25
+ ** 每天我都会和之前带出来的一批阿里、蚂蚁金服、滴滴的优秀同学给大家进行答疑,并且我们还有专门的付费用户的微信群,大家可以在微信群里跟我们一起进行技术交流**
26
+
27
+ ** 如果你能坚持下来,学满6季,还可以获取私人定制的面试一条龙VIP服务**
28
+
29
+ ** 如果是连续6季面试训练营都购买的同学,还可以获取面试一条龙VIP服务**
30
+
31
+ ** 具体信息大家看“狸猫技术窝”公众号的知识店铺内的训练营详情即可**
32
+
33
+ ** 具体可参见训练营目录下的《训练营专属服务》文档。简单来说,这个私人定制的面试VIP服务,会为你的跳槽面试全程保驾护航**
34
+
Original file line number Diff line number Diff line change
1
+
2
+ 非常常见的一个技术面试题,但凡只要是聊到分布式这块,一定会问问你,** Dubbo,Spring Cloud,服务注册中心** ,你们当时是怎么选型和调研的,你们最终是选择了哪块技术呢?你选择这块技术的原因和理由是什么呢?
3
+
4
+ ** Eureka、ZooKeeper**
5
+
6
+ ** Dubbo** 作为服务框架的,一般注册中心会选择zk
7
+
8
+ ** Spring Cloud** 作为服务框架的,** 一般服务注册中心会选择Eureka**
9
+
10
+ ** Consul、Nacos,** 普及型还没那么广泛,我会在面试训练营课程里增加对应的内容,给大家去进行补充
11
+
12
+ #### (1)服务注册发现的原理
13
+
14
+ 集群模式
15
+ ![ ZooKeeper] ( /docs/distributed-system/images/eureka-register.png )
16
+
17
+ ** Eureka,peer-to-pee** r,部署一个集群,** 但是集群里每个机器的地位是对等的,各个服务可以向任何一个Eureka实例服务注册和服务发现,集群里任何一个Euerka实例接收到写请求之后,会自动同步给其他所有的Eureka实例**
18
+ ![ ZooKeeper] ( /docs/distributed-system/images/zookeeper-register.png )
19
+
20
+ ** ZooKeeper,服务注册和发现的原理,Leader + Follower两种角色,只有Leader可以负责写也就是服务注册,他可以把数据同步给Follower,读的时候leader/follower都可以读**
21
+
22
+ #### (2)一致性保障:CP or AP
23
+
24
+ ** CAP,C是一致性,A是可用性,P是分区容错性**
25
+
26
+ ** CP,AP**
27
+
28
+ ** ZooKeeper是有一个leader节点会接收数据, 然后同步写其他节点,一旦leader挂了,要重新选举leader,这个过程里为了保证C,就牺牲了A,不可用一段时间,但是一个leader选举好了,那么就可以继续写数据了,保证一致性**
29
+
30
+ Eureka是peer模式,可能还没同步数据过去,结果自己就死了,此时还是可以继续从别的机器上拉取注册表,但是看到的就不是最新的数据了,但是保证了可用性,强一致,最终一致性
31
+
32
+ (3)服务注册发现的时效性
33
+
34
+ zk,时效性更好,注册或者是挂了,一般秒级就能感知到
35
+
36
+ eureka,默认配置非常糟糕,服务发现感知要到几十秒,甚至分钟级别,上线一个新的服务实例,到其他人可以发现他,极端情况下,可能要1分钟的时间,ribbon去获取每个服务上缓存的eureka的注册表进行负载均衡
37
+
38
+ 服务故障,隔60秒才去检查心跳,发现这个服务上一次心跳是在60秒之前,隔60秒去检查心跳,超过90秒没有心跳,才会认为他死了,2分钟都过去
39
+
40
+ 30秒,才会更新缓存,30秒,其他服务才会来拉取最新的注册表
41
+
42
+ 三分钟都过去了,如果你的服务实例挂掉了,此时别人感知到,可能要两三分钟的时间,一两分钟的时间,很漫长
43
+
44
+ #### (4)容量
45
+
46
+ zk,不适合大规模的服务实例,因为服务上下线的时候,需要瞬间推送数据通知到所有的其他服务实例,所以一旦服务规模太大,到了几千个服务实例的时候,会导致网络带宽被大量占用
47
+
48
+ eureka,也很难支撑大规模的服务实例,因为每个eureka实例都要接受所有的请求,实例多了压力太大,扛不住,也很难到几千服务实例
49
+
50
+ 之前dubbo技术体系都是用zk当注册中心,spring cloud技术体系都是用eureka当注册中心这两种是运用最广泛的,但是现在很多中小型公司以spring cloud居多,所以后面基于eureka说一下服务注册中心的生产优化
51
+
52
+ (5)多机房、多数据中心、健康检查
53
+
54
+
Original file line number Diff line number Diff line change
1
+
2
+ ** zk,一般来说还好,服务注册和发现,都是很快的**
3
+
4
+ ** eureka,必须优化参数**
5
+
6
+ ** eureka.server.responseCacheUpdateIntervalMs = 3000**
7
+ ** eureka.client.registryFetchIntervalSeconds = 30000**
8
+
9
+ ** eureka.client.leaseRenewalIntervalInSeconds = 30**
10
+ ** eureka.server.evictionIntervalTimerInMs = 60000**
11
+ ** eureka.instance.leaseExpirationDurationInSeconds = 90**
12
+
13
+ ** 服务发现的时效性变成秒级,几秒钟可以感知服务的上线和下线**
14
+
You can’t perform that action at this time.
0 commit comments