裸金属 Nginx + Keepalived + HAProxy 企业级网关方案
本方案用于在裸金属主机上部署一套企业级 Web 网关，适用于前后端分离系统。
Maven 核心机制学习笔记：POM 继承、Profiles、生命周期、依赖作用域与版本
Maven 的核心并不只是“下载依赖和执行 mvn package”，它实际上围绕 POM、构建生命周期、依赖管理、Profile 和版本体系组织整个 Java 工程的构建过程。本文把日常开发中最常用、也最容易混淆的几个点放在一起梳理。
Linux SSH 免密登录与批量主机管理：从 Passphrase、ssh-agent 到 SSH Config
简介在 Linux 服务器管理中，SSH 几乎是所有远程运维动作的基础。无论是日常登录服务器、远程执行命令、使用 scp 传输文件，还是通过 rsync 做增量同步，底层通常都依赖 SSH。 最开始接触 SSH 时，我们往往使用最直接的方式： 1ssh rocky@192.168.0.50 然后输入服务器密码。 这种方式对于一台服务器没有问题，但当需要长期管理多台机器时，问题会很快暴露出来： 1
Rocky Linux 9 NFS 完整学习笔记：原理、配置、自动挂载与实操实验
以 Rocky Linux 9 为实验环境，从 NFS 基础原理、服务端配置、UID/GID 权限模型，到 NFSv3/NFSv4、fstab、systemd automount、autofs、故障排查与完整实验，系统学习 Linux NFS。
Java 生产级工程实践：从函数式编程到故障诊断与 Kubernetes
写 Java 业务代码并不难，真正拉开工程能力差距的，往往是代码进入生产之后的那一段：如何用更清晰的方式表达业务逻辑，如何理解线程、内存、GC 与网络的真实运行状态，如何在没有 Debugger 的生产环境里留下证据并定位根因，以及应用迁移到 Kubernetes 后如何重新认识 CPU、内存、Pod 生命周期和故障现场。本文把这些问题放到同一条工程链路中，从 Java 8 的函数式编程讲到 JV
Java 业务安全设计：从不信任客户端到幂等、注入防护与敏感数据保护
很多业务安全事故并不是因为缺少复杂的密码学算法，而是因为最基本的边界没有守住：服务端相信了客户端计算结果，把外部输入拼进了 SQL 或脚本，把用户 ID 当成普通参数接收，资金操作没有全链路幂等，敏感数据又以不合适的方式保存。本文从 Java 业务开发视角重新组织这些问题，建立一条从请求入口、身份与权限、资源防刷、资金幂等、注入防护，到密码、隐私数据和 TLS 传输的完整安全链路，并结合现代 Sp
Java 业务系统工程化设计：从反射、Spring 到缓存、异步与多存储架构
业务系统真正困难的地方，往往不是把一个接口写出来，而是让代码在长期演进、并发访问、依赖故障、版本升级和流量增长之后仍然保持可维护、可扩展、可恢复和可观测。本文从 Java 反射、泛型与注解的语言边界出发，逐步进入 Spring IoC/AOP、接口设计、缓存与异步可靠性、生产可观测性以及 MySQL、Redis、Elasticsearch、时序数据库协同设计，整理一套面向真实业务系统的工
Java 业务开发中的十类隐蔽陷阱：从对象判等到 OOM
Java 业务代码真正难排查的 Bug，往往不是复杂算法写错，而是一些“看起来理所当然”的语义在边界条件下突然失效：== 偶尔能正确比较包装类型、BigDecimal.equals 不认为 1.0 和 1 相等、subList 只是原 List 的视图、异步日志会丢数据、submit 会把线程池异常藏进 Future，甚至一个看似只是“放大限制”的 Tomcat 参数也可能把堆内存吃光。本文把对象
Java 业务开发常见陷阱：并发、池化、HTTP、事务与索引的工程化实践
Java 业务系统真正难处理的部分，往往不是把一个接口写通，而是在并发、超时、重试、资源耗尽和异常回滚同时发生时，仍然保证数据正确、吞吐稳定且问题可定位。本文围绕并发容器与锁、线程池、连接池、HTTP 调用、Spring 声明式事务和 MySQL 索引六条主线，重新组织这些看似分散的问题，并结合 JDK 21、Spring Framework 6.x、Spring Cloud OpenFeign、
区块链应用与工程实践：从数字资产、交易所到 BaaS、供应链与 Tinychain
区块链真正进入工程实践后，问题很快就从“区块如何连接、共识如何工作”扩展到资产如何表示、交易所如何记账、钱包如何管理多条链、链上数据如何索引、身份和供应链怎样接入，以及一个最小区块链节点究竟由哪些模块组成。本文从数字资产出发，逐步串联交易平台、钱包服务、BaaS、数字身份、供应链和 Tinychain 实现，形成一套从业务应用到基础设施、再回到底层节点设计的完整区块链工程视角。
区块链系统设计进阶：性能、智能合约、共识、治理与公私链架构
区块链真正难理解的地方，不是哈希、签名或区块结构本身，而是这些机制放进一个开放分布式系统后产生的工程权衡：节点越开放，共识和数据传播越昂贵；执行能力越强，状态同步与安全边界越复杂；治理越自动化，投票权、激励与攻击面也越需要重新设计。本文从交易性能和“去中心化”的关系出发，串起智能合约与以太坊、Token 标准、公链项目的架构选择、联盟链与 Hyperledger、比特币扩容之争以及链上治理，并结合
区块链底层技术：P2P 网络、共识机制、密码学与账本模型
真正理解区块链，不能只停留在“分布式账本”和“不可篡改”几个概念上。一个能够运行的区块链系统，需要同时解决节点如何发现彼此、交易如何传播、恶意节点存在时如何达成共识、资产所有权如何通过密码学证明、历史数据如何组织，以及状态究竟采用 UTXO 还是账户模型表达。本文把这些原本分散的知识重新组织成一套完整技术体系，并结合 Bitcoin、Ethereum 等典型系统解释各层之间如何协作。
区块链基础原理：从分布式账本、共识机制到数字货币与钱包
区块链并不只是“把数据串成链”，也不等于比特币或数字货币。真正理解它，需要把 P2P 网络、密码学、交易模型、区块结构、共识机制、经济激励和数字资产放到同一个系统里观察。本文从中心化记账的问题出发，以比特币为主要样本，梳理一笔交易从钱包签名、网络广播、矿工打包到最终确认的完整过程，并进一步讨论 PoW、双花、钱包、Token、数字货币、联盟链、应用边界以及区块链工程选型。
RFC 10：Documentation Conventions——当技术讨论开始扩容，RFC 如何成为一套可运行的协作协议
RFC 10 没有定义一个网络报文，却解决了另一个同样真实的系统问题：当参与 ARPANET 协议设计的人和站点迅速增加时，技术意见怎样被唯一编号、稳定引用、可靠分发，又怎样避免“写成文档就自动变成权威结论”。它对 RFC 3 的修订幅度并不大，恰恰因此更值得读——真正发生变化的不是写作哲学，而是这套协作机制开始从几个人之间的工作笔记，向一个需要治理编号、参与者和分发拓扑的技术基础设施演化。
经典软件架构风格与子风格：数据流、调用返回、独立构件、虚拟机与仓库
软件架构风格关注的并不是某个具体框架，而是系统中构件如何组织、构件之间如何连接、数据怎样流动以及控制权如何转移。经典软件体系结构通常可以从数据流、调用/返回、独立构件、虚拟机和以数据为中心的仓库五个家族理解，并进一步细分为批处理、管道-过滤器、主程序-子程序、面向对象、分层、通信进程、事件系统、解释器、规则系统、数据库仓库和黑板等具体子风格。本文从构件、连接件、控制模型、数据模型、优缺点
软件架构方法论：ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking
软件架构并不是画出一张组件关系图就结束了。从领域共性提炼、架构设计，到质量属性评估、风险与权衡分析，再到成本收益决策，不同阶段需要解决完全不同的问题。本文系统整理 ABSD、DSSA、SAAM、ATAM、CBAM 与 Architectural Thinking，重点说明它们各自解决什么问题、核心流程是什么、彼此如何衔接，以及如何在真实软件项目中组合使用。
RPC 高级工程实践与源码脉络：异步、安全、可观测、流量治理与协议演进
RPC 真正进入生产环境之后，问题很快就会超出“如何完成一次远程方法调用”的范围：吞吐量为什么上不去、内部服务如何鉴权、跨服务异常怎样定位、大量超时任务怎样低成本调度、架构升级如何利用真实流量验证、隔离集群怎样快速扩容、没有接口 Jar 如何调用服务，以及新旧 RPC 协议如何平滑共存。本文从这些工程问题出发，结合一套插件化、纯异步 RPC 的代码结构，把性能、安全、可观测性、流量治理、泛化调用、
RPC 框架进阶设计：从插件化架构到服务治理与无损上下线
RPC 的核心目标看似简单：把本地方法调用转换成网络请求，再在远端恢复方法语义。但真正进入生产环境后，问题很快会从“如何完成一次远程调用”扩展到“如何发现实例、判断节点是否健康、控制流量、处理失败、保护上下游以及实现无损发布”。本文从 RPC 框架整体架构出发，系统梳理插件化设计、服务发现、健康检测、路由、负载均衡、异常重试、优雅启停、熔断限流与业务分组，并把这些能力重新组织成一套完整的 RPC