nacos的一致性协议distro介绍

nacos介绍

nacos在它的官网上是这样介绍自己的

一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台

它可作为服务的注册中心,也可用于配置的管理。作为注册中心强调了“更易于构建云原生应用”。注册中心我们可能更加熟悉zookeeper,这里做一个简单的对比

特性 zookeeper nacos
一致性协议 CP CP+AP
健康检查 Keep Alive TCP / HTTP / MySql / Client beat
负载均衡 权重 / selector / metadata
多数据中心 不支持 支持
跨注册中心同步 不支持 支持
雪崩保护
访问协议 TCP HTTP / DNS
K8s集成 不支持 支持
dubbo集成 -- 支持 支持

一致性协议

在介绍一致性协议前先了解一下CAP理论

  • Consistency 一致性,在分布式系统中的所有数据备份,在同一时刻是否同样的值;
  • Availability 可用性,只要收到用户的请求,服务器就必须给出回应;
  • Partition tolerance 分区容错性,以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择

分布式系统必须具有分区容错性,一致性与可用性只能选择其一,如果选择一致性,必须在某节点写入时,数据同步到其他节点完成后才可以响应下一个请求,这段时间内服务是不可用的;反之选择可用性,则一致性无法保证,这就是CAP理论

作为注册中心,P要保证,C和A需要权衡;常见的一致性协议有paxos、raft,他们都是强一致性协议(CP),然而今天要介绍的nacos的distro协议时弱一致协议(AP),即最终一致性协议。注册中心到底该是AP还是CP,推荐阅读阿里中间件的博客《阿里巴巴为什么不用 ZooKeeper 做服务发现?

distro协议介绍

distro协议网上的资料比较少,因为它是阿里“自创的协议“,通过源码总结一下distro协议的关键点:

  • distro协议是为了注册中心而创造出的协议;
  • 客户端与服务端有两个重要的交互,服务注册与心跳发送;
  • 客户端以服务为维度向服务端注册,注册后每隔一段时间向服务端发送一次心跳,心跳包需要带上注册服务的全部信息,在客户端看来,服务端节点对等,所以请求的节点是随机的;
  • 客户端请求失败则换一个节点重新发生请求;
  • 服务端节点都存储所有数据,但每个节点只负责其中一部分服务,在接收到客户端的“写“(注册、心跳、下线等)请求后,服务端节点判断请求的服务是否为自己负责,如果是,则处理,否则交由负责的节点处理;
  • 每个服务端节点主动发送健康检查到其他节点,响应的节点被该节点视为健康节点;
  • 服务端在接收到客户端的服务心跳后,如果该服务不存在,则将该心跳请求当做注册请求来处理;
  • 服务端如果长时间未收到客户端心跳,则下线该服务;
  • 负责的节点在接收到服务注册、服务心跳等写请求后将数据写入后即返回,后台异步地将数据同步给其他节点;
  • 节点在收到读请求后直接从本机获取后返回,无论数据是否为最新。

通过几个特殊场景来加深一下理解

  • 某服务一段时间未发送心跳,被服务端摘除,该服务恢复后继续发送心跳,重新被注册;
  • 服务端某节点宕机,不回复其他服务端节点的健康检查请求,则会被其他节点从健康节点列表中剔除,其他节点重新分配负责节点,依靠客户端的心跳重新建立完整的服务数据;
  • A机房部署2节点,B机房部署3节点,组成一个集群,5个节点分别负责相应的服务,某时刻,两机房网络不通,导致A机房两个节点组成一个集群,B机房三个节点组成一个集群,即“脑裂问题”,在强一致性协议中,此时只可能A机房可用,B机房不可用,distro协议不处理脑裂问题,这种情况需要再细分两种:(1)客户端与A、B机房都联通,则一段时间随机请求的心跳之后,A、B集群中仍然有全量的服务,A、B正常(2)部分客户端与A联通,部分客户端与B联通,则部分服务注册到A,部分注册到B,A内部可以调用,B内部也可以调用,AB不可相互调用,这种极端情况比起强一致的情况要好一些,强一致协议会导致与A连通的服务可用,与B联通的服务不可用,A也调用不了B。

nacos简单评测

  • 目前版本(1.2.0)的实现,无论是客户端与服务端或是服务端之间的通信都是采用http协议,数据格式为json,在服务数量多的情况下非常消耗cpu资源,如果改为长连接,数据格式再高效一点就更好;
  • 服务的心跳是以instance纬度,即ip + port + service,这会导致心跳请求非常多,结合第一点,不改造的情况下,几乎无法用于生产;
  • distro协议判断服务的负责节点采用简单的hash算法,如果nacos某节点宕机,则所有的服务都会重新计算映射到新的节点,变动较多,如果能采用一致性hash算法,则单节点宕机,只转移该故障节点负责的服务。


    image
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,858评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,372评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,282评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,842评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,857评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,679评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,406评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,311评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,767评论 1 315
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,945评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,090评论 1 350
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,785评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,420评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,988评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,101评论 1 271
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,298评论 3 372
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,033评论 2 355

推荐阅读更多精彩内容