- 博客(17)
- 收藏
- 关注
RSS订阅原创 10 Nacos 如何在集群中同步实例信息
在微服务架构中，服务发现与配置管理的核心诉求是数据一致性与服务可用性的动态平衡。然而由于分布式系统天然面临网络分区（Partition Tolerance，P）的不可控风险，CAP 原则又明确了三者不可兼得的铁律——在必须保障 P 的前提下，系统只能在一致性（Consistency，C）与可用性（Availability，A）之间做出取舍。Nacos 作为一站式服务治理中间件，其核心创新在于采用双协议协同架构应对差异化场景需求：Raft 协议强化 CP 特性，保障核心数据的强一致性；Distro 协议主
2025-12-14 23:14:22
903
原创 03 运动康复：让我们的脊柱重返青春
“生命在于运动” 这句话，想必大家早已耳熟能详。而运动对脊柱（尤其是颈椎与腰椎）的养护作用，我结合自身经验总结出两大核心：一是通过针对性锻炼增强脊柱周围肌肉的支撑力，从而减轻脊柱自身的承重压力；二是通过规律运动提升身体灵活性，缓解肌肉长期紧绷带来的僵硬感。
2025-12-12 20:00:00
496
原创 02 姿态调整：解决 80% 的脊柱健康问题
作为打工人的我们，不可能有大把大把的时间可以泡在健身房或者躺在床上，我们绝大部分时间都在工作，要不坐着敲代码，要不站着开会、讨论。从解决 80% 问题的角度出发，我们也要重视姿态调整，有句俗话说得好：“站有站相、坐有坐相”。如果站得歪歪倒倒，坐的时候又含腰驼背，就算是每天抽大把的时间锻炼，效果也会大打折扣，甚至加速脊柱退变。
2025-12-12 19:37:59
750
原创 01 看清敌人！颈椎腰椎的构造与劳损真相
你是否已经习惯了颈部的僵硬和腰部的酸胀？别再把这一切问题简单归咎于“累了”。我们的颈椎和腰椎，正因其精妙而脆弱的结构，在日复一日的重压下悄然退变。本文将带你直击问题核心，看清脊柱的“设计原理”，明白疼痛从何而来，以及你正处在哪个危险的阶段。正所谓“知己知彼，方能百战不殆”。
2025-12-08 20:54:32
600
原创 00 人未老，脊柱先老？程序员的脊柱自救指南（系列开篇）
程序员久坐工作容易引发腰颈问题，本文分享保护脊柱健康的实用经验。核心建议三点：保持正确坐姿、加强核心力量训练、提升身体灵活性。作者计划通过系列文章详细讲解，包括脊柱生理结构、正确坐姿示范、有效锻炼方法、显示器选择建议以及乘车时的脊椎保护技巧。通过科学调整日常习惯，帮助程序员群体缓解职业带来的身体负担，实现健康工作。
2025-12-08 20:36:39
346
原创 09 gRPC & Netty 在 Nacos 客户端 & 服务端通信中的应用
gRPC 是由 Google 开发的一款高性能、开源的远程过程调用（RPC）框架，旨在简化跨服务、跨语言的通信，广泛应用于微服务架构中服务间的高效交互。gRPC 底层依赖 Netty 作为网络传输引擎，两者协作实现了高效的跨服务通信。关于 Netty 的源码分析，后续我也会单独出一个文集，大家敬请期待吧 😄在 2021 年 3 月发布的 Nacos 2.0.0 版本就将 gRPC 作为核心通信协议，替代了 Nacos 1.x 上的 HTTP/1.1 和 UDP 协议。
2025-11-09 21:29:58
919
原创 08 Nacos 客户端服务下线 & 服务端删除注册信息
当 Nacos 客户端服务下线时，需要立即通知到 Nacos 服务端，并将服务注册信息删除。同时还要通知到相关订阅该服务的客户端，否则就会出现服务远程调用失败的问题。Nacos 服务端对客户端的健康检查Nacos 服务端的连接感知机制客户端主动发起注销操作其中，第 2 种方式比较隐蔽，底层是基于 gRPC 连接感知机制实现的。LoadBalancer 提供的缓存（如果引入 Spring Cloud LoadBalancer 的话，会使用 Caffeine 作为缓存组件）
2025-11-09 18:04:13
1462
原创 07 Nacos 服务端对客户端进行健康检查，并将不健康的客户端进行下线
服务 A、服务 B 在启动时会将自身注册到 Nacos 上，当服务 A 需要远程调用服务 B 时，会从 Nacos 获取服务 B 对应远程服务的 IP + 端口号，然后发起调用。此时如果服务已 B 不可用，就会导致服务 A 远程调用报错。因此就需要 Nacos 服务端能提前检测到服务 B 是否可用，也就是对服务 B 进行健康检查，并将不健康服务 B 实例（客户端）进行下线。这样服务 A 通过 Nacos 拿到的服务 B 实例才是健康的，可处理请求的。
2025-11-08 23:26:34
705
原创 06 Nacos 服务注册源码解析：服务查询
本文主要分析 Nacos 服务查询相关源码。假设订单服务 order-service 需要远程调用库存服务 stock-service 查询商品库存数量，如果我们使用的是 Open Feign 组件进行远程调用，它底层会基于 Ribbon 负载均衡，在远程调用前就会去获取远程服务的调用信息（IP + 端口号），获取服务信息的过程就涉及到服务查询。服务查询算是 Nacos 服务注册比较难的一个章节了！
2025-11-08 22:24:37
1010
原创 05 Nacos 服务注册源码解析：服务注册
从本文开始，就正式进入 Nacos 服务注册源码分析啦！至于为什么要把它放在配置中心之后来分析呢？原因有二：1️⃣ 从我自身项目经验来看，平时开发过程中很少会遇到服务注册相关的问题，大部分的问题还是配置相关问题，比如为什么改了配置没有自动更新等等。2️⃣ 注册中心的难度和复杂度更大，涉及到的异步操作更多。当然，本系列文章的分析也只是入门级的，主要还是考虑到自身能力水平有限😭。说了这么多，现在就开始吧！！！
2025-11-07 22:50:12
833
原创 04 Nacos 配置管理源码解析：客户端感知配置的变化
当 Nacos 服务端配置发生变化后，客户端是如何感知此变化的呢？客户端感知到配置变化以后，又是如何更新本地配置信息的呢？相信看完本文，你将会得到答案。万事开头难，今天终于将 Nacos 配置管理核心源码分析更新完了。后续将继续更新 Nacos 服务注册核心源码分析。
2025-11-07 22:42:15
941
原创 03 Nacos 配置管理源码解析：配置修改后的同步操作
当我们尝试在 Nacos Web 管理端修改配置后，配置信息是如何同步到 Nacos 服务端各个节点，以及通知到 Nacos 客户端的呢?通常我们会通过集群的方式部署 Nacos，集群中的 Nacos 节点类型包含 Leader、Follower。Web 管理端，其它 Follower 节点则通过配置同步的方式修改本地配置信息。
2025-11-04 23:17:12
1030
原创 02 Nacos 配置管理源码解析：Spring Boot 整合配置中心
首先总结一下 Nacos 获取配置文件的方式：优先从本地磁盘获取配置文件本地没有，就从远端服务获取配置文件，并写入本地磁盘Nacos 服务端配置文件发生变化时，会通知客户端更新磁盘中的配置文件（后续文章会分析）只从本地磁盘获取配置文件在服务启动时，会将配置文件写入本地磁盘当配置发生变化时，会刷新磁盘中的配置文件（后续文章会分析）后续会分析配置文件修改以后，Nacos 服务端是如何更新配置文件，并将变更同步至其它 Nacos 节点的。以及如何通知客户端进行配置的热更新。
2025-11-03 22:09:23
1055
原创 AQS的应用：ReentrantLock源码分析
AQS: AbstractQueuedSynchronizer，抽象队列同步器。用来实现锁或其他同步器组件的公共基础部分的抽象实现，是重量级基础框架及整个JUC体系的基石，用于解决锁分配给“谁”的问题。常见的同步组件如ReentrantLock、ReentrantReadWriteLock、CountdownLatch等都是基于AQS实现的（通过内部类extend AQS）。AQS内部包含一个CLH变体队列，抢不到锁的线程将会被封装成一个Node并进入此队列，而此处的锁实际上就是state变量(类型)。一旦
2022-06-20 22:48:13
187
1
原创 JMM如何解决重排序问题
随着现代CPU从提升单核性能转变到提升多核性能，并发编程显得愈发重要。通过多线程的协同工作使得程序的执行效率更高！同时，计算机软硬件为了提升程序执行效率，对指令做了重排序操作，分为三种类型：Java内存模型JMM是一个抽象概念，涵盖了缓存、写缓冲区、寄存器以及其它硬件和编译器优化，用于解决Java多线程对共享数据的读写一致性问题。在JMM中变量的值从线程A到线程B要经过两个阶段：线程A将工作内存中更新过的共享变量刷到主内存中；线程B从主内存中读取线程A更新过的变量。基于上述软硬件层面的重排序操作以及JMM内
2022-06-20 22:41:31
225
原创 Spock入门 - 快速开始&基础语法
环境搭建配置pom.xml依赖<dependencies> <!-- 若本机安装了groovy，无需此依赖 --> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>2.4.15</versio
2020-05-19 11:30:53
2277
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人