技术之路

前言几个月前，我想给家里有老花眼的长辈做一个打开就能用的放大镜 App：进入即放大、一键开灯、一个滑块调倍率，装到 Android 手机上。后来这个需求一路演变成了一个完整的故事——Android 版上架自托管、中英双语国际化、再复刻一个 iOS 版。 整个开发过程几乎全部由 AI 协作完成，而且不是对话式打补丁，而是一套技能（Skill）驱动的工程化流程：需求被反复拷问、词汇表与架构决策被实时记录、规范变成工单、实现严格 TDD、最后还有双轴代码评审。 这篇文章重点不是App 怎么写的，而是这套流程怎么跑起来的，以及过程中那些真正让人头疼的核心问题是怎么解决的。 需求与设计：先烤再动手（grill-with-docs）开工前，我调用了 grill-with-docs 技能。它的设计很有意思：先别急着写代码，把设计树上的每个决策都问一遍。 整个提问分了两轮： 第一轮（地基）：技术栈（Kotlin + Compose）、相机方案（CameraX）、默认放大倍数（2.0x）、放大范围（跟随设备最大倍率）、手势（滑块+捏合）、前后摄（仅后置）、闪光灯行为、是否要定格、横竖屏、倍率记忆...

前言Matt Pocock 是 TypeScript 圈的知名开发者，他把自己日常使用的 AI 编程方式沉淀成了一套技能组合：wayfinder、to-spec、to-tickets、implement、code-review。这五个技能不是零散的提示词，而是一条按顺序执行的工程化工作流。 这套流程的核心目标，是把一个模糊的想法，通过严格的工程纪律，逐步转化为可执行、高质量的代码。它解决的矛盾是：AI 的会话是一次性的，但工程不是。 核心工作流概览flowchart LR A[模糊想法] --> B[wayfinder 规划] B --> C[to-spec 规格化] C --> D[to-tickets 任务化] D --> E[implement 实现] E --> F[code-review 审查] F --> G[高质量代码] wayfinder 负责把模糊想法变成决策地图，to-spec 把决策整理成规格说明，to-tickets 把规格拆成可独立完成的工单，implement 按工单用 TDD 实现，code-revi...

Kong 是什么Kong 是一个云原生、高性能、可扩展的 API 网关，底层基于 OpenResty（Nginx + LuaJIT）构建。你可以把它理解成一个流量指挥中心，所有外部请求都先到达 Kong，再由它完成认证、限流、路由、日志收集等工作，最后转发到后端真实的微服务上。 核心定位：API 管理 + 流量控制中间件。 它不只是一个反向代理，更是一个平台： 社区版（免费）：覆盖绝大多数网关功能 企业版：额外提供可视化 GUI、高级安全、DevPortal 等商业功能 它的数据库可选 PostgreSQL 或 Cassandra，也能以 DB-less 模式（声明式配置）运行，非常适合 Kubernetes 环境。 Kong 可以实现哪些功能对 Java 开发者而言，可以把它视为 Spring Cloud Gateway + Spring Security + Resilience4j 的集大成者，但独立于语言栈。关键能力包括： 核心路由与负载均衡 路由（Route） + 服务（Service） + 上游（Upstream） 三层抽象。 支持按域名、路径、Header、H...

APISIX 是什么简单来说，Apache APISIX 是一个云原生、高性能、可动态扩展的 API 网关。 技术基座：它基于 OpenResty（Nginx + LuaJIT）构建，核心逻辑用 Lua 编写，因此天然继承了 Nginx 的高并发、低时延特性。 核心设计理念：与传统的 Nginx 网关不同，APISIX 最大的特点就是 完全动态。无论你是修改路由、更新插件、加载 SSL 证书，还是变更上游服务，都不需要重启，几毫秒内即可热生效。 配置中心：它使用 etcd 来存储所有配置。网关节点无状态，通过 watch etcd 来实时同步配置，这使得水平扩展变得非常简单。 插件化架构：几乎所有的功能，比如限流、认证、监控，都被抽象为插件。你可以按需组合，作用在全局、某个服务或某条路由上。 与 Java 生态的联系：你可以在 Spring Cloud / Dubbo 微服务体系的前面放上 APISIX，让它统一接管所有南北向流量（外部到内部服务）。它支持代理 Dubbo 协议，也可以通过插件运行器支持用 Java 编写自定义插件。 APISIX 可以实现什么功能对...

Spring Cloud Gateway 是什么Spring Cloud Gateway 是 Spring 官方基于 Spring WebFlux（底层默认使用 Netty）构建的 API 网关。它在 2.x 时代替代了不再维护的 Zuul 1.x，成为 Spring Cloud 微服务体系中的标准网关方案。它是一个非阻塞、响应式的网关，完全异步，天然适配高并发场景。 核心特点：它不是基于 Servlet 容器（如 Tomcat），而是运行在 Netty 之上，因此它不阻塞调用线程，能更好地利用系统资源，适合作为微服务入口承担海量请求。 Gateway 的核心模型是： Route（路由）：网关的基本构建块，包含 ID、目标 URI、断言集合、过滤器集合。 Predicate（断言）：匹配 HTTP 请求的条件，比如路径、Header、参数等。 Filter（过滤器）：对请求或响应进行修改、加工，分为 GatewayFilter（局部）和 GlobalFilter（全局）。 可以实现哪些功能Spring Cloud Gateway 不只是一个转发请求的工具，它提供了丰富的内置...

OpenResty 的本质：不只是 Nginx + LuaOpenResty ≠ Nginx + Lua 解释器，而是对 Nginx 核心的 全异步化、协程化改造 与 LuaJIT 深度绑定 的平台。 核心组成：Nginx C 内核 + LuaJIT（即时编译的 Lua 虚拟机） + 大量精良的 lua-resty-* 库。它把 Nginx 请求处理的 11 个阶段（如 rewrite、access、content、log）全部通过 *_by_lua 指令暴露给 Lua 脚本。 编程模型：在 Lua 中写 同步非阻塞 代码。底层借助 Nginx 的事件驱动和 Lua 协程，网络 I/O、Sleep 等操作会自动挂起当前协程，让出 CPU 给其他请求，等到事件就绪再恢复。你写的是直观的顺序逻辑，跑的是高并发异步。 与 Java 的类比：如果 Netty 是一个可以让你用 Java 构建非阻塞网络应用的框架，那 OpenResty 就是把这种能力直接集成进了 反向代理服务器，并用更为轻量的 Lua 来编排流量。Java 线程通常占用 1 MB 内存，而一个 Lua 协程仅...

Nginx 是什么一句话定义： Nginx 是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。 它的核心特点是事件驱动、异步非阻塞的架构。这和 Java 中传统的 Servlet 容器（如 Tomcat）每个请求对应一个线程的模型截然不同。Nginx 用极少的 worker 进程（通常等于 CPU 核心数），通过 epoll 等高效的 I/O 多路复用机制，轻松处理数万乃至百万级的并发连接，同时保持极低的 CPU 和内存消耗。 在分布式系统中，它就是南北向流量的总入口，是所有外部请求抵达你后台服务集群前必须经过的那扇大门。 着重介绍：Nginx 可以做什么作为流量入口，Nginx 的能力远远超出把请求转发到后台这个范畴，它是一个功能强大的流量治理平台。 反向代理与负载均衡 透明转发：客户端不知道后端真实服务器，Nginx 统一收口。 负载均衡算法：支持轮询（Round Robin）、权重轮询、IP 哈希（ip_hash）、最少连接数（least_conn）、URL 哈希（hash $request_u...

这套方案对标 Spring Cloud Alibaba + Kubernetes 生态，组件全部是新版（2024~2026 年主流）且生产验证过的。 流量入口与网关 组件 选型 作用 反向代理 / 负载均衡 Nginx / OpenResty 第一层接入，SSL 终结，流量分发 API 网关 Spring Cloud Gateway (Java 体系首选，响应式) 动态路由、身份认证、限流、跨域、日志 备用网关 APISIX / Kong 性能极高，适合非 Java 中心化网关 微服务核心框架 组件 选型 作用 注册中心 Nacos 2.x 服务发现、健康检查、元数据管理 配置中心 Nacos 或 Apollo 配置热更新、灰度推送、审计 RPC 框架 Dubbo 3 (Triple/gRPC 协议) 高性能 Java RPC，跨语言支持 HTTP 调用 OpenFeign + Spring Cloud LoadBalancer 声明式 HTTP 客户端，微服务间调用更轻量 应用基座 Sp...

服务熔断、服务限流和服务降级是构建高可用、高弹性系统的三大基石，它们的目标一致（保证系统核心功能可用），但着眼点和实现方式不同。 核心概念对比 特性 服务熔断 (Circuit Breaker) 服务限流 (Rate Limiting / Throttling) 服务降级 (Service Degradation) 核心目标 快速失败，防止连锁故障。故障隔离。 控制流量，防止系统被突发流量冲垮。过载保护。 弃车保帅，牺牲非核心功能，保证核心功能可用。体验保全。 触发条件 依赖的下游服务失败率/超时率达到阈值。 流量/并发数达到预设的阈值（如QPS、线程数）。 1. 系统资源普遍不足（如CPU、线程池满）。2. 熔断或限流发生后。 作用对象 主要是对下游依赖服务的调用进行控制。 主要是对进入本服务的请求流量进行控制。 主要是对本服务提供的功能进行调整。 实现层面 通常集成在服务调用框架中（如Feign、Dubbo）。 通常位于网关/入口层或服务内部（如Sentinel、Hystrix）。 业务逻辑层，需要根据业务预先设...

核心目标与原则在开始之前，我们必须明确高并发系统的核心目标： 高性能：低延迟、高吞吐量。 高可用性：系统能够持续提供服务，即使部分组件失败（SLA 可达 99.99%）。 可扩展性：能够通过增加资源来平滑地应对流量增长。 可维护性：系统易于理解、修改和运维。 遵循的原则包括：解耦、冗余、异步、分区、自动化。 系统设计系统设计关注宏观架构，如何将各个部件组合成一个有机整体。 整体架构：水平扩展与分层摒弃传统的单体垂直扩展（Scale-up），采用分布式的水平扩展（Scale-out）架构。典型的现代高并发架构如下所示： 123用户 -> [CDN] -> [负载均衡器] -> [API 网关] -> [微服务集群] -> [数据层] | | | | | [静态资源] [流量分发] [鉴权/限流] [服务发现] [缓存/DB/消息队列] 各层核心设计要点： 客户端与 CDN： CDN：将静态资源（图片、CSS...