Skip to content

Commit 7113a56

Browse files
author
文亮
committed
add doc
1 parent 4813b23 commit 7113a56

File tree

7 files changed

+106
-0
lines changed

7 files changed

+106
-0
lines changed

README.md

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -190,6 +190,10 @@
190190
- [14、平时除了使用外,有研究过Spring Cloud的底层架构原理么?](/docs/distributed-system/springCloud-study-theory.md)
191191
- [15、从底层实现原理的角度,对比一下Dubbo和Spring Cloud的优劣!](/docs/distributed-system/dubbo-vs-springCloud.md)
192192
- [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)
193197

194198

195199
### 第二季-高并发
Loading
Loading

docs/distributed-system/register-high-availability.md

Whitespace-only changes.
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
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+
Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
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+
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
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+

0 commit comments

Comments
 (0)