Tikrok8 新版本更新

[5wunian]

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 缓存加速） 这条链路终于完整了。

第 8 代架构决策

"第 8 代"不是版本号迭代，而是架构成熟度的标志——每一代都解决了一个上一代无法克服的问题。第 8 代的标志是：服务器端 Kitex gRPC 统一迁移 + 媒体处理微服务体系。

以下是在八代演进过程中沉淀下来的关键决策。

为什么选择 Kitex 而非标准 gRPC？

第 8 代将 7 个 gRPC 服务从标准 google.golang.org/grpc 全线迁移至 CloudWeGo Kitex v0.16.2。这一决策的驱动因素和实际效果：

维度	标准 gRPC	Kitex v0.16.2
服务治理	需自行集成（etcd/resolver/拦截器链）	内置 etcd/nacos/consul 服务发现 + 自定义中间件
流式 RPC	BidiStreamingClient 泛型（Go 1.18+）	原生双向流接口，Recv()/Send() 签名简洁
性能	标准 HTTP/2 实现，无额外优化	内置连接池/协程池/请求复用，吞吐提升 10-15%
代码生成	protoc 插件（--go_out + --go-grpc_out）	自有 IDL 编译器，生成 service 骨架
互操作性	N/A	Kitex gRPC 与标准 gRPC 完全互操作（均 HTTP/2 + Protobuf）

实际效果： Kitex 的 server.WithMiddleware 中间件模式比标准 gRPC 的拦截器更简洁——认证、限流、日志等横切关注点在服务启动时统一注册，handler 层零感知。

为什么新增 Image Service 和 Resource Service？

第 7 代中，图片处理和媒体资源管理散落在 Product Service 和 TUS 上传流程中，导致两个问题：

1. Product Service 职责过重 — 同时承载商品/套餐/论坛/教程和媒体资源管理，MediaResource 模型 20+ 字段，DAO 代码 136 行
2. 图片处理无专用通道 — 头像裁剪、教程配图缩放、WebP/AVIF 转换等功能需要实时处理，与商品业务耦合

第 8 代拆分为两个独立服务：

• Image Service：纯实时图片处理（裁剪/缩放/格式转换/质量调整），基于 govips C 绑定库。不存储元数据，只操作 S3 对象。Gateway 直接将图片 URL 指向 image-service 的 HTTP 处理器
• Resource Service：媒体资源元数据管理（media_id → s3_key 映射）、S3 上传授权（presigned URL）、审核、查询。从 Product Service 剥离，两者再无依赖

实际效果： Product Service go.mod 缩小 40%，Image Service 可以独立扩缩容（图片处理是 CPU 密集型），媒体上传/审核流程独立演进。

分享前端权限体系设计

架构总览

config/roles.ts         配置层 ─ 定义"谁"
    └─ UserType / TYPE_HIERARCHY / TYPE_META / hasRole()
config/routes.ts        配置层 ─ 定义"哪些页面"
    └─ PageDef[] / renderRoutes() / deriveSidebar() / validateRoutes()
    │
App.tsx                 生成层 ─ 自动生成 <Route> 树
AdminSidebar            生成层 ─ 自动生成侧边栏菜单
UserSidebar / DeveloperSidebar  同上
RequireAuth / AdminGuard        权限路由守卫

核心原则：两处配置，全自动联动。

• 改角色 → 只改 roles.ts
• 改页面 → 只改 routes.ts
• 不需要改 App.tsx、Sidebar、Guards

---

一、角色体系 (config/roles.ts)

1.1 用户类型

export const USER_TYPES = ['user', 'developer', 'admin'] as const;
export type UserType = (typeof USER_TYPES)[number];

1.2 层级（数字越大权限越高）

export const TYPE_HIERARCHY: Record<UserType, number> = {
  user: 0,        // 普通用户
  developer: 1,   // 开发者（自动拥有 user 权限）
  admin: 2,       // 管理员（自动拥有 developer + user 权限）
};

层级递进逻辑：admin > developer > user。hasRole('admin', 'developer') 返回 true。

1.3 元数据

export const TYPE_META: Record<UserType, TypeMeta> = {
  user:      { label: '普通用户', shortLabel: '用户', color: 'bg-gray-100...', icon: 'fa-user' },
  developer: { label: '开发者',   shortLabel: '开发者', color: 'bg-emerald-100...', icon: 'fa-code' },
  admin:     { label: '管理员',   shortLabel: '管理员', color: 'bg-blue-100...',  icon: 'fa-shield-alt' },
};

1.4 权限检查

hasRole(userType, 'admin')      // user?.type === 'admin'
hasRole(userType, 'developer')  // user?.type === 'developer' || 'admin'
isAdmin(userType)               // 快捷方式
isDeveloper(userType)           // 快捷方式

1.5 Navbar 角色入口

用户在 Navbar 下拉菜单看到的额外入口：

NAVBAR_ROLE_LINKS: [
  { path: '/admin', icon: 'fa-shield-alt', label: '后台管理', minType: 'admin' },
  { path: '/developer', icon: 'fa-code', label: '开发者中心', minType: 'developer' },
]

---

[5wunian]

tikrok 代码行数，这么快突破。
183 提交
329,686++
160,276--
这还是没有算上 tikrok-devops
126 提交
47,229++
4,544--服务器运维代码
这还没算上 前端 tikrok-web
100 提交
39,856++
11,815--
信息系统越完善，需要处理的架构到接口到联调到运维越多。这就是专业