<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[brilliant_stone的博客]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/brilliant_stone</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; brilliant_stone]]></copyright><item><title><![CDATA[gRPC新手指南:3min了解核心概念]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155786117</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155786117</guid><author>brilliant_stone</author><pubDate>Wed, 10 Dec 2025 17:15:10 +0800</pubDate><description><![CDATA[3min用图片带你快速了解gRPC的核心概念]]></description><category></category></item><item><title><![CDATA[(垃圾佬)-低成本低存储构建海量构件仓库：基于 Linux + Rclone 聚合存储的 Nexus 仓库]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155646027</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155646027</guid><author>brilliant_stone</author><pubDate>Sat, 06 Dec 2025 19:28:15 +0800</pubDate><description><![CDATA[通过 Linux 强大的 FUSE 生态和 Rclone 的巧妙配置，将这一组分散、免费的云存储资源，转化为了一个高可用、可无限水平扩展的 Nexus 存储后端。这不仅解决了 VPS 硬盘昂贵的痛点，更提供了一种处理海量冷数据的通用思路。对于预算有限但技术折腾能力强的团队来说，这无疑是一个极具性价比的“降本”方案。]]></description><category></category></item><item><title><![CDATA[【K8s硬核实战】打破网络边界：构建安全、自维护的节点级边缘代理网络]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155488266</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155488266</guid><author>brilliant_stone</author><pubDate>Tue, 02 Dec 2025 11:15:46 +0800</pubDate><description><![CDATA[在混合云或边缘计算场景中，Kubernetes 节点往往分布在不同的物理局域网内。如何让集群内的 Pod 安全地通过特定节点访问该节点所在局域网的资源（如打印机、数据库），同时又不暴露宿主机端口？本文将介绍一种利用 DaemonSet + InitContainer 实现“服务自注册”的自动化方案，打造一套零侵入、高安全的集群内边缘代理系统。]]></description><category></category></item><item><title><![CDATA[超越性能： gRPC 助力微服务的“零信任”安全堡垒]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155199194</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155199194</guid><author>brilliant_stone</author><pubDate>Mon, 24 Nov 2025 16:43:30 +0800</pubDate><description><![CDATA[用TLS 1.3解决“看不见、改不了”的问题；用mTLS解决“服务间互信”的问题；用解决“用户身份传递”的问题；用拦截器解决“权限控制收敛”的问题。构建 gRPC 微服务，不仅仅是定义.proto文件那么简单。真正的挑战在于如何将这些安全组件像乐高积木一样，无缝地嵌入到你的基础设施中，让开发人员在无感知的情况下，写出最安全的代码。安全不是一个可以通过“安装”获得的功能，而是一种持续的架构设计。希望这份基于 gRPC 的深度解析，能为你构建下一代微服务提供坚实的理论基础。]]></description><category></category></item><item><title><![CDATA[超越 REST：为何 gRPC 是现代微服务的“中枢神经系统”]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155195439</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155195439</guid><author>brilliant_stone</author><pubDate>Mon, 24 Nov 2025 14:40:50 +0800</pubDate><description><![CDATA[回顾 gRPC 的设计，你会发现它不仅仅是一个 RPC 框架，它是一套微服务最佳实践的固化。它强制你写契约（Protobuf），强制你考虑超时（Deadline），强制你处理连接复用（HTTP/2），并内置了负载均衡（Load Balancing）和服务发现的接口。它就像一个经验丰富的老架构师，把分布式系统中可能遇到的坑，在框架层面填平了。在构建高性能、可扩展的分布式系统时，gRPC 正在成为事实上的标准。它不仅连接了代码，更连接了对系统健壮性的共同认知。]]></description><category></category></item><item><title><![CDATA[Spring AI：构建企业级 Java AI 应用的未来蓝图]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155167522</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155167522</guid><author>brilliant_stone</author><pubDate>Sun, 23 Nov 2025 21:04:27 +0800</pubDate><description><![CDATA[在人工智能技术飞速发展的浪潮中，Java 生态系统正迎来一次关键的现代化机遇。Spring AI——一个旨在为 Java 开发者提供统一、便携、强大的 AI 编程模型，以驱动下一代企业级智能应用的核心框架]]></description><category></category></item><item><title><![CDATA[驯服单体巨兽：Spring Modulith]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155159987</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155159987</guid><author>brilliant_stone</author><pubDate>Sun, 23 Nov 2025 12:38:32 +0800</pubDate><description><![CDATA[Spring Modulith 并非要取代微服务,而是为构建“结构化单体应用”提供的一套官方工具集。它帮助开发者在单体应用内部强制执行模块边界,实现高内聚、低耦合,从而提升代码的可维护性和可扩展性。本演示将引导您完成一次完整的“开发者之旅”,从模块定义、验证、测试到文档生成与生产环境观测。]]></description><category></category></item><item><title><![CDATA[Kubernetes 节点存储治理：容器镜像清理的原理、实践与自动化策略]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155139237</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155139237</guid><author>brilliant_stone</author><pubDate>Sat, 22 Nov 2025 20:47:00 +0800</pubDate><description><![CDATA[在 Kubernetes 集群的长期运维中，节点磁盘空间不足是导致 Pod 驱逐和节点不可用的常见原因。本文深入剖析 Kubernetes 镜像垃圾回收的内部机制，详细介绍在抛弃 Docker 之后如何利用 CRI 工具进行精准的镜像清理，并探讨基于 Eraser 的自动化运维方案以及操作背后潜藏的安全风险。]]></description><category></category></item><item><title><![CDATA[Longhorn 加密存储：从配置到验证，彻底阻断宿主机越权访问]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/155002234</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/155002234</guid><author>brilliant_stone</author><pubDate>Tue, 18 Nov 2025 21:43:58 +0800</pubDate><description><![CDATA[在云原生环境中，存储安全是至关重要的一环。本文详细记录了我一次部署和验证 Longhorn 加密存储的完整过程，旨在解决一个核心安全问题：即便获得宿主机 root 权限，也无法访问 Kubernetes 集群中的敏感数据。文章不仅涵盖了标准的配置步骤，更复盘了一次由 `StorageClass` 配置不完整引发的 `FailedMount` 故障排查，详细介绍了不同 Linux 发行版的前置依赖准备，最终通过在宿主机层面直接验证加密效果，为 Longhorn 加密功能的有效性提供了确凿证据。]]></description><category></category></item><item><title><![CDATA[将 Nginx Ingress 的 NodePort 精确地只暴露在单个节点上，而不是所有的节点都开放端口]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/154182081</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/154182081</guid><author>brilliant_stone</author><pubDate>Fri, 31 Oct 2025 13:43:18 +0800</pubDate><description><![CDATA[多节点集群中只让某个机器开放端口，以nginx-ingress-controller为例来进行演示]]></description><category></category></item><item><title><![CDATA[nexus docker仓库保留N个最新的镜像 脚本分享]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/154133094</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/154133094</guid><author>brilliant_stone</author><pubDate>Thu, 30 Oct 2025 17:53:58 +0800</pubDate><description><![CDATA[通过脚本来自动化的删除自托管nexus的docker仓库中的无用镜像但至少保留N个最新的]]></description><category></category></item><item><title><![CDATA[ApplicationModuleListener 不生效不起作用]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/153772547</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/153772547</guid><author>brilliant_stone</author><pubDate>Thu, 23 Oct 2025 09:54:23 +0800</pubDate><description><![CDATA[通过源码解释 spring modulith 的 ApplicationModuleListener 不生效 而 spring自带的 EventListener 却正常触发的问题]]></description><category></category></item><item><title><![CDATA[30个代码片段+20min 带你领略DDD领域驱动的美]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/153196962</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/153196962</guid><author>brilliant_stone</author><pubDate>Mon, 13 Oct 2025 15:28:20 +0800</pubDate><description><![CDATA[DDD 领域驱动设计让代码结构直接反映业务逻辑，而不是被技术框架主导。✅ 领域对象要有行为，不是数据容器✅ 业务规则集中在领域层，不要分散在 Service✅ 使用值对象替代基本类型✅ 聚合边界清晰，一个聚合一个仓储✅ 领域层不依赖框架和技术细节✅ 跨聚合通过 ID 引用，不直接引用对象✅ 用事件实现模块间解耦DDD 的核心思想:业务优先: 代码直接反映业务逻辑领域核心: 领域模型是软件的核心，技术是外围统一语言: 代码术语和业务术语一致边界清晰: 模块边界明确，职责单一。]]></description><category></category></item><item><title><![CDATA[乐观锁如何保证并发控制?]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/153040416</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/153040416</guid><author>brilliant_stone</author><pubDate>Sat, 11 Oct 2025 10:38:03 +0800</pubDate><description><![CDATA[实现思路一般是自旋比较。图揭示了乐观锁在事务的情况下如何保证并发，虽然两者同时开启事务，但是B在比较的过程中发现了数据不一致，主动放弃了修改，从而保证事务AB之间的结果不会覆盖，同时应用层又能感知到update修改的行数来决定是回滚还是提交数据来保证业务数据的正确性。乐观锁还有一个缺点，上述揭示了事务B再等A释放锁，也就是出现阻塞情况，那么升级问题，事务A和B同时开始，A先修改数据a再修改数据b，事务B先修改数据b在修改数据a，A对a的i修改，和B对b的修改同时完成，二者开始阻塞等待对方释放锁。]]></description><category></category></item><item><title><![CDATA[优雅的实现“命令链”(责任链+命令模式)]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/149227420</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/149227420</guid><author>brilliant_stone</author><pubDate>Wed, 09 Jul 2025 16:57:28 +0800</pubDate><description><![CDATA[我认为：命令链模式，并不是对经典命令模式的否定，而是它的一种演进和组合。命令模式的贡献 (封装请求)]]></description><category></category></item><item><title><![CDATA[数据库设计：警惕entity_type的设计]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/149200547</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/149200547</guid><author>brilliant_stone</author><pubDate>Wed, 09 Jul 2025 16:05:15 +0800</pubDate><description><![CDATA[最近总结了之前的一个ERP项目的设计，最开始订单表和库存表都是主子表结构，子表为物料清单表(实际上是两个表，但是完全一致)，主表则各有侧重，比如订单有更多的客户和运费相关的内容，库存则有更多的仓库和供应商的信息，二者小部分重叠但在后续长达一年的功能更新&bug修复中，二者趋同，从原来只是小部分重叠，变成了大部分重叠，甚至不重叠的属性其实只是一些无关紧要的装饰字段两者又同时关联了一个佣金表，为了同时支持佣金表指向订单和库存，引入了一个type字段，通过type字段+id来唯一的指向某个产品,结构如下示意。]]></description><category></category></item><item><title><![CDATA[【图文并茂】数据库中存储树形结构的四种方法]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/149174520</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/149174520</guid><author>brilliant_stone</author><pubDate>Mon, 07 Jul 2025 19:27:36 +0800</pubDate><description><![CDATA[究其原因, 数据库中存储树的难题主要是: 树的深度是不可估计 而 表中一行的信息长度是 可知且确定的我们无法在一行中存储一个完整的树，只能通过不同的数据组织方式，在不同的行中整合出一棵树。主要的组织方式主要有 : 邻接表、物化路径、嵌套集和闭包表， 四种方式通过不同的结构来构建出针对特定问题的树，下文中将逐个解释每种方式的优缺点.]]></description><category></category></item><item><title><![CDATA[Spring 框架在运行时无法获取到方法的参数名]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/149155060</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/149155060</guid><author>brilliant_stone</author><pubDate>Sun, 06 Jul 2025 17:07:43 +0800</pubDate><description><![CDATA[这个问题的根本原因在于 Java 编译器在默认情况下，并不会将方法的参数名称保留在编译后的 .class 文件中。如果您的项目是聚合项目，并且子模块没有直接继承自 spring-boot-starter-parent，那么上述配置可能不会生效。大多数标准的 Spring Boot 项目，可以在 maven-compiler-plugin 的配置中添加 -parameters 编译参数。具体的方案是 使用 -parameters  参数， 在编译时，将方法的。就一个例子来说， 你之前的方法签名是。]]></description><category></category></item><item><title><![CDATA[Docker容器限制出站带宽]]></title><link>https://blog.youkuaiyun.com/brilliant_stone/article/details/148634896</link><guid>https://blog.youkuaiyun.com/brilliant_stone/article/details/148634896</guid><author>brilliant_stone</author><pubDate>Fri, 13 Jun 2025 16:10:11 +0800</pubDate><description><![CDATA[人话速览:服务器小鸡太垃圾了，一个alist容器给我带宽干爆了，写个脚本限制下出站带宽，让我重新连上小鸡在日常的服务器管理中，我们经常会遇到某些 Docker 容器占用大量网络带宽的情况，这可能会影响到服务器上其他服务的正常运行。例如，一个正在同步大量数据或提供下载服务的容器，可能会成为网络瓶颈。Linux 内核提供了强大的tc(Traffic Control) 工具，可以对网络流量进行精细化控制。虽然tc。]]></description><category></category></item></channel></rss>