Nacos配置中心交互模型是 push 还是 pull ?你应该这么回答 |
您所在的位置:网站首页 › 客户端推送配置 › Nacos配置中心交互模型是 push 还是 pull ?你应该这么回答 |
“
本文案例收录在 https://github.com/chengxy-nds/Springboot-Notebook 大家好,我是小富~ 对于Nacos大家应该都不太陌生,出身阿里名声在外,能做动态服务发现、配置管理,非常好用的一个工具。然而这样的技术用的人越多面试被问的概率也就越大,如果只停留在使用层面,那面试可能要吃大亏。 比如我们今天要讨论的话题,Nacos在做配置中心的时候,配置数据的交互模式是服务端推过来还是客户端主动拉的? 这里我先抛出答案:客户端主动拉的! 接下来咱们扒一扒Nacos的源码,来看看它具体是如何实现的? 配置中心聊Nacos之前简单回顾下配置中心的由来。 简单理解配置中心的作用就是对配置统一管理,修改配置后应用可以动态感知,而无需重启。 因为在传统项目中,大多都采用静态配置的方式,也就是把配置信息都写在应用内的yml或properties这类文件中,如果要想修改某个配置,通常要重启应用才可以生效。 但有些场景下,比如我们想要在应用运行时,通过修改某个配置项,实时的控制某一个功能的开闭,频繁的重启应用肯定是不能接受的。 尤其是在微服务架构下,我们的应用服务拆分的粒度很细,少则几十多则上百个服务,每个服务都会有一些自己特有或通用的配置。假如此时要改变通用配置,难道要我挨个改几百个服务配置?很显然这不可能。所以为了解决此类问题配置中心应运而生。 配置中心 推与拉模型客户端与配置中心的数据交互方式其实无非就两种,要么推push,要么拉pull。 推模型 客户端与服务端建立TCP长连接,当服务端配置数据有变动,立刻通过建立的长连接将数据推送给客户端。 优势:长链接的优点是实时性,一旦数据变动,立即推送变更数据给客户端,而且对于客户端而言,这种方式更为简单,只建立连接接收数据,并不需要关心是否有数据变更这类逻辑的处理。 弊端:长连接可能会因为网络问题,导致不可用,也就是俗称的假死。连接状态正常,但实际上已无法通信,所以要有的心跳机制KeepAlive来保证连接的可用性,才可以保证配置数据的成功推送。 拉模型 客户端主动的向服务端发请求拉配置数据,常见的方式就是轮询,比如每3s向服务端请求一次配置数据。 轮询的优点是实现比较简单。但弊端也显而易见,轮询无法保证数据的实时性,什么时候请求?间隔多长时间请求一次?都是不得不考虑的问题,而且轮询方式对服务端还会产生不小的压力。 长轮询开篇我们就给出了答案,nacos采用的是客户端主动拉pull模型,应用长轮询(Long Polling)的方式来获取配置数据。 额?以前只听过轮询,长轮询又是什么鬼?它和传统意义上的轮询(暂且叫短轮询吧,方便比较)有什么不同呢? 短轮询 不管服务端配置数据是否有变化,不停的发起请求获取配置,比如支付场景中前段JS轮询订单支付状态。 这样的坏处显而易见,由于配置数据并不会频繁变更,若是一直发请求,势必会对服务端造成很大压力。还会造成推送数据的延迟,比如:每10s请求一次配置,如果在第11s时配置更新了,那么推送将会延迟9s,等待下一次请求。 为了解决短轮询的问题,有了长轮询方案。 长轮询 长轮询可不是什么新技术,它不过是由服务端控制响应客户端请求的返回时间,来减少客户端无效请求的一种优化手段,其实对于客户端来说与短轮询的使用并没有本质上的区别。 客户端发起请求后,服务端不会立即返回请求结果,而是将请求挂起等待一段时间,如果此段时间内服务端数据变更,立即响应客户端请求,若是一直无变化则等到指定的超时时间后响应请求,客户端重新发起长链接。 Nacos初识为了后续演示操作方便我在本地搭了个Nacos。注意: 运行时遇到个小坑,由于Nacos默认是以cluster集群的方式启动,而本地搭建通常是单机模式standalone,这里需手动改一下启动脚本startup.X中的启动模式。 直接执行/bin/startup.X就可以了,默认用户密码均是nacos。 几个概念Nacos配置中心的几个核心概念:dataId、group、namespace,它们的层级关系如下图: dataId:是配置中心里最基础的单元,它是一种key-value结构,key通常是我们的配置文件名称,比如:application.yml、mybatis.xml,而value是整个文件下的内容。 目前支持JSON、XML、YAML等多种配置格式。 group:dataId配置的分组管理,比如同在dev环境下开发,但同环境不同分支需要不同的配置数据,这时就可以用分组隔离,默认分组DEFAULT_GROUP。 namespace:项目开发过程中肯定会有dev、test、pro等多个不同环境,namespace则是对不同环境进行隔离,默认所有配置都在public里。 架构设计下图简要描述了nacos配置中心的架构流程。 客户端、控制台通过发送Http请求将配置数据注册到服务端,服务端持久化数据到Mysql。 客户端拉取配置数据,并批量设置对dataId的监听发起长轮询请求,如服务端配置项变更立即响应请求,如无数据变更则将请求挂起一段时间,直到达到超时时间。为减少对服务端压力以及保证配置中心可用性,拉取到配置数据客户端会保存一份快照在本地文件中,优先读取。 这里我省略了比较多的细节,如鉴权、负载均衡、高可用方面的设计(其实这部分才是真正值得学的,后边另出文讲吧),主要弄清客户端与服务端的数据交互模式。 “下边我们以Nacos 2.0.1版本源码分析,2.0以后的版本改动较多,和网上的很多资料略有些不同 地址:https://github.com/alibaba/nacos/releases/tag/2.0.1 客户端源码分析Nacos配置中心的客户端源码在nacos-client项目,其中NacosConfigService实现类是所有操作的核心入口。 说之前先了解个客户端数据结构cacheMap,这里大家重点记住它,因为它几乎贯穿了Nacos客户端的所有操作,由于存在多线程场景为保证数据一致性,cacheMap采用了AtomicReference原子变量实现。 /** * groupKey -> cacheData. */private final AtomicReference cacheMap = new AtomicReference(new HashMap());cacheMap是个Map结构,key为groupKey,是由dataId, group, tenant(租户)拼接的字符串;value为CacheData对象,每个dataId都会持有一个CacheData对象。 获取配置 Nacos获取配置数据的逻辑比较简单,先取本地快照文件中的配置,如果本地文件不存在或者内容为空,则再通过HTTP请求从远端拉取对应dataId配置数据,并保存到本地快照中,请求默认重试3次,超时时间3s。 获取配置有getConfig()和getConfigAndSignListener()这两个接口,但getConfig()只是发送普通的HTTP请求,而getConfigAndSignListener()则多了发起长轮询和对dataId数据变更注册监听的操作addTenantListenersWithContent()。 @Overridepublic String getConfig(String dataId, String group, long timeoutMs) throws NacosException { return getConfigInner(namespace, dataId, group, timeoutMs);}@Overridepublic String getConfigAndSignListener(String dataId, String group, long timeoutMs, Listener listener) throws NacosException { String content = getConfig(dataId, group, timeoutMs); worker.addTenantListenersWithContent(dataId, group, content, Arrays.asList(listener)); return content;} 注册监听 客户端注册监听,先从cacheMap中拿到dataId对应的CacheData对象。 public void addTenantListenersWithContent(String dataId, String group, String content, List |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |