RPC 高级工程实践与源码脉络：异步、安全、可观测、流量治理与协议演进
RPC 真正进入生产环境之后，问题很快就会超出“如何完成一次远程方法调用”的范围：吞吐量为什么上不去、内部服务如何鉴权、跨服务异常怎样定位、大量超时任务怎样低成本调度、架构升级如何利用真实流量验证、隔离集群怎样快速扩容、没有接口 Jar 如何调用服务，以及新旧 RPC 协议如何平滑共存。本文从这些工程问题出发，结合一套插件化、纯异步 RPC 的代码结构，把性能、安全、可观测性、流量治理、泛化调用、
RPC 框架进阶设计：从插件化架构到服务治理与无损上下线
RPC 的核心目标看似简单：把本地方法调用转换成网络请求，再在远端恢复方法语义。但真正进入生产环境后，问题很快会从“如何完成一次远程调用”扩展到“如何发现实例、判断节点是否健康、控制流量、处理失败、保护上下游以及实现无损发布”。本文从 RPC 框架整体架构出发，系统梳理插件化设计、服务发现、健康检测、路由、负载均衡、异常重试、优雅启停、熔断限流与业务分组，并把这些能力重新组织成一套完整的 RPC
RPC 核心原理：从通信流程、协议与序列化到 Netty、动态代理和 gRPC
RPC（Remote Procedure Call，远程过程调用）是分布式系统中最基础的通信抽象之一。它真正解决的并不只是“让两台机器能够通信”，而是如何把接口代理、协议 framing、序列化、网络 IO、请求与响应关联、服务端分发等复杂过程隐藏起来，让业务代码尽可能获得类似本地方法调用的开发体验。本文从一次完整 RPC 调用出发，系统梳理协议设计、序列化选型、IO 多路复用、零拷贝、动态代理，
Spring Security OAuth 2.0 + JWT 实战：从零搭建授权服务器、资源服务器与 OAuth Client
OAuth 2.0 如果只停留在授权码、Access Token、Refresh Token 等概念层面，很容易出现“流程看懂了，真正写代码还是不会”的情况。本文以 Spring Boot、Spring Security OAuth 与 JWT 为基础，完整搭建 Authorization Server、Resource Server 和 OAuth Client 三个应用，从数据库、JWT 非对
OAuth 2.0 与 Spring Security：从授权模型、安全机制到微服务架构实践
OAuth 2.0 真正困难的地方并不是“如何拿到一个 access_token”，而是理解用户、客户端、授权服务器和资源服务器之间的委托关系，以及授权码、Scope、PKCE、JWT、网关和业务权限分别应该解决什么问题。本文从 OAuth 2.0 的核心模型出发，串联授权码流程、安全漏洞、开放平台、微服务架构与 Spring Security 实践，并重点说明早期 Spring Security
OAuth 2.0 深入理解：授权码、令牌、PKCE、JWT、OIDC 与开放平台实践
OAuth 2.0 的价值并不只是“生成一个 Token”，而是建立一套能够在不向第三方暴露用户凭据的前提下，将有限资源访问权限安全委托出去的授权体系。本文从 OAuth 2.0 为什么出现开始，系统梳理四种角色、授权码流程、Scope、访问令牌与刷新令牌、JWT、PKCE、OIDC、SSO 以及开放平台架构，并结合当前安全最佳实践说明哪些早期授权模式已经不应继续使用。
RFC 9 带读：Host Software——从 Logical Link 到 Service Call，早期 Host-Host 协议开始进入操作系统
前言RFC 9 的标题再次回到一个看起来很普通的名字：Host Software。 但如果把它和前面的 RFC 1、RFC 2、RFC 7、RFC 8 放在一起看，会发现它已经明显进入了另一个阶段。 RFC 1 还在讨论： 1Host Software 大概应该做什么？ RFC 7 开始讨论： 12Network Program、Handler、Buffer在 Host 里应该怎么组织？ RF
RFC 8 带读：ARPA Network Functional Specifications——从链路、校验到远程 NLS，早期 ARPANET 功能规格的第一次收束
前言RFC 8 的标题是 ARPA Network Functional Specifications（ARPA 网络功能规格）。 和前几篇 RFC 相比，这个标题突然显得“正式”了很多。 RFC 1、RFC 2 主要在讨论 Host Software 应该有哪些能力；RFC 6 记录 Steve Crocker 与 Bob Kahn 关于 Host–IMP Interface 的一次谈话；RFC
RuoYi 权限体系源码解析：菜单、按钮、接口权限与数据权限如何协同
RuoYi 的权限体系表面上围绕“菜单管理”和“角色授权”展开，底层实际由两条相对独立的链路组成：一条负责目录、页面、按钮和接口操作的功能权限，另一条负责限制用户能够查询哪些部门或个人数据。本文以 RuoYi v4.8.3 当前源码为基线，从 sys_menu、Shiro UserRealm、@RequiresPermissions、Thymeleaf 按钮控制、@DataScope 与 MyBa
RFC 7 带读：Host-IMP Interface——从用户请求到硬件中断，ARPANET 主机网络栈的早期分层
前言读完 RFC 6 以后，Host 与 IMP 之间“到底应该怎么接”仍然只是一些散落的问题： 字符转换由谁完成； Host 应该向 IMP 提供哪些控制信息； IMP 应该怎样反馈状态； Link 字段到底多大； 出错以后谁负责处理。 到了 RFC 7，这些讨论第一次明显地收敛成一份软件组织设计草案。 RFC 7 的标题非常直接： Host-IMP Interface。 作者 Gérard
Spring Boot 使用 SpringDoc 构建 OpenAPI 3 接口文档
在 Spring Boot 项目中，接口文档不应该是一份需要人工同步维护的附属 Word 文档，而应该尽可能从真实的 Controller、DTO、参数约束和接口注解中生成。SpringDoc 正是 Spring Boot 生态中常用的 OpenAPI 文档生成方案。本文围绕 SpringDoc 的工作原理、Spring Boot 3/4 版本选择、Swagger UI、OpenAPI
Spring Cloud Gateway：微服务网关的路由、过滤、限流与容错实践
在微服务架构中，API Gateway 不只是一个请求转发器，而是外部流量进入内部服务体系的统一边界。Spring Cloud Gateway 将路由匹配、服务发现、负载均衡、过滤器链、鉴权、跨域、限流、超时、重试、熔断和监控等能力集中到网关层。本文从 Gateway 的核心模型和请求处理链路出发，结合 Nacos、Redis 与 Resilience4J 给出一套面向 Spring Boot 3
EasyCode 与 Velocity：从数据库表到可维护代码模板的工程化实践
EasyCode 将 IntelliJ IDEA 的数据库元数据转换为可供模板访问的表、字段、类型等对象，再通过 Velocity 模板生成 Entity、DAO、Service、Controller 等代码。真正决定代码生成质量的并不是“右键生成”本身，而是类型映射、命名规则、模板上下文、文件路径和团队代码规范。本文从 EasyCode 的工作机制出发，系统梳理 Velocity 模板语法、模板
Spring Modulith 与 Java 25 JPMS：在单体应用中构建可验证的模块化架构
当 Spring Boot 单体项目逐渐增长，真正令人头疼的通常不是“单体”本身，而是业务边界消失之后形成的无约束依赖：Service 相互调用、Repository 跨领域访问、实体被全局复用，最终任何修改都可能产生连锁影响。Spring Modulith 提供了一套围绕业务模块组织、验证、测试、事件通信和可观测性的机制，而 Java 的 JPMS 则从编译与运行时层面提供更底层的模块边界。本文
RFC 6 带读：Conversation with Bob Kahn——Host 与 IMP 的边界到底应该有多聪明
前言RFC 6 可能是最不像“标准文档”的 RFC 之一。 它没有章节，没有正式协议语法，也没有长篇背景说明。Steve Crocker 只是在开头写了一句： 他昨天和 BBN 的 Bob Kahn 聊了一次。 随后把谈话中的几个技术结论记了下来。 全文真正讨论的内容只有三类： 1231. IMP 是否应该负责字符编码转换2. HOST 与 IMP 之间的控制接口应该暴露哪些能力3. IMP
RFC 5 带读：Decode Encode Language (DEL)——1969 年的可下载前端程序与跨终端交互
前言读完 RFC 1～4，再打开 RFC 5，会突然发现画风变了。 前几篇还在讨论 Host Software、IMP、Link、网络联调和 RFC 文档制度，RFC 5 却直接拿出了一门编程语言： DEL（Decode-Encode Language，解码-编码语言）。 而且这不是一份只有几页的概念提案。RFC 5 从网络交互模型一路写到语言语法，里面有： Function、Procedure
RFC 4 带读：Network Timetable——ARPANET 上线前的系统集成与测试计划
前言前几篇 RFC 还在讨论 Host Software、Link、控制消息和文档协作规则，RFC 4 却突然换了一个非常“工程项目”的视角。 它的标题只有两个词：Network Timetable。 如果把它直译成“网络时间表”，很容易以为这只是一份项目排期。实际上，RFC 4 更像一份 ARPANET 初始四节点网络的系统集成、联调、验收和故障定位计划。 它没有定义新的报文格式，也没有给出一套
SOA 面向服务架构：参考架构、核心机制与工程实践
SOA（Service-Oriented Architecture，面向服务的体系架构）并不只是 SOAP、WSDL 或 ESB 的组合，而是一套围绕“服务”组织企业 IT 能力的方法。本文从业务驱动、松耦合和服务复用出发，系统梳理 SOA 的参考架构、适配器、服务总线、流程服务、信息服务、服务治理、安全、可靠消息与分布式事务等核心机制，并结合现代微服务、API Gateway、消息系统和可观测性