5wunian
V2EX  ›  编程

Tikrok8 新版本更新

  •  
  •   5wunian · 1 day ago · 435 views

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

    Supplement 1  ·  1 day ago

    第 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_ids3_key 映射)、S3 上传授权(presigned URL)、审核、查询。从 Product Service 剥离,两者再无依赖

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

    1 replies    2026-05-24 19:14:05 +08:00
    5wunian
        1
    5wunian  
    OP
       23h 59m ago
    tikrok 代码行数,这么快突破。
    183 提交
    329,686++
    160,276--
    这还是没有算上 tikrok-devops
    126 提交
    47,229++
    4,544--服务器运维代码
    这还没算上 前端 tikrok-web
    100 提交
    39,856++
    11,815--
    信息系统越完善,需要处理的架构到接口到联调到运维越多。这就是专业
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   3497 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 50ms · UTC 11:13 · PVG 19:13 · LAX 04:13 · JFK 07:13
    ♥ Do have faith in what you're doing.