Linux
最近我在折腾一个很实际的问题： 我有一台内网机器，上面跑着很多服务，每个服务都有自己的端口。现在我想把其中某些服务暴露到公网，让外部可以访问。 这个需求很常见。 比如我家里或者局域网里有一台 Ubuntu 机器，上面跑着： MCP 服务：8120 API 服务：8122 测试后台：8080 某个 Go 服务：9000 某个 Python 服务：7860 这些服务本身都在内网里，外部是访问不到的。 如果机器没有公网 IP，或者路由器不方便做端口映射，那传统方式就很麻烦。于是我用了 frp。 一开始我对 frp 的理解还比较简单： 它就是一个内网穿透工具，可以把内网端口暴露到公网服务器上。 但真正跑通之后，我对它的理解一步一步升级了。 一、frp 的核心逻辑：公网服务器帮内网机器“代收连接” frp 的结构其实很清晰： 外部用户
部署运维
记录一次从零开始部署 frp 的完整过程，包括原理理解、架构设计、踩坑排查，以及最终跑通的全流程。 背景 我有一台内网服务器，上面跑着一些本地服务（监听在 8900 端口）。同时我有一台云服务器，有公网 IP，上面已经用 Caddy 跑了一堆服务。 需求很简单：让公网能访问到我内网服务器上的服务。 方案：frp（Fast Reverse Proxy）—— 一个专注于内网穿透的反向代理工具。 frp 是什么 frp 由两个组件构成： * frps（server）：部署在有公网 IP 的服务器上 * frpc（client）：部署在内网机器上 它的工作原理： 1. frps 在公网服务器上启动，监听一个"控制端口"（默认 7000），等待客户端连接
MCP
最近我一直在思考一个问题：传统 SaaS 到底应该怎么转向 AI？ 一开始很容易想到的方向是：给原来的系统加一个 AI 助手。 比如在页面右下角放一个聊天框，让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值，但我现在越来越觉得，这只是比较表层的一种转型。 真正的变化，可能不是“在 SaaS 里面加 AI”，而是 SaaS 本身的能力形态发生变化。 过去的 SaaS，核心是给人使用。 人登录系统，看页面、点按钮、筛选数据、导出报表、判断问题，然后再去做决策。数据库是给 Web 页面供数的，后端 API 是给前端页面服务的，整个产品的中心是“人如何操作软件”。 但 AI 时代，尤其是 Agent 逐渐发展之后，
Python
最近在重新设计一个任务系统时，我顺便把自己对 Python，尤其是 CPython 应用场景的理解重新梳理了一遍。 这次讨论的背景是一个典型的异步任务服务： 上游提交任务 API 立即返回 task_id 后台 worker 慢慢执行 用户通过 task_id 查询任务状态 任务主要是 LLM 调用、图片下载、外部 HTTP 请求这类 I/O 型工作。 一开始关注的是队列、Redis、PostgreSQL、worker 并发控制这些问题。但聊到后面，其实更核心的问题变成了： Python 到底应该放在什么位置？ 哪些并发适合 Python？ 哪些并发不要硬塞给 Python？ FastAPI、协程、线程、数据库之间应该怎么分工？ 这篇文章就是这次思考的整理。 一、我不想抛弃 Python，
Go
最近我在写 worker 任务系统的时候，重新理解了一遍 Python 和 Go 的并发差异。 以前写 Python，多 worker 经常要考虑： 多进程怎么管理？ 日志会不会串？ 一个 worker 崩了怎么办？ 怎么吃满多核心？ 后来换成 Go，发现一个进程里开多个 goroutine worker 就很自然： go worker(1) go worker(2) go worker(3) go worker(4) 日志也好管，状态也好管，而且单进程还能利用多个 CPU 核心。 一开始很容易误会成： Python 不行，Go 行 但更准确的理解应该是： Python 和
Go
最近我在做 worker 任务系统的时候，突然意识到一个很关键的问题： 以前写 Python，多 worker 的时候经常要小心日志串、文件切割乱、时间不好管理。 但是换成 Go 以后，一个进程里开多个 goroutine worker，反而可以比较自然地写到同一个日志文件里。 一开始我以为这是“Python 和 Go 写日志能力不一样”，后来想明白了，核心不是日志本身，而是： Python 常见 worker 模型：多进程 Go 常见 worker 模型：单进程 + 多 goroutine 这背后其实是两个语言在并发模型上的巨大差异。 一、进程、线程、goroutine 先分清楚 先把几个概念捋一下。 进程：操作系统分配资源的单位 线程：CPU 调度执行的基本单位
Go
在讨论 PostgreSQL queue 方案之后，我又回头看了一下之前自己设想过的 Go + Redis 任务架构。 最早我脑子里的方案大概是： POST 创建任务 Redis 存状态 Go goroutine 直接处理 进程内 channel 控制并发 这个方案很直观，也很符合 Go 的写法。 用户请求进来后，API 生成一个 task_id，把任务状态写进 Redis，然后把任务塞进 Go 的 channel，由后台 goroutine 消费执行。并发控制就靠一个固定大小的 channel 或 worker pool，比如最多 20 个 goroutine 同时执行任务。 这个设计在单进程里确实很舒服。 但当我开始思考多进程、多容器、
架构
"What can't Postgres do?" —— 这两年技术圈最流行的一句话 "Use one database, but use it really well." —— Hacker News 上一条 2k+ 赞的评论 写在最前面:一张让人窒息的架构图 先看一张图,看看你眼熟不: [客户端] │ ▼ [API Gateway] ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ [业务服务] [认证服务] [搜索服务] │ │ │ ├──→ MySQL ├──→ Redis ├──→ Elast
架构
最近我对一个 LLM 任务服务做了一次比较完整的架构升级。 这个服务本身并不复杂：上游提交任务，我返回一个 task_id，后续上游再通过 task_id 查询任务状态和结果。任务的执行内容主要是调用 LLM 或相关多模态接口，单个任务耗时通常在几十秒以内。 最开始的实现是比较常见的组合： FastAPI + Redis + Docker API 接到请求后生成任务 ID，把状态写入 Redis，然后由后台逻辑继续执行任务。这个方案在早期足够轻量，开发速度也很快。 但随着需求继续演进，我开始更明确地追求几个能力： 1. 上游可以瞬间提交大量任务 2. API 必须快速返回 task_id 3. 真正执行的任务数量必须全局可控 4. 任务状态要可查询、可恢复、可追踪 5. worker 崩溃后任务不能永久卡死 6. 未来希望减少组件数量，尽量 all
MCP
理解 MCP、JSON-RPC、Streamable HTTP 的过程中，有一个很自然的联想： 这不就是固定一个 POST 接口，然后传入不同 JSON，根据请求体里的字段返回不同响应吗？ 这个直觉是对的。 尤其是当 MCP 走 Streamable HTTP 的时候，表面上看确实很像： POST /mcp 然后请求体里传： { "jsonrpc": "2.0", "method": "tools/call", "params": { "name": "search", "arguments"
MCP
做 MCP 相关项目时，经常会遇到几个词： MCP JSON-RPC Transport stdio SSE Streamable HTTP 这些词经常一起出现，如果不把层次拆开，很容易混在一起。 这篇文章尝试从工程开发的角度，把它们之间的关系梳理清楚。重点不是翻译标准文档，而是建立一套比较稳定的理解模型。 一、先分清三层：MCP、JSON-RPC、Transport 可以先记住这句话： MCP 负责：Agent 能调用什么能力 JSON-RPC 负责：调用消息长什么样 Transport 负责：消息怎么传过去 也就是： MCP = 协议语义层 JSON-RPC = 消息格式层 Transport = 传输层 更直观一点： MCP： 我要调用工具、读取资源、获取 prompt JSON-RPC： method 是什么，
AI
最近把一套 Embedding 服务完整落地了一遍：4 张显卡分别启动 vLLM 实例，用 Nginx 做统一入口和故障切换，再在上层挂一个 FastAPI 网关，把原始向量统一裁剪成 256 维并归一化，最终形成一套比较完整、可直接对外提供服务的 Embedding 架构。 这篇文章把整个过程完整整理一下，包含环境准备、离线模型部署、多卡启动、Nginx 配置、systemd 开机自启，以及业务网关设计。 整套架构的目标很明确： * 提供标准 HTTP Embeddings API * 支持四卡并行 * 支持统一入口与负载均衡 * 单实例故障时自动 failover * 支持开机自启 * 保留日志，便于运维与统计 一、整体架构 先看整体结构： Client │ ▼ FastAPI Gateway（8681） ← 推荐对外入口 │ ▼ Nginx（
陕公网安备61011302002223号