惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

D
Docker
博客园 - 【当耐特】
S
SegmentFault 最新的问题
阮一峰的网络日志
阮一峰的网络日志
大猫的无限游戏
大猫的无限游戏
WordPress大学
WordPress大学
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
The Cloudflare Blog
Apple Machine Learning Research
Apple Machine Learning Research
小众软件
小众软件
博客园 - 三生石上(FineUI控件)
Martin Fowler
Martin Fowler
云风的 BLOG
云风的 BLOG
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
F
Fortinet All Blogs
Y
Y Combinator Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
J
Java Code Geeks
Engineering at Meta
Engineering at Meta
MyScale Blog
MyScale Blog
B
Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
人人都是产品经理
人人都是产品经理

Go 编程语言

做了一个持续同步官方的 A Tour of Go 中文版,也逐渐扩展成了多语言项目 - V2EX WorkBuddy + 企业微信 有人用过吗? - V2EX 业务系统开发语言从 PHP / Python 转向 Go 如何实现数据的存储 - V2EX [2026 最新] Go 1.27 泛型方法完全解读 - V2EX Go 后台接入 SSO 后,本地用户表应该怎么退? - V2EX clbtransport - 自带负载均衡的 http.Transport 简易替代 - V2EX 基于 go+react 开发的一款可私有化部署、任务驱动的代码托管平台 iForge - V2EX 分享一个还在 RC 阶段的项目:把 C 编译成不依赖 cgo 的 Go package - V2EX [工业边缘网关] EdgeX 更新啦,增加了 MCP,可以被 AI 接管了,可以让 AI 控制物理世界啦 [工业边缘网关] EdgeX 更新啦 上线了官网 顺便更新版本 v0.10.0 有了 Agent,后台脚手架是该退场,还是变成约束层? 强兼 Claude Code:左 DeepSeek V4,右 Kimi K3 构建时自动注入版本号:从 Git tag 到 Go 可执行文件 [边缘计算] 想借助 AI 来开发 边缘网关接入 AI 解决设备通信 不知道有没有需求 [Go]工业边缘计算网关 edgex 业余时间独立开发 持续更新半年咯 求个 star eget:不用等中央仓库,直接安装 GitHub 和任意下载站的工具 gookit/gcli v3.8:新增支持共享选项、文档生成和参数重排 V2EX 我开源了一款极简的 P2P 文件传输与 VPN 工具 (Win/Mac/ Linux /Android) gookit/gcli v3.5.0 发布 - 简单易用、功能丰富的 Go 命令行应用与工具库 用 Go gRPC 信令对接 Android WebRTC:大家一般怎么划分网关和客户端边界? 在服务端用 Pion + FFmpeg + RNN 做 WebRTC 通话降噪,值得吗? 这两种 lint 报错场景, v 友们一般怎么处理 tikrok 的部分来时路 tikrok 第 7 代微服务重构: Golang 微服务 grpc 接口与服务实现隔离方案 写了个 Go 库:在 TCP 应用协议开始前做认证,也支持端口敲门 go 打包的二进制程序怎么反编译 [边缘计算开源] 工业数据采集网关 版本更新 用 golang 写了,一套面向个人音乐资产的本地优先音乐系统 做了个 Go 的 MCP Server 框架,一行代码把 Gin API 接入 AI
Tikrok v6.0 新的生产级架构,成本不变,但是部署复杂略有增加
5wunian · 2026-05-14 · via Go 编程语言

Tikrok — 第 6 代内网穿透平台

关键词: QUIC 内网穿透 | 多协议隧道 | gRPC 微服务 | Go 多模块 | Docker 全栈

Tikrok 是第 6 代内网穿透平台——基于 QUIC 协议,数据面与控制面分离架构,支持 TCP/HTTP/UDP 多协议隧道转发,具备完整的用户认证、流量计费、配额管理和监控体系。


项目概况

解决的问题

传统内网穿透工具(如 frp 、ngrok )存在协议老旧( TCP 长轮询)、单端口多协议支持弱、缺少企业级功能(计费/配额/SSO )等问题。Tikrok 从零开始,围绕 QUIC 协议构建了一套完整的数据面+控制面分离的内网穿透平台。

六代演进

  • 第 1 代 (2024Q2) — TCP 长轮询原型,单隧道单进程,无认证
  • 第 2 代 (2024Q3) — QUIC 协议替换 TCP 长轮询,单端口多协议支持( ALPN 协商 h3/h2/http/1.1/tikrok )
  • 第 3 代 (2024Q4) — SDK 模块化,提炼 tikrok-sdk( quic/protocol/tunnel 等核心包独立发布),server/client 双模块
  • 第 4 代 (2025Q1) — 控制面与数据面分离,引入 etcd 服务发现、MySQL 持久化、JWT 认证
  • 第 5 代 (2025Q2) — gRPC 微服务架构定型:auth/user/order/product/tunnel 五服务 + Gin HTTP Gateway ,Docker Compose 12 容器全栈部署
  • 第 6 代 (2025Q3-至今) — 生产级交付:Ansible 自动化部署、Jeepay 支付集成、Casdoor SSO 、Prometheus+Grafana 监控、流量计费、配额管理、36 项 E2E 自动化验证

现状

维度 状态
QUIC 隧道( TCP/HTTP/UDP ) 生产可用
微服务网关 + 5 gRPC 服务 生产可用
用户认证( JWT/API Key ) 生产可用
流量计费( 30s 上报 + 原子递增) 生产可用
产品/订单/支付( Jeepay ) 生产可用
Casdoor SSO 集成 功能完成,待灰度
管理后台 API 功能完成,前端对接中
E2E 验证( 36 项检查) 全部通过
单元测试覆盖 14 个核心包 82%-100%
Kubernetes 部署 实验阶段

架构总览

设计哲学

数据面与控制面分离 — 这是 Tikrok 区别于 frp/ngrok 的核心设计决策:

数据面 (Data Plane):      控制面 (Control Plane):
  QUIC 隧道转发              HTTP API + gRPC 微服务
  高性能、低延迟              灵活扩展、独立部署
  无状态(路由信息查询控制面)   有状态( MySQL/Redis/etcd )

数据面专注做一件事——快速转发字节流;控制面处理所有业务逻辑(认证、计费、配额)。两层之间通过 gRPC 通信。

                    ┌──────────────────────┐
                    │  tikrok client CLI    │
                    │  (QUIC 隧道连接)      │
                    └──────────┬───────────┘
                               │ QUIC
                               ▼
┌──────────────────────────────────────────────────────┐
│              tikrokd-server (QUIC 数据面)               │
│  443/UDP: QUIC | 443/TCP: TLS (h3/h2/http/1.1/tikrok)│
│  DNS/SNI 路由 → 隧道直接转发                            │
└──────┬───────────────────────────────────────┬────────┘
       │ gRPC (API Key 验证/配额检查)            │ 字节计数
       ▼                                        ▼
┌──────────────────────┐            ┌──────────────────────┐
│  tikrok-services     │            │ TrafficReporter      │
│  Gin Gateway (:8088) │◄───────────│ 每 30s 上报流量      │
│  5 × gRPC 微服务     │            └──────────────────────┘
│  etcd/MySQL/Redis    │
└──────────────────────┘

多模块工作区

为何选择 Go 多模块而非单体仓库?

  1. SDK 独立发布tikrok-sdk 是核心 QUIC 协议栈,独立版本号,可被外部项目引用
  2. 服务端/客户端独立构建tikrokd-server 部署在服务器,tikrok CLI 分发给用户,两者没有共享代码的直接依赖
  3. 微服务独立演进tikrok-services 是完整的微服务平台,使用自己的 go.mod 管理依赖

演进方向是成为平台级产品,同时方便制作成开放平台,方便引入三方协作开发。毕竟一个人可以完成的有限,微服务化后,可以分包给不同的开发者。