今日实测：鸿蒙端云一体待办清单中 APIG、FunctionGraph 与 RDS 如何分工

今天在华为云开发者成长中心做日常任务时，先后浏览了两个鸿蒙端云一体案例，又在 AI DevSpace 里就其中一个案例的架构提了问题、得到了解答。本文把这次真实的阅读和对话整理成一篇笔记：一个待办清单 App 的请求到底走过哪些服务，每个服务负责什么，以及 30 秒轮询同步这件事值不值得学、又该在什么地方留个心眼。

先说明范围：今天我没有实际开通 RDS、APIG 去部署一整套云资源，本文依据的是两个公开案例的文档和我在 AI DevSpace 里的对话，不是一份部署实录。案例本身是已经验证过的完整链路，我的重点是把它的分工讲清楚。

一、一条请求走过的路

以云同步待办清单为例，一次登录或新增任务，大致走过这样一条链：

HarmonyOS 端（ArkTS） → APIG → FunctionGraph → RDS

端侧只和 APIG 打交道。App 把请求发给 APIG 的统一入口，APIG 再把请求转发给对应的云函数，云函数读写数据库，最后结果原路返回。端侧不需要知道云函数在哪里，也不需要直连数据库，数据库的地址和凭据只存在云函数一侧。

一句话总结分工：APIG 管入口和流量，FunctionGraph 管业务逻辑，RDS 管数据持久化。三者各司其职，端侧只跟 APIG 对话。

二、两个案例对照着看，分工就更清楚了

今天浏览的第一个案例是端云一体员工签到 App：前端用 ArkTS，后端是 Node.js + Express + MySQL，签到时用 GPS 定位结合 Haversine 公式判断是否在公司 500 米范围内，再用 JWT 做登录态。它的后端是一个常驻的 Express 服务，签到、校验、落库都在同一个服务里完成。

第二个案例是云同步待办清单：端侧同样是 ArkTS，但云侧被拆成了 8 个 FunctionGraph 云函数，数据放在 RDS 的 3 张表里，APIG 专享版是唯一公网入口。两个案例做的都是“端侧 + 云端”的事，差别在于云侧的组织方式：一个是整体式后端服务，一个是按接口拆分的无服务器函数。

这个对照很有用：并不是所有场景都要上 Serverless。签到这种逻辑集中、调用频率可预期的场景，用一个后端服务更直观；而待办清单把注册、登录、任务 CRUD、同步、建表、诊断拆成 8 个函数，每个函数职责单一，改一个接口不用动整站，更适合对照着学习“一个接口对应一个函数”的拆分思路。

三、30 秒轮询同步：优点和缺点都得说清楚

待办清单的多端同步用的是 30 秒轮询：客户端每隔 30 秒主动问一次服务器有没有新数据，两台设备登录同一账号，一端改了，另一端 30 秒内能同步一致。

优点有四条。第一是实现简单，端侧一个定时器加一次 HTTP 请求就能做，不依赖长连接、WebSocket 等额外设施。第二是兼容性好，普通 HTTPS 请求即可，HarmonyOS、Web 等不同端可以用同一套逻辑。第三是服务端无状态压力，每次请求独立、短连接，FunctionGraph 天然适配“来了就处理、处理完就释放”的模式，不用维护长连接的会话状态。第四是网络容错，一次请求失败不影响下一次，30 秒后自动重试，对弱网环境有一定韧性。

缺点同样明显。第一是实时性差，最坏情况下 A 端新增一条待办，B 端要等将近 30 秒才知道，对协作编辑类场景体验不好。第二是无效请求多，大多数轮询时数据并没有变化，但请求照发、函数照执行、数据库照查询，这些全是无效开销，用户量一大，函数调用次数和数据库读压力会线性上涨，直接体现在账单上。第三是电量消耗，移动端每 30 秒唤醒一次网络模块，对续航有持续影响，尤其息屏时仍在轮询更浪费。第四是扩展性瓶颈，粗略估算，1 万个用户每 30 秒请求 1 次，每秒就约 333 次请求，读压力不容忽视。

所以我的判断是：学习和演示阶段用 30 秒轮询完全合理，它把同步这件事的复杂度降到了最低；但如果要把这个 App 当成长期产品做下去，应该往增量同步走——比如服务端返回数据的版本号或更新时间戳，客户端只拉取变化的部分；实时性要求再高一点，就要考虑 WebSocket 或消息推送，而不是缩短轮询间隔。缩短间隔治标不治本，只会让无效请求更多。

四、演示环境的安全边界，学习时就要划清

两个案例的文档都明确写了安全边界，这一点值得单独拎出来说，因为初学者最容易把演示配置直接当成生产配置。

待办清单案例目前是演示取舍：APIG 侧无认证，端侧以公网入口地址加 Host 头的方式直连，跳过了证书名校验；会话 token 走 URL 查询参数、永不过期、不可撤销，还以明文存在端侧 Preferences 里；密码倒是做了 scrypt 加盐哈希，SQL 全部参数化，读写按会话归属过滤，DEBUG 日志也会自动剔除 password 和 token 字段——该做的基线做了，没做的也明确列了出来。

如果要往生产走，至少要补三件事：第一，token 改走 Authorization 请求头传输，加上过期时间和刷新、撤销机制；第二，APIG 切到 APP 或 IAM 认证，配上自有域名和可信证书，AppSecret 不要放在可分发的客户端代码里；第三，登录加上限流和审计，APIG 配置限流策略，防止在线爆破。做完这三件，再谈上线才有意义。

五、给想复现的读者的三条建议

第一，先走“快速部署”路线再走“完整实践”路线。先把已验证的源码拉下来跑通一次，看到登录、新增、同步真的能走通，再回头从零写代码，理解会深得多。

第二，部署时全程只用一个区域，区域代码、项目 ID、VPC、子网、安全组这些值一次抄对。案例文档里反复提醒这一点，因为区域不一致是最常见的联调失败原因。

第三，验收要按表来，不要凭感觉。登录、注册、新增、勾选、优先级、截止日期、删除、多端同步、日志面板，一项一项打勾，冷启动第一次 504 是预期现象，重试几次即可，遇到问题先看云函数日志和接口返回的 code，再定位是端侧、网关还是数据库的问题。

今天的收获可以浓缩成一句话：端云一体不是把代码分成两份，而是把入口、业务和数据三件事交给各自最合适的服务，再用一条清晰的请求链把它们串起来。理解了这条链，再去看任何一个端云一体案例，都会快很多。