Apache APISIX 从入门到原理：架构、路由、插件与生产实践

Apache APISIX 是建立在 NGINX、OpenResty 与 LuaJIT 之上的动态 API Gateway。它并不只是把请求从入口转发到后端，而是把路由、认证、限流、负载均衡、服务发现、灰度发布、缓存、可观测性等横切能力集中到流量入口统一治理。 本文从可运行的安装与 Admin API 实践出发，进一步拆解 APISIX 的数据面、控制面、etcd 动态配置、RadixTree 路
DevOps
#Kubernetes #Nginx #Apache APISIX #API Gateway #OpenResty #etcd #Microservices

APISIX + Nacos + Dubbo 整合实践：以订单服务为例

在 Dubbo 微服务体系中，外部客户端通常使用 HTTP/HTTPS，而内部服务使用 Dubbo RPC，Nacos 负责注册与服务发现。传统方案往往需要额外部署 HTTP Adapter，将 HTTP 请求转换为 Dubbo 调用。本文以订单查询与下单业务为例，整理 APISIX、Nacos 与 Dubbo 的整合方式，重点说明服务发现、HTTP→Dubbo 协议转换、Dubbo 3
Architecture
#Service Discovery #Dubbo #Nacos #API Gateway #Microservices #APISIX

Linux systemd 从入门到实战：Unit、systemctl、Service 与日志排障

前言在现代 Linux 发行版中，systemd 几乎已经成为绕不开的基础组件。我们平时执行的： 1234systemctl start nginxsystemctl enable nginxsystemctl status nginxjournalctl -u nginx 背后都属于 systemd 的服务管理体系。 如果只把 systemd 理解成“用来启动服务的工具”，其实低估了它。sys
Linux
#Linux #运维 #systemd #systemctl #journalctl #服务管理

使用 VNC 远程控制 Linux Desktop 服务器：TigerVNC 安装、配置与安全访问

前言日常管理 Linux 服务器时，大多数操作通过 SSH 就足够了，但有些场景仍然离不开图形桌面，例如： 运行只能通过 GUI 操作的软件； 使用浏览器、IDE、仿真工具或桌面应用； 远程维护一台安装了 GNOME、XFCE 等桌面环境的 Linux 工作站； 管理实验室、开发环境或内网 Desktop Server； 需要从 Windows、macOS 或另一台 Linux 机器直接控制 L
Linux > 运维
#Linux #Rocky Linux #RHEL #VNC #TigerVNC #GNOME #Remote Desktop

VMware vCenter Server 8.0 接入 Windows Server 2022 AD 域：LDAPS 身份源与权限配置

本文专门介绍如何将 VMware vCenter Server 8.0 接入 Windows Server 2022 Active Directory，使用 AD 账号统一登录 vSphere Client，并通过 AD 安全组完成 vCenter 权限授权。 本文采用的方案是： 123456789Windows Server 2022 AD DS + DNS ↓LDAPS / TC
服务器与虚拟化 > VMware
#VMware #vSphere 8 #vCenter #Windows Server 2022 #Active Directory #LDAPS #SSO #LDAP #RBAC

VMware vCenter Server Appliance 8.0 安装部署教程：从 ESXi 到 VCSA

本文专门讲 VMware vCenter Server Appliance 8.0（VCSA 8.0）的安装与基础配置。 内容从部署前的 DNS、FQDN、时间和资源规划开始，完整覆盖 VCSA 两阶段安装、首次登录、数据中心与集群创建、ESXi 主机纳管、许可证、更新、备份和常见安装故障。 如果还需要让 vCenter 使用 Windows Server 2022 Active Director
服务器与虚拟化 > VMware
#VMware #vSphere 8 #vCenter #VCSA #ESXi #SSO #VAMI

DeepSeek-OCR：从“识字”到“理解文档”，重新认识 OCR 2.0 与上下文光学压缩

传统 OCR 解决的是“图片里写了什么”，而现代文档智能系统真正需要解决的问题已经变成了：这段文字在文档中扮演什么角色，它和表格、公式、图片、图表之间是什么关系，以及如何把整份 PDF 还原成机器可以继续理解、检索和推理的结构化知识。 DeepSeek-OCR 可以放在这个变化中理解。它不是单纯把字符识别得更准，而是把 OCR、版面理解、视觉语言建模和结构化生成放到统一的多模态框架中，并进一步提出
AI > 多模态 > OCR
#Markdown #DeepSeek-OCR #OCR 2.0 #VLM #DeepEncoder #Contexts Optical Compression #多模态 RAG #vLLM #Transformers #PDF

RFC 3 带读：Documentation Conventions——互联网最早的协作规则，为什么反而鼓励“不成熟”

前言RFC 1 和 RFC 2 讨论的是一个很具体的技术问题：ARPANET 的 Host 软件应该怎样工作。 到了 RFC 3，Steve Crocker 突然没有继续设计 Link、Message、Host-to-Host checksum 或远程终端，而是停下来写了一篇只有很短篇幅的文档： Documentation Conventions（文档约定）。 如果只看标题，它似乎不像一篇“技术
RFC > 网络协议
#RFC #ARPANET #Network Working Group #Documentation Conventions #Internet History #IETF

Spring 工程实践中的隐式规则：数据访问、事务、HTTP 调用与测试的常见陷阱

Spring 工程实践中的隐式规则：数据访问、事务、HTTP 调用与测试的常见陷阱Spring 最大的优势，是把大量底层细节包装成统一、易用的抽象；Spring 最容易让人踩坑的地方，也恰恰来自这些抽象。 很多问题看起来互不相关：Redis 明明写进去了却读不到、事务抛了异常却没有回滚、内层事务明明被 try-catch 了却把外层事务一起回滚、切换数据源的注解看起来执行了但 SQL 仍然落在原库
Java > Spring
#Spring Boot #Spring #Redis #AOP #Spring Data #Spring Transaction #RestTemplate #Spring Test #Cassandra

Spring MVC 请求处理全链路：从 URL、Header、Body 到 Validation、Filter、Security 与异常处理

从一次 HTTP 请求在 Servlet 容器中的完整生命周期出发，系统梳理 Spring MVC 的 URL 匹配、参数解析、Header、Body 编解码、Validation、Filter、Spring Security 与异常处理机制，并结合源码调用链解释常见错误、排查方法和现代 Spring 的版本演进。
Java > Spring
#Spring Boot #Java #Validation #Spring Security #Spring MVC #HTTP #Exception #Servlet #Filter

从 Bean 到 Web 请求：Spring 核心运行机制、AOP、事件与常见陷阱

Spring 好用的地方，恰恰也是它最容易让人掉坑的地方：大量重复、繁琐的对象创建、依赖装配、生命周期管理、代理增强和 Web 请求分发工作都被框架接管了。开发者只需要写几个注解，程序往往就能运行；但一旦包结构、Bean 数量、代理方式、初始化时机或监听体系发生变化，那些平时看不见的约定就会突然暴露出来。 理解 Spring，不能只停留在“这个注解怎么用”。更有效的方式，是建立一条完整的运行链路：
Java > Spring
#Spring Boot #Spring #Spring MVC #AOP #IoC #DI #Bean #ApplicationEvent #DispatcherServlet

安全编码体系：从信任边界、最小权限到纵深防御

安全编码体系：从信任边界、最小权限到纵深防御软件安全很容易被误解成“安全团队的工作”：防火墙、WAF、杀毒软件、漏洞扫描器、入侵检测、零信任网关都部署好了，应用似乎就安全了。 真正进入代码层以后，会发现事情恰好相反。很多严重安全事故的起点并不是一段“看起来像黑客代码”的实现，而是一次普通的字符串处理、一次整数加法、一次数组遍历、一次异常打印、一次对象序列化，甚至只是调用了一个自己没有真正理解的 A
软件工程
#Java #安全编码 #Secure Coding #Software Security #代码质量

Java 经济代码：从线程同步、内存管理到异步与可伸缩性的性能工程实践

Java 经济代码：从线程同步、内存管理到异步与可伸缩性的性能工程实践所谓“经济的代码”，并不是把每一行代码都压榨到极致，也不是看到 synchronized、对象创建或集合就条件反射式地“优化”。它讨论的是一个更完整的问题： 在满足真实需求的前提下，让软件用尽可能少的代码复杂度、线程协调、内存、CPU、I/O、状态和维护成本，完成尽可能多的有效工作，并为未来的规模增长留下空间。 如
软件工程 > 性能工程
#Java #并发编程 #性能优化 #代码设计 #内存管理 #异步编程 #可伸缩性 #JMH

高质量软件工程实践：从接口契约、文档与代码规范，到性能工程和简单设计

高质量软件工程实践：从接口契约、文档与代码规范，到性能工程和简单设计写出“能运行”的代码并不难，真正困难的是让代码在一个长期演化的软件系统中依然能够被别人理解、被安全修改、被可靠复用，并且在真实负载下以合理的成本运行。 从这个角度看，接口规范、用户指南、编码规范、Code Review、回归测试、性能工程、需求控制和接口设计，并不是彼此割裂的主题。它们实际上围绕着同一个目标展开：降低软件生命周期中
软件工程 > 性能工程
#Java #技术文档 #Code Review #API设计 #代码规范 #性能工程 #软件设计

RFC 2 带读：Host Software——从 RFC 1 的草图走向可实现的主机协议

前言RFC 1 刚刚提出“Host Software 应该怎么做”两天左右，SRI 的 Bill Duvall 就给出了 RFC 2。 两篇文档的标题都被 RFC Editor 收录为 Host software，讨论的也是同一批问题，但风格明显不同。 RFC 1 更像一张设计草图：它解释为什么需要 Host-to-Host Software，提出把 Link 0 留给控制消息，用其他 Link
RFC > 网络协议
#RFC #ARPANET #Host Software #IMP #NCP #Host-Host Protocol #SRI

Linux 性能优化工程方法论：从全局观到诊断闭环

Linux 性能优化工程方法论：从全局观到诊断闭环性能问题最麻烦的地方，通常不是“不会用某个命令”，而是不知道应该先看什么、为什么看、看到异常之后如何继续向下追。 线上出现延迟升高、吞吐下降、平均负载异常、CPU 打满、磁盘 I/O 抖动或者网络请求变慢时，如果排查方式仍然是“看一眼 top，猜一下最近改了什么，不行就搜索报错”，那么偶尔也能碰巧解决问题，但很难形成稳定、可复用的工程能力
Linux
#Linux #性能优化 #perf #性能分析 #Wireshark #系统原理 #网络

Linux 性能工程实战：从监控、定位、动态追踪到容器与网络调优

Linux 性能工程实战：从监控、定位、动态追踪到容器与网络调优Linux 性能问题真正困难的地方，通常不是“不知道某个命令怎么用”，而是不知道应该从哪里开始、下一步看什么、看到异常后如何把指标与系统机制对应起来。 CPU、内存、磁盘 I/O、网络只是性能问题的表象分类。进入真实系统后，一个看起来像“网络慢”的问题，可能来自连接跟踪表耗尽；一个“容器启动慢”的问题，可能并不是 Docke
Linux > Performance
#Linux #Docker #性能优化 #perf #性能分析 #eBPF #Prometheus #可观测性 #FlameGraph #网络调优