


全国
好顺佳集团
2022-06-02 12:44:46
1716
内容摘要:面试官:如果公司要开发分布式注册中心,您的设计思路是什么?1.报名中心是什么?服务注册中心,它是微服务实例和服务元数据的数据库。服务实例在启动时向服务注册中心注册,并在关闭时注销。服务的...
面试官:如果公司要开发分布式注册中心,您的设计思路是什么?
1.报名中心是什么?
服务注册中心,它是微服务实例和服务元数据的数据库。服务实例在启动时向服务注册中心注册,并在关闭时注销。
服务的客户端和路由器查询服务注册表以查找服务的可用实例。服务注册中心可以调用服务实例的健康检查API,以验证它是否可以处理请求。
2.帽盖的设计原则和基本理论是什么?
一致性(C):分布式系统中的所有数据备份是否同时具有相同的值。(相当于所有节点访问数据的同一最新副本)
可用性(A):集群中的某些节点发生故障后,整个集群是否仍能响应客户端的读写请求。(数据更新的高可用性)
分区容忍度(P):当集群中的机器因网络故障无法保证彼此正常通信时,每台机器都有能力各自为战,保证服务的正常使用
CAP原理的本质不是AP、CP就是AC,就是没有CAP。
如果分布式系统中没有数据的副本,那么系统必须满足强一致性条件,因为只有一个数据,不会出现数据不一致的情况。此时C和P有两个元素
但是,如果系统出现网络分区情况或停机,则不可避免地会导致部分数据无法访问
此时,可用性条件不能满足,即在这种情况下得到了CP系统,但不能同时满足CAP。不可避免地会有一些数据无法访问,此时无法满足可用性条件,即在这种情况下获得CP系统,但无法同时满足CAP。
BASE的庸俗CA退而求其次,这就是所谓的最终一致性。
3.面对种类繁多的注册表组件,该如何选择技术?
基于以上理论,我将目前工作中最常用的尤里卡和Z
OoKeeper用于比较。
我直接放了两张图:
上图是Eureka集群的示意图,采用对等架构集群模式,部署一个集群,但集群中每台机器的状态是相等的
每个服务都可以向任何Euerka实例服务和服务发现注册。在集群中的任何Euerka实例接收到写请求后,它将自动同步到所有其他Eureka实例
但他会有问题。他可能还没有同步数据,结果他会死的
此时可以继续从其他机器上拉出注册表,但看到的不是最新数据,但可用性是有保证的。这种状态遵循基础理论,即最终一致性。
架构图如下:
ZooKeeper有一个领导者节点,它将接收数据,然后同步地写到其他节点。一旦领导人去世,就要重新选举领导人
在这个过程中,为了保证C,牺牲了A,在一段时间内无法使用。但是,如果一个领导当选了,那么您可以继续数据并确保一致性
说到这里,笔者认为真正意义上的AP在现实场景中几乎是不存在的,我也从未体验过完全不需要数据统一的场景。说白了,这不是大脑分裂吗?...
接下来,我将从两个方面继续谈谈它们之间的区别:
(一)服务注册发现的及时性
ZK,更好的时效性,注册或挂机,秒级即可感知
尤里卡,默认配置很糟糕,服务发现感知几十秒甚至几分钟
当启动一个新的服务实例以便其他人可以找到它时,在极端情况下,ribbon可能需要1分钟来获得每个服务上缓存的eureka注册表以进行负载平衡
服务失败,每60秒检查一次心跳,发现该服务最后一次心跳是在60秒之前,每60秒检查一次心跳,超过90秒没有心跳就认为他死了,2
几分钟过去了
30秒,缓存将被更新,30秒,其他服务将拉出最新的注册表
三分钟过去了,如果你的服务实例挂断了,别人觉得可能需要两三分钟,一两分钟,很长时间
(2)容量
Zk,不适合大规模的服务实例,因为当服务上下行时,需要即时向所有其他服务实例推送数据通知
因此,一旦业务规模过大,当有上千个业务实例时,就会大量占用网络带宽
Eureka也很难支持大规模的服务实例,因为每个Eureka实例都要接受所有请求,很多实例的压力太大无法支持,很难达到上千个服务实例
之前dubbo技术系统使用zk作为注册中心,spring cloud技术系统使用eureka作为注册中心,这两种技术应用最广泛
但是现在很多中小型公司大多是spring cloud,所以我们后面会讲到基于eureka的service registry的生产优化
4.如果要自学报名中心,需要注意什么?
既然要开发自己的注册中心,就必然要开发相应的客户端和服务器,两端都要考虑自己的事情
客户:
服务拉动:绝对不是一次全拉动。此时,您应该考虑服务器可能会提供一个最近的更改队列供客户机拉取的可能性
还有,必须有一个指标数据,用来验证拉增量数据后数据是否完整,以及验证数据是否异常。如果有异常,拉动整个数量一次。
心跳发送:告诉服务器是否活着来续订服务。
服务离线:服务离线,修改标志的状态,当然这个标志要保证它的可见性。
服务器端:
Service registry:要深入理解java并发收缩,必须注意Service registry中的读写并发控制,既要保证线程安全,又要减少锁争用,最大限度地保证
它的性能。
注册服务健康检查:在单位时间内,如果注册服务不续签服务,则该服务应离线。
集群同步:根据自己的实际业务需求,制定合适的集群架构方案,在此前提下,制定合适的数据传输方案,保证吞吐量。
此外,还要考虑注册表与主流技术框架的兼容性。
上一篇:苏州公司注册名称预先核准
下一篇:苏州注册的公司能转到南通
张总监 13826528954
限时领取创业礼包
所有服务
您的申请我们已经收到!
专属顾问会尽快与您联系,请保持电话畅通!