小白也能懂的 Nacos 服务模型介绍

前言

按照目前市场上的主流使用场景,Nacos 被分成了两块功能:服务注册发现(Naming)和配置中心(Config)。在之前的文章中我介绍了 Nacos 配置中心的实现原理,今天这篇文章所介绍的内容则是与 Nacos 服务注册发现功能相关,来聊一聊 Nacos 的服务模型。

说到服务模型,其实需要区分视角,一是用户视角,一个内核视角。即 Nacos 用户视角看到的服务模型和 Nacos 开发者设计的内核模型可能是完全不一样的,而今天的文章,是站在用户视角观察的,旨在探讨 Nacos 服务发现的最佳实践。


用了这么久配置中心,还不知道长轮询是什么?

前言

传统的静态配置方式想要修改某个配置时,必须重新启动一次应用,如果是数据库连接串的变更,那可能还容易接受一些,但如果变更的是一些运行时实时感知的配置,如某个功能项的开关,重启应用就显得有点大动干戈了。配置中心正是为了解决此类问题应运而生的,特别是在微服务架构体系中,更倾向于使用配置中心来统一管理配置。

配置中心最核心的能力就是配置的动态推送,常见的配置中心如 Nacos、Apollo 等都实现了这样的能力。在早期接触配置中心时,我就很好奇,配置中心是如何做到服务端感知配置变化实时推送给客户端的,在没有研究过配置中心的实现原理之前,我一度认为配置中心是通过长连接来做到配置推送的。事实上,目前比较流行的两款配置中心:Nacos 和 Apollo 恰恰都没有使用长连接,而是使用的长轮询。本文便是介绍一下长轮询这种听起来好像已经是上个世纪的技术,老戏新唱,看看能不能品出别样的韵味。文中会有代码示例,呈现一个简易的配置监听流程。


Nacos 集群部署模式最佳实践

1 前言

Nacos 支持两种部署模式:单机模式和集群模式。在实践中,我们往往习惯用单机模式快速构建一个 Nacos 开发/测试环境,而在生产中,出于高可用的考虑,一定需要使用 Nacos 集群部署模式。我的上一篇文章《一文详解 Nacos 高可用特性》提到了 Nacos 为高可用做了非常多的特性支持,而这些高可用特性大多数都依赖于集群部署模式。这篇模式文章便是给大家介绍一下,在实践中可以被采用的几种集群部署模式,无论你是希望自行搭建 Nacos,还是希望对 MSE 商业版 Nacos 有一个更加深刻的理解,我都很乐意跟你分享下面的内容。

由于篇幅限制,本文不会介绍如何将一个多节点的 Nacos 集群启动起来,主要介绍的是一个多节点的 Nacos 集群启动之后,我们的应用如何很好地连接到 Nacos 集群,即客户端视角。这中间我们会引入一些其他组件以解决一些问题,本文标题也可以叫做《Nacos 接入点最佳实践》。我将会介绍以下三种方案:直连模式、 VIP 模式和地址服务器模式,并对它们进行对比。


一文详解 Nacos 高可用特性

前言

服务注册发现是一个经久不衰的话题,Dubbo 早期开源时默认的注册中心 Zookeeper 最早进入人们的视线,并且在很长一段时间里,人们将注册中心和 Zookeeper 划上了等号,可能 Zookeeper 的设计者都没有想到这款产品对微服务领域造成了如此深厚的影响,直到 SpringCloud 开始流行,其自带的 Eureka 进入了人们的视野,人们这才意识到原来注册中心还可以有其他的选择。再到后来,热衷于开源的阿里把目光也聚焦在了注册中心这个领域,Nacos 横空出世。

注册中心

Kirito 在做注册中心选型时的思考:曾经我没得选,现在我只想选择一个好的注册中心,它最好是开源的,这样开放透明,有自我的掌控力;不仅要开源,它还要有活跃的社区,以确保特性演进能够满足日益增长的业务需求,出现问题也能及时修复;最好…它的功能还要很强大,除了满足注册服务、推送服务外,还要有完善的微服务体系中所需的功能;最重要的,它还要稳定,最好有大厂的实际使用场景背书,证明这是一个经得起实战考验的产品;当然,云原生特性,安全特性也是很重要的…

似乎 Kirito 对注册中心的要求实在是太高了,但这些五花八门的注册中心呈现在用户眼前,总是免不了一番比较。正如上面所言,功能特性、成熟度、可用性、用户体验度、云原生特性、安全都是可以拉出来做比较的话题。今天这篇文章重点介绍的是 Nacos 在可用性上体现,希望借助于这篇文章,能够让你对 Nacos 有一个更加深刻的认识。


Dubbo 稳定性案例:Nacos 注册中心可用性问题复盘

问题描述

上周四晚刚回到家,就接到了软负载同学的电话,说是客户线上出了故障,我一听”故障“两个字,立马追问是什么情况,经过整理,还原出线上问题的原貌:

客户使用了 Dubbo,注册中心使用的是 Nacos,在下午开始不断有调用报错,查看日志,发现了 Nacos 心跳请求返回 502

1
2
2019-11-15 03:02:41.973 [com.alibaba.nacos.client.naming454] -ERROR [com.alibaba.nacos.naming.beat.sender] request xx.xx.xx.xx failed.
com.alibaba.nacos.api.exception.NacosException: failed to req API: xx.xx.xx.xx:8848/nacos/v1/ns/instance/beat. code:502 msg:

此时还没有大范围的报错。随后,用户对部分机器进行了重启,开始出现大规模的 Nacos 连接不上的报错,并且调用开始出现大量 no provider 的报错。


Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×