程序新视界

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～Nacos在服务注册功能中使用到了UDP的通信方式，主要功能就是用来辅助服务实例变化时对客户端进行通知。然而，对于大多数使用Nacos的程序员来说，可能还不知道这个功能，更别说灵活运用了。看完整个源码的实现，还是要为这一功能点个赞的，可以说非常巧妙和实用。但在实现上有一些不足，文末会进行指出。本篇文章就带大家从源码层面来分析一下Nacos 2.0中是如何基于UDP协议来实现服务实例变更的通知。UDP通知基本原理在分析源码之前，先来从整体上看一.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～前面我们讲了Nacos客户端如何获取实例列表，如何进行缓存处理，以及如何订阅实例列表的变更。在获取到一个实例列表之后，你是否想过一个问题：如果实例列表有100个实例，Nacos客户端是如何从中选择一个呢？这篇文章，就带大家从源码层面分析一下，Nacos客户端采用了如何的算法来从实例列表中获取一个实例进行请求的。也可以称作是Nacos客户端的负载均衡算法。单个实例获取NamingService不仅提供了获取实例列表的方法，也提供了获取单个实例的方.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～本篇文章我们来通过源码分析一下Nacos的本地缓存及故障转移功能，涉及到核心类为ServiceInfoHolder和FailoverReactor。ServiceInfoHolder功能概述ServiceInfoHolder类，顾名思义，服务信息的持有者。前面文章已经多次涉及到ServiceInfoHolder类，比如每次客户端从注册中心获取新的服务信息时都会调用该类的processServiceInfo方法来进行本地化的处理，包括更新缓存服务、.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～上篇文章，我们分析了Nacos客户端订阅的核心流程：Nacos客户端通过一个定时任务，每6秒从注册中心获取实例列表，当发现实例发生变化时，发布变更事件，订阅者进行业务处理，然后更新内存中和本地的缓存中的实例。这篇文章为服务订阅的第二篇，我们重点来分析，定时任务获取到最新实例列表之后，整个事件机制是如何处理的。回顾整个流程先回顾一下客户端服务订阅的基本流程：在第一步调用subscribe方法时，会订阅一个EventListener事件。而在定.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～说起Nacos的服务订阅机制，对此不了解的朋友，可能感觉非常神秘，这篇文章就大家深入浅出的了解一下Nacos 2.0客户端的订阅实现。由于涉及到的内容比较多，就分几篇来讲，本篇为第一篇。Nacos订阅概述Nacos的订阅机制，如果用一句话来描述就是：Nacos客户端通过一个定时任务，每6秒从注册中心获取实例列表，当发现实例发生变化时，发布变更事件，订阅者进行业务处理。该更新实例的更新实例，该更新本地缓存的更新本地缓存。上图画出了订阅方法的主线.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～本篇带大家通过源码层面分析一下Nacos Client的服务发现的路程，事实可能并不像你想象的那样简单。Nacos服务发现直观的看，Nacos客户端的服务发现，就是封装参数、调用服务端接口、获得返回实例列表。但细化这个流程，会发现不仅包括了通过NamingService获取服务列表，在获取服务列表的过程中还涉及到通信协议（Http or gRPC）、订阅流程、故障转移逻辑等。下面我们根据服务发现来捋一下相关的流程。先说入口程序，依旧是在Na.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～本篇文章Nacos核心逻辑篇，给大家讲解一下「临时实例」与「持久化实例」的区别及运用场景。Nacos的临时实例与持久化实例在Nacos Client进行实例注册时，我们知道是通过Instance对象来携带实例的基本信息的。在Instance中有一个ephemeral字段，用来表示该实例是临时实例，还是持久化实例。public class Instance implements Serializable { /** *.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～随着对Nacos源码的深入阅读，感觉越来越有意思了，大量的设计模式和基础知识点都在其中被运用。不论你是否阅读源码，都值得借鉴一下Nacos的运用案例。今天这篇文章，给大家介绍一下Nacos Client中对代理模式的运用。阅读这篇文章，你可以不懂Nacos源码，但能够学到代理模式的运用；如果你准备阅读Nacos源码，不仅可以学到代理模式的案例，还可以更加深刻的感知到Nacos中的设计思想。代理模式简介通俗的来讲，代理模式就是让别人（代理）帮忙做.

学习不用那么功利，二师兄带你从更高维度轻松阅读源码～大家可能看到过很多写Java反射机制的文章，但如果在阅读源码的过程中，遇到反射机制的使用，你是否想过为什么要这么用吗？这篇文章就带大家来看看Nacos中对Java反射机制的一处实践案例。这篇文章既属于知识点的分析，也属于Nacos设计层面的分析。Nacos中反射机制实践先来介绍一下Nacos反射机制使用的背景。nacos-client项目中，可以通过NacosFactory获得NamingService，然后基于NamingService来进.

学习不用那么功利，二师兄带你一起轻松读源码～在上篇文章中，我们学习了Nacos中是如何灵活运用《简单工厂模式》的。而设计模式在面试过程中也经常会出现。当面试官问到：说说工厂模式是如何实现的？他问的工厂模式指的是什么？这篇文章属于扩展篇的扩展，我们基于简单工厂模式，再来聊聊工厂模式。工厂方法模式先来回答上面的问题，如果笼统的讲工厂模式，通常包括：简单工厂/静态工厂、工厂方法模式和抽象工厂模式。上节讲了简单工厂模式，而抽象工厂模式一般应用在比较复杂的大型应用中，也不太常见。因此，如果工厂模式只是指.

学习不用那么功利，二师兄带你一起轻松读源码～番外篇简介Nacos源码分析系列文章，在开篇已经提到过，写作的目标有两个：第一，能够系统的学习Nacos知识；第二，能够基于Nacos学到涉及到的知识点或面。为了方便大家学习，相对应的文章标题会有所区别，Nacos原理部分命名按照正常编号进行。而番外篇，也就是技术点的讲解则会在文章编号上添加“EXT-”的前缀。这样，如果大家只想学习Nacos原理知识，则可跳过EXT前缀的文章。这篇文章我们来看看Nacos Client中对工厂模式的使用。这里分两个步骤.

开篇构想在此之前，已经写了十多篇Nacos的文章，感觉Nacos还值得更深入的学习一下。于是萌生了写一个Nacos源码系列专栏的文章。写作的目标呢，有两个：第一，能够系统的学习Nacos知识；第二，能够基于Nacos学到涉及到的知识点或面；展现形式呢，也有两个：第一，单篇足够简单且又有价值；第二，发现代码中的新颖之处；源码版本信息目前在生产实践中建议大家采用1.4.2版本，但作为技术研究，本系列文章会基于2.0.2版本来仅仅讲解。这是两个跨度比较大的版本，建议大家配合源码进行学习。关于源码拉取，

前言在上篇文章《微服务：剖析一下源码，Nacos的健康检查竟如此简单》中讲了当微服务突然挂掉的解放方案：调整健康检查周期和故障请求重试。朋友看了文章，建议再聊聊正常关闭服务时如何让微服务优雅下线。为什么说是优雅下线？我们知道在分布式应用中为了满足CAP原则中的A（可用性），像Nacos、Eureka等注册中心的客户端都会进行实例列表的缓存。当正常关闭应用时，虽然可以主动调用注册中心进行注销，但这些客户端缓存的实例列表还是要等一段时间才会失效。上述情况就有可能导致服务请求到已经被关闭的实例上，虽然通过重

前言前面我们多次提到Nacos的健康检查，比如《微服务之：服务挂的太干脆，Nacos还没反应过来，怎么办？》一文中还对健康检查进行了自定义调优。那么，Nacos的健康检查和心跳机制到底是如何实现的呢？在项目实践中是否又可以参考Nacos的健康检查机制，运用于其他地方呢？这篇文章，就带大家来揭开Nacos健康检查机制的面纱。Nacos的健康检查Nacos中临时实例基于心跳上报方式维持活性，基本的健康检查流程基本如下：Nacos客户端会维护一个定时任务，每隔5秒发送一次心跳请求，以确保自己处于活跃状态。

前言我们知道通过Nacos等注册中心可以实现微服务的治理。但引入了Nacos之后，真的就像理想中那样所有服务都由Nacos来完美的管理了吗？Too young，too simple！今天这篇文章就跟大家聊聊，当服务异常宕机，Nacos还未反应过来时，可能会发生的状况以及现有的解决方案。Nacos的健康检查故事还要从Nacos对服务实例的健康检查说起。Nacos目前支持临时实例使用心跳上报方式维持活性。Nacos客户端会维护一个定时任务，每隔5秒发送一次心跳请求，以确保自己处于活跃状态。Nacos

Nacos服务自动关闭在使用Nacos时，有时候会遇到服务自动关闭的情况。这通常涉及到三方面的原因：内存配置、启动方式和关闭方式。下面逐一说明。内存配置导致Nacos关闭Nacos最新版本默认的JVM配置是2G，如果你的服务器配置比较低，在这样的默认配置下会导致OOM情况的发生。startup.sh中配置项：if [[ "${MODE}" == "standalone" ]]; then JAVA_OPT="${JAVA_OPT} -Xms512m -Xmx512m -Xmn256m"

前言在Spring Cloud项目中我们经常会用到Nacos，但如果只是在测试环境或者微服务数量相对比较少时，采用Nacos默认的JVM配置会浪费很多资源。特别是那些低配置用来研究的服务器。无论是出于生产环境优化所需，还是出于测试环境不浪费资源所需，都需要对默认的JVM进行调整。Nacos内存配置Nacos是基于Spring Boot的项目，所使用的内存参数是在启动命令中进行配置的。而启动命令位于startup.sh（或.cmd）当中：#=============================

前言目前公司系统采用Spring Cloud架构，其中服务注册和发现组件用的Nacos，最近运维抱怨说，磁盘不够用，日志增长的太快。简单排查一下，罪魁祸首竟然是Nacos。按理说Nacos作为服务注册中心，不会应该会产生太多日志的，本身涉及的服务也不多，但几天就会产生1G以上的日志，的确有点疯狂。这篇文章就聊聊Nacos的日志系统。事件背景经过排查，其中输出最多的日志为{nacos.home}/logs/access_log.yyyy-mm-dd.log格式的日志。日志中包含了微服务系统调用Naco

前言学习一个技术框架，最快速的手段就是将其集成到项目中，体验一下它的功能。在这个过程中，你还踩到很多坑。而排坑的过程，又是一次能力的提升。前面我们写了一些列Nacos的文章，经过《学习Nacos？咱先把服务搞起来，实战教程》的介绍，我们已经可以把Nacos Server给启动起来了。这篇文章，我们就来学习一下如何将Nacos集成到Spring Cloud项目中，同时实例演示一下，基于Nacos的微服务之间的两种调用形式。集成与版本为了演示这个案例，大家首先要将Nacos Server跑起来。同时会

前言前面已经写不少Nacos相关的文章了，比如《Spring Cloud集成Nacos服务发现源码解析？翻了三套源码，保质保鲜！》，而且目前也计划写一个Spring Cloud的技术解析专栏，一个技术框架一个技术框架的为大家拆解分析原理和实现。既然拿Nacos作为一个开始，那么我们这篇文章就来补充一下Nacos Server的部署以及Nacos Client的调用，直观的了解一下Nacos都包含了什么功能。这是使用Nacos的基础，也是后续进行深度剖析的依据。强烈建议一起学习一下。Nacos Serv

前面文章我们介绍了Nacos的功能及设计架构，这篇文章就以Nacos提供的服务注册功能为主线，来讲解Nacos的客户端是如何在Spring Cloud进行集成和实现的。本会配合源码分析、流程图整理、核心API解析等维度来让大家深入浅出、系统的来学习。Spring Boot的自动注册故事要从头Spring Boot的自动注入开始。很多朋友大概都了解过Spring Boot的自动配置功能，而Spring Cloud又是基于Spring Boot框架的。因此，在学习Nacos注册业务之前，我们先来回顾一下

前言最近写了一些列的Nacos源码相关文章，很多朋友都感兴趣的在问：你最近在阅读什么源码，如何阅读源码？今天这篇文章就以Nacos源码阅读来展开聊聊。对阅读源码或技术感兴趣的朋友，也可以添加微信交流（微信号：zhuan2quan）。在读这篇文章的时候呢，要看你想获得什么了。因为这篇文章亦是在写如何阅读Nacos源码，也是在写如何阅读源码。不要被技术栈所束缚，要提炼属于自己的方法。看你所欲，取你所需。阅读源码的目的不清楚大家为什么要阅读源码，就聊聊个人阅读源码的目的，或许可以拿来借鉴。学习底层原理与

为什么要使用服务发现功能？当调用REST API 或Thrift API的服务时，我们在构建请求时通常需要知道服务实例的IP和端口。在传统应用中，服务实例的地址信息相对固定，可以从配置文件中读取。而这些地址也只是只会偶尔更新。但在现代应用程序中，往往是基于云的微服务架构，此时获取服务实例的IP和端口便是一个需要解决的难题。如下图所示：上图中，服务实例实例的IP是动态分配。同时，还面临着服务的增减、故障以及升级等变化。这对于客户端程序来说，就需要使用更精确的服务发现机制。目前，服务发现模式主要有两种

前言Nacos在微服务系统的服务注册和发现领域，势头迅猛是肉眼可见的。在微服务系统中，服务的注册和发现又是一个灵魂的存在。没有注册中心的存在，成百上千服务之间的调用复杂度不可想象。如果你计划或已经在使用Nacos了，但仅停留在使用层面，那这篇文章值得你一读。本文我们先从服务发现机制说起，然后讲解Nacos的基本介绍、实现原理、架构等，真正做到深入浅出的了解Nacos。服务注册与发现说起Nacos，不得不先聊聊微服务架构中的服务发现。关于服务发现其实已经在《要学习微服务的服务发现？先来了解一些科普知