tikrok.cc 开始进行实现分账功能实现，以下是一些规则，不知道大家对此以为如何 👨💻 开发者权益 你不是"内容提供方"，你是"生产资料的共同所有者"。 定价自主权 自由决定一次性购买、订阅制、打赏或企业授权，支持多币种结算 透明分成 每一笔收入实时可见，平台抽成比例公开，结算周期明确 精准曝光 依靠社区投票、兴趣标签与行为数据，让长尾应用也有被看见的机会 需求直达 用户可付费投票支持新功能，众筹达标即启动开发 数据反哺 获得匿名化的用户行为报告，了解产品使用路径与优化方向 ✊ 让劳动价值回归创造者 在传统平台模式中，开发者投入劳动创造应用，平台掌控分发渠道与用户关系，剩余价值被渠道方大量抽取。 在我们的实践中，开发者与用户共同构成社区主体，平台作为基础设施由社区共治共享，收益分配向创造者倾斜。 ✓ 生产资料公有：核心规则开源，治理权社区共享 → 避免渠道垄断 ✓ 按劳分配为主：收益按开发贡献、社区参与、用户认可多维计算 ✓ 人的自由发展：开发者专注创造，无需博弈算法、讨好审核 "哲学家们只是用不同方式解释世界，而问题在于改变世界。" — 今天，我们用实践回应这句话。 💰 比订阅更人性化：复合定价 传统的软件订阅模式让用户"持续付费却永不拥有"。我们提供一种更公平的选择： 核心规则 订阅期内使用的版本永久可用 订单过期后，你在订阅期间获得的版本无需再付费，可持续永久使用，不受任何限制。 版本升级需要重新订阅 如果应用发布了新的大版本，你希望升级体验新功能，则需要重新订阅。不升级不影响已拥有版本的正常使用。 自由选择，无需纠结 你可以跳过中间版本，只在需要的版本时重新订阅。不再是"不续费就不能用"的被动模式。 流量型应用续费：只收流量，不收版本费 对于内网穿透、API 网关等流量型应用，首次订阅包含软件版本维护费用。 再次订阅时，如果之前的订阅记录良好，后续订阅只收取流量费用，不再重复包含软件版本维护费。 长期用户的边际成本持续降低——平台与你建立的是信任关系，而非重复收费。 为什么选择 vfox 进行版本管理？ 这正是我们引入 vfox 作为应用管理底座的原因。vfox 的插件化架构天然支持： ▸ 精确版本锁定 ：每个大版本独立安装、独立激活，买断版本不会被覆盖 ▸ 无缝版本切换 ：一条命令在买断版本和最新版本之间自由切换 ▸ 团队环境一致 ：通过 toolchain.toml 实现项目级版本锁定，消除"在我机器上能跑" ▸ 离线可用 ：买断版本完全本地化，无需持续联网验证
Tikrok Services — 第八代微服务平台 新网站 tikrok.cc 陆续更新中 基于 gRPC + Gin 的微服务平台，采用 Go 多模块工作区 (go.work) 架构， 通过 gen/ 接口隔离层 实现 RPC 客户端与服务端实现解耦，共 15 个独立模块。 第八代更新了什么 与第七代相比，第八代主要围绕 「内容交付」 补齐了三个关键拼图： 1. 独立图片处理微服务 从零搭建了 Image Service （ HTTP :9006 + gRPC :9056 ），基于 Go 原生 imaging 库实现生产级图片实时处理。支持裁剪、缩放、格式转换，本地 LRU 磁盘缓存（ 7 天 TTL ），信号量限流并发。Nginx 侧做了 proxy_cache 直连路由，图片直接走 nginx 缓存层，不经过 Gateway 。Markdown 内容中的 ref:media_id 引用自动解析为图片 URL——论坛帖子和教程终于能正常显示配图了。 2. TUS 协议大文件分段上传 新增独立 TUS Upload Service （ HTTP :9007 ），支持断点续传、并发分片。前端上传大文件时中断了可以从断点继续，不用重新传。上传完成自动写入媒体资源库并触发 S3 归档。软件版本发布也改为 TUS 上传驱动——上传完成即发布。 3. QUIC 网关合并进 tunnel 服务 之前 QUIC 数据平面是独立的 tikrokd-server ，维护两套部署太痛苦了。第八代将 QUIC 网关完整合并进 tunnel 服务，UDP listener 、HTTP/3 、TLS ALPN 协商（ h3/h2/http1.1/tikrok ）、流量统计、证书管理（ Let's Encrypt 自动签发）、速率限制全部整合在一个进程中。部署少一个组件，监控少一套指标。 配套还补了开发者注册审核流程、管理员升级接口、20+ 个 Swagger API 文档更新、4 个数据库迁移。 第八代的核心思路： 内容上传（ TUS ）→ 内容存储（ S3 + 媒体资源管理）→ 内容消费（ Image Service 实时处理 + Nginx 缓存加速） 这条链路终于完整了。
Changelog [v1.0.10] - 2026-05-19 文档更新 根 README 全面升级至第 7 代架构文档：gen/ 隔离层、sqlc 数据层契约、DAO 测试体系 tikrok-services README 全面重写：数据访问层架构、事务模式、测试分层、错误处理 [v1.0.9] - 2026-05-18 sqlc 数据层重构（第 7 代核心） sqlc.yaml 配置优化： emit_interface: true 、 query_parameter_limit: 3 、 emit_pointers_for_null_types: true 41 处 SELECT * 全部替换为显式列名 DAO 构造器从 *db.Queries 变更为 db.Querier 接口，实现 Mock 可测试 消除 200+ 处 sql.NullX 手动转换代码 20 个 DAO 实现 WithTx(*sql.Tx) DAO 事务抽象 测试基础设施 5 个服务生成 MockQuerier （ gomock + mockgen ） 63 个 DAO 单元测试：auth(26)、order(19)、tunnel(19) 创建 pkg/testutil/sqlctest 包：轻量 Docker MySQL 测试助手 2 个集成测试： HandlePaymentCallback 事务原子性验证 9 个 Bash API 测试脚本覆盖全 API 面 错误处理 所有 GetByID / GetByEmail 将 sql.ErrNoRows 封装为 BizError （ ErrNotFound ） 逻辑层不再处理原始 sql.ErrNoRows [v1.0.8] - 2026-05-17 gen/ 接口隔离层 创建 gen/ 目录：5 个纯 RPC 接口模块（ auth/user/order/product/tunnel ） 每个 gen 模块仅 15 行 go.mod 、~2.7K go.sum ，不含业务代码 修改 proto go_package 指向 gen/ 模块路径 更新所有服务导入路径从 app/*/kitex_gen 指向 gen/* Gateway 消费方只依赖 gen/* ，不接触 app/* gen/ 模块可安全对外发布（不泄露业务实现） Docker 部署优化 切换为预编译二进制多阶段构建 版本管理自动化（ VERSION 文件 + build-images.sh ） Docker Compose 版本自增 + 旧镜像清理 [v1.0.7] - 2026-05-16 多模块工作区重构 7 个子模块独立 go.mod / go.sum ，由 go.work 统一管理 消除内部 replace 依赖，模块可独立构建 BizError 实现 GRPCStatus() 方法，支持 gRPC 错误码透明传输 修复所有记录创建时缺失 CreatedAt 时间戳的问题 测试脚本错误码断言统一修复 [v1.0.6] - 2026-05-15 GORM → sqlc+Goose 迁移 移除 GORM ，替换为 sqlc 代码生成框架 + Goose 迁移工具 创建 22 个数据库迁移文件（ 00001-00022 ） sqlc 生成类型安全的数据访问代码（ Queries 结构体） 降低默认免费配额限制 提交全部 sqlc 生成代码及查询文件 Code Review 修复 Uber Go 风格指南修复：goroutine 生命周期、全局变量、切片容量 安全修复：内部 API 认证、IDOR 、资源泄漏、CORS 泛型工具函数 + 100 Go Mistakes 修复 连接泄漏、并发安全、Context 传播、Etcd 锁重构 Jeepay 子模块引用更新（连接泄漏修复） 订单数据流修复、静默错误处理、种子数据补充 [v1.0.5] - 2026-05-14 生产部署安全加固 Vault 加密敏感配置 微服务角色分离 MySQL 自动备份 Ansible 集成 tikrok-services 微服务部署 流量计费链路完善 HandleTrafficReport / ReportTraffic / Heartbeat 持久化 内部 API 和流量上报路由注册 ServiceConnector 统一管理 gRPC 连接 Gateway 精简重构 删除 SQLite 存储层，容器化部署 删除 payment/sso/sse 子系统（迁移至 tikrok-services ） 删除业务逻辑 handler 和中间件（迁移至 tikrok-services ） 重写 gRPC 客户端，使用 HTTP gateway 替代直接 gRPC 调用 [v1.0.4] - 2026-05-13 安全与稳定性 修复管理员端点 403 和列表返回 null 的问题 修复 API Key 认证和令牌失效（ Logout 递增 TokenVersion ） 修复 MySQL 保留关键字 key 导致查询失败 修复 API Key 创建时零日期 MySQL 拒绝 添加 Gin 中间件 X-API-Key 认证 更新 Swagger 文档补充缺失路由和 definitions 后端全部缺失的 gRPC RPC 方法实现 [v1.0.3] - 2026-05-12 微服务功能完善 HTTP Gateway 从 Hertz 迁移到 Gin 框架 9 个 Bash API 测试脚本（认证、密码、API Key 、配额、隧道、管理后台） etcd 服务发现修复：Docker 环境地址注册 Swagger 文档和端到端测试基础设施 Casdoor SSO 集成（ OAuth/OIDC 回调、用户同步） ServiceConnector 统一 gRPC 连接管理器 [v1.0.2] - 2026-05-11 平台基础设施 微服务集群 Docker 容器部署（ 12 容器 5 层依赖） 商品与授权系统设计 Goose 数据库迁移任务和部署步骤 etcd 服务实现自动重连与性能优化 修复 CRITICAL 和 WARNING 级别安全问题及代码缺陷 [v1.0.1] - 2026-05-10 项目全面清理与 gateway → tikrokd-server 重命名 SDK 重构：移除所有非共享网络库包 完成 SDK 模块化，提炼 tikrok-sdk 核心包 [v1.0.0] - 2026-05-09 初始架构定型 第 6 代 gRPC + Gin 微服务架构 SDK 模块化（ quic/protocol/tunnel/mux/discovery/pool/metrics ） QUIC 数据面与服务端（ tikrokd-server ） 客户端 CLI （ tikrok ） etcd 服务注册与发现 MySQL + Redis 持久化 JWT + API Key 认证 Prometheus + Grafana 监控 Ansible 自动化部署 36 项 E2E 自动化验证 Jeepay 支付、Casdoor SSO 集成
目前，tkrok 第 7 代，实现代码行业达到了 20+ 万行，即将达到个人维护的边界。为方便后续个人远程开发者可以方便地接入项目维护工作，特此将第 6 代实现重构升级。分享给社区，为 golang 微服务兴旺，肋力。也方便后续开发者接手了解生产级的代码实现，为自学的开发者指南。 接口契约优先 · 实现细节隐藏 · 协作零泄露 🎯 核心目标拆解 ✅ 服务提供方：只暴露 IDL + 生成的 Client/Handler 接口，隐藏业务实现 ✅ 服务消费方：仅依赖 RPC 客户端代码，无需拉取服务端源码 ✅ 协作开发：通过契约版本协商变更，避免「改接口改到崩溃」 ✅ 安全管控：私有仓库 + 权限隔离 + 依赖审计，防止源码泄露 💡 本质： 「接口定义仓库」与「业务实现仓库」物理分离 + 自动化代码生成 🏗️ 整体架构设计（参考字节/腾讯实践） 📦 公司 Git 组织 ├── 🔓 idl-registry/ # [公开] 接口定义仓库（只含 IDL + 生成代码） │ ├── user-service/ │ │ ├── user.thrift # 服务契约（唯一真理源） │ │ ├── kitex_gen/ # 自动生成的 Client/Handler/Model │ │ ├── go.mod # module company.com/idl/user-service │ │ └── README.md # 接口变更规范 + 版本日志 │ └── order-service/ │ └── ... │ ├── 🔐 user-service-impl/ # [私有] 服务端实现仓库（仅内部可见） │ ├── handler/ # 业务逻辑实现（实现 idl 定义的 Handler 接口） │ ├── main.go # 服务启动入口 │ ├── go.mod │ │ require company.com/idl/user-service v1.2.0 # 依赖接口仓库 │ └── .gitignore # 禁止提交 handler 业务代码到 idl 仓库 │ ├── 🔐 order-service-impl/ # [私有] 其他服务实现 │ └── ... │ └── 🔐 internal-tools/ # [私有] 代码生成/发布工具链 ├── kitex-gen-wrapper.sh # 封装 kitex 生成命令 └── publish-idl.sh # 自动打标签 + 推送到私有 GOPROXY 🔑 关键原则： idl-registry ： 只含接口契约 + 生成代码 ，权限开放给所有开发者 *-impl ： 仅含业务实现 ，权限严格管控，禁止外部访问 消费方 go.mod 只依赖 company.com/idl/* ， 永远不依赖 *-impl
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 多模块而非单体仓库？ SDK 独立发布 — tikrok-sdk 是核心 QUIC 协议栈，独立版本号，可被外部项目引用 服务端/客户端独立构建 — tikrokd-server 部署在服务器， tikrok CLI 分发给用户，两者没有共享代码的直接依赖 微服务独立演进 — tikrok-services 是完整的微服务平台，使用自己的 go.mod 管理依赖 演进方向是成为平台级产品，同时方便制作成开放平台，方便引入三方协作开发。毕竟一个人可以完成的有限，微服务化后，可以分包给不同的开发者。
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 多模块而非单体仓库？ SDK 独立发布 — tikrok-sdk 是核心 QUIC 协议栈，独立版本号，可被外部项目引用 服务端/客户端独立构建 — tikrokd-server 部署在服务器， tikrok CLI 分发给用户，两者没有共享代码的直接依赖 微服务独立演进 — tikrok-services 是完整的微服务平台，使用自己的 go.mod 管理依赖 演进方向是成为平台级产品，同时方便制作成开放平台，方便引入三方协作开发。毕竟一个人可以完成的有限，微服务化后，可以分包给不同的开发者。
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 多模块而非单体仓库？ SDK 独立发布 — tikrok-sdk 是核心 QUIC 协议栈，独立版本号，可被外部项目引用 服务端/客户端独立构建 — tikrokd-server 部署在服务器， tikrok CLI 分发给用户，两者没有共享代码的直接依赖 微服务独立演进 — tikrok-services 是完整的微服务平台，使用自己的 go.mod 管理依赖 演进方向是成为平台级产品，同时方便制作成开放平台，方便引入三方协作开发。毕竟一个人可以完成的有限，微服务化后，可以分包给不同的开发者。