<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>架构演进 on 姚玉亮的网络日志</title><link>https://yusanwen-code.github.io/tags/%E6%9E%B6%E6%9E%84%E6%BC%94%E8%BF%9B/</link><description>Recent content in 架构演进 on 姚玉亮的网络日志</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><lastBuildDate>Tue, 19 Dec 2023 10:30:00 +0800</lastBuildDate><atom:link href="https://yusanwen-code.github.io/tags/%E6%9E%B6%E6%9E%84%E6%BC%94%E8%BF%9B/index.xml" rel="self" type="application/rss+xml"/><item><title>两年八个月后端架构演进：从 SaaS 到 AI 数据平台</title><link>https://yusanwen-code.github.io/posts/post-69/</link><pubDate>Tue, 19 Dec 2023 10:30:00 +0800</pubDate><guid>https://yusanwen-code.github.io/posts/post-69/</guid><description>&lt;img src="https://yusanwen-code.github.io/images/post-69-cover.jpg" alt="Featured image of post 两年八个月后端架构演进：从 SaaS 到 AI 数据平台" /&gt;&lt;p&gt;把这两年的技术栈摊开看，进进出出的东西不少：go-zero、Wire、Temporal、Hertz、eino……每次变化，都不是我追着潮流去的，是业务把新问题拍在面前，接住，才有下一步。&lt;/p&gt;&#10;&lt;p&gt;从宠物医疗 SaaS 到中台，再到 AI 数据平台，两年八个月，大概走了三段路。&lt;/p&gt;&#10;&lt;p&gt;&lt;img alt="两年八个月的三段架构演进" loading="lazy" sizes="(max-width: 767px) calc(100vw - 30px), (max-width: 1023px) 700px, (max-width: 1279px) 950px, 1232px" src="https://yusanwen-code.github.io/images/post-69-arch-evolution.svg"&gt;&lt;/p&gt;&#10;&lt;h2 id="先给飞行中的飞机换发动机"&gt;先给飞行中的飞机换发动机&#10;&lt;/h2&gt;&lt;p&gt;2021 年 4 月我加入一家 SaaS 公司，接手的第一个大项目，是把宠物医疗 SaaS 从 fasthttp C/S 架构迁到 go-zero B/S。老系统是个迭代了很多年的单体，所有医院共用一套代码、一个数据库，发版靠手动 FTP，回滚基本靠运气。&lt;/p&gt;&#10;&lt;p&gt;迁移动作是先按业务域拆服务：医生端、医院管理、HIS 对接、AI 影像判读各自独立，服务间用 gRPC，Jaeger 做链路追踪。go-zero 的工具链帮了大忙，&lt;code&gt;.api&lt;/code&gt; 文件直接生成路由和代码骨架，团队上手很快。同期还做了经营数据分析平台，加上 C 端顾客小程序和 B 端管理小程序，后端用同一套微服务撑住多端。&lt;/p&gt;&#10;&lt;p&gt;那阵子最大的收获其实不在某个技术点上。数据双写、灰度切流、老接口兼容，这些活儿教科书不教，但每天都在做。说白了，就是学着在不停机的前提下，给飞行中的飞机换发动机。&lt;/p&gt;&#10;&lt;h2 id="中台教会我的是边界"&gt;中台教会我的，是边界&#10;&lt;/h2&gt;&lt;p&gt;2023 年 12 月，我加入一家科技公司，一开始主导统一支付平台和统一认证中心。这两个项目和 SaaS 时代最大的区别在于：它们不是单一产品，是要给多条业务线复用的中台。&lt;/p&gt;&#10;&lt;p&gt;统一支付平台做了三端分离支付、订单状态机、RSA/SHA 签名的 OpenAPI、动态计费引擎和对账导出。状态机是核心。一笔订单从创建到回调成功，可能经历十几次状态跃迁，任何一个分支没覆盖到，就是资损。我的做法是用显式状态机表加幂等键，把每条跃迁写死，不给隐式状态留活路；对账用 Excelize 导出，再和渠道逐笔比对。&lt;/p&gt;&#10;&lt;p&gt;统一认证中心是另一种复杂度：OAuth2/OIDC、RSA 签发 JWT、SSO、多应用 AppID/AppSecret、AppRole 团队隔离、RBAC，还要支持可插拔 Provider（腾讯云 SMS/SES/Captcha），以及微信、企微、飞书登录。我用 Wire 做依赖注入，Service/DAO 分层，最后的效果是新增一种登录方式，只需要实现一个 Provider 接口。&lt;/p&gt;&#10;&lt;p&gt;这个阶段，我的架构审美从&amp;quot;能拆就拆&amp;quot;转向了&amp;quot;该合就合&amp;quot;。中台的价值其实在复用，但过度抽象会把所有业务方绑死。&lt;/p&gt;&#10;&lt;p&gt;边界划在哪里，比用什么框架重要得多。&lt;/p&gt;&#10;&lt;h2 id="核心矛盾换成了长流程"&gt;核心矛盾换成了长流程&#10;&lt;/h2&gt;&lt;p&gt;从数据治理服务开始，工作的性质又变了。S3 预签名上传、PDF 解析、Temporal Worker 数据质量规则引擎、MySQL 加 StarRocks 数仓、OpenAlex 学术数据同步。这套东西的核心矛盾，不再是&amp;quot;高并发业务&amp;quot;，而是&amp;quot;长流程数据管道&amp;quot;。&lt;/p&gt;&#10;&lt;p&gt;Temporal 把我从手写状态机和重试里解放出来：Activity 失败自动重试，Workflow 状态持久化，比 go-zero 时代裸写 goroutine 加补偿逻辑稳太多。后来做数据集管理服务，Hertz 做接入，eino 和 pond 跑高并发的文档解析、向量化、知识图谱构建，存储用 GaussDB 和 MongoDB。那是我第一次认真处理 GPU/CPU 混合调度和大文件内存控制，好在 pond 的 worker pool 把并发度压在了下游能承受的范围内。&lt;/p&gt;&#10;&lt;p&gt;再往后是知识库问答服务，做企业级 LLM 知识库问答，问题又换了一茬：多轮对话、light_rag、MCP 工具调用、多模型路由。统一 LLM 适配层把 OpenAI、Azure、VLLM、HuggingFace 的差异屏蔽掉，业务侧只认一个 ChatCompletion 接口。我看着它从一个能跑的 DEMO，长成能接公司多个业务线的平台，中间踩的坑比前两年加起来还多。&lt;/p&gt;&#10;&lt;h2 id="没变的是这几件事"&gt;没变的是这几件事&#10;&lt;/h2&gt;&lt;p&gt;技术栈从 go-zero 扩到 Hertz、eino、Temporal，架构从微服务扩到数据管道和 AI 平台。但有几件事，从头到尾没变：&lt;/p&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;可观测性要先于功能。没有日志、指标、trace 的系统，跑得再快也不敢上线。&lt;/li&gt;&#10;&lt;li&gt;状态和边界是复杂度的根源。订单状态机、Temporal Workflow、Agent 多步任务，本质都是在管理状态跃迁。&lt;/li&gt;&#10;&lt;li&gt;选型服务于场景。gRPC 还是 HTTP、Temporal 还是裸 goroutine、RAG 还是 Agent，答案永远在具体场景里。&lt;/li&gt;&#10;&lt;li&gt;发布和回滚能力是底线。KubeSphere 容器化让发布效率提升约 80%，故障回滚在 5 分钟内，这比任何架构炫技都实在。&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;p&gt;我没有刻意追过技术潮流，只是被业务推着走，遇到什么问题就解什么问题。回头看，真正的成长是面对一个全新领域时，能快速抓住核心矛盾，再用工程化的方式把它落地。&lt;/p&gt;&#10;&lt;p&gt;这条路还在继续。&lt;/p&gt;&#10;&#10; &lt;blockquote&gt;&#10; &lt;p&gt;封面图：&lt;a class="link" href="https://www.flickr.com/photos/158652122@N02/49925355486" target="_blank" rel="noopener"&#10; &gt;M McBey / Flickr&lt;/a&gt; · CC BY 2.0&lt;/p&gt;&#10;&#10; &lt;/blockquote&gt;&#10;</description></item></channel></rss>