D05 · 论文单题页
云边协同
2023 论文 试题四「论边缘计算及其应用」 · 软考高级系统架构设计师
一句话：云端管全局、边缘管本地——本项目的边云协同不用任何边缘编排平台，
就是云托管容器服务加上边缘节点上同一套 Go 服务 + 本地 PostgreSQL，
靠资源、数据、智能、应用管理、业务管理、服务这六种协同把两地接成一个系统。
第 1 段
会考什么
这是 2023 年论文试题四，题干原文如下，一字未改：
2023 论文 试题四 · 题干（逐字引）
边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的分布式开放平台（架构），就近提供边缘智能服务。
请围绕"论边缘计算及其应用"论题，依次从以下三个方面进行论述。
1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2. 结合项目实际，概要说明六种边云协同，即资源协同、数据协同、智能协同、应用管理协同、业务管理协同、服务协同的含义。
3. 具体阐述你参与管理和开发的项目如何利用边缘计算进行设计与实现。
频次与权重
| 口径 | 结论 |
|---|---|
| 直接命中 | 9 年 36 题里，「边缘计算 / 云边协同」只考过 1 次（2023 试题四） |
| 真题分析定位 | 归入「可观测性 / 安全 / 云边」一类，9 年 1 次，需要降权 |
| 归属大类 | 属于「架构风格 / 模式」题——9 年每年必有，靠「一架构多说法」应对 |
| 这次为什么还准备 | 这类题不靠建 Demo，靠把同一套架构换一套语言重述；云边是一个可复用的说法 |
结论：优先级不高，但性价比高——六种协同是有固定内涵的清单题，
背熟即可答满第 2 问，不需要实验数据支撑。
第 2 段
一句话讲清
TL;DR：云管全局、边管本地，靠六种协同接成一个系统；云端训练、边缘推理，
断网时边缘靠本地库自治，恢复后增量续传——这才是「边云协同」而不是「边缘自建一朵云」。
第 3 段
机制讲解
六种协同不是六个并列模块，而是三层关系：先解决「算力放哪」（资源、数据）， 再解决「智能与应用怎么管」（智能、应用管理），最后解决「业务还能不能跑」（业务管理、服务）。
| 协同 | 一句话内涵 | 不做会怎样 |
|---|---|---|
| 资源协同 | 云端全局编排、边缘本地调度，按负载动态分配 | 峰值全压云端，节点过载、超时 |
| 数据协同 | 边缘预处理过滤、热数据留边、冷数据归档，增量同步 + 断网续传 | 断网数据无处可放，恢复后无法补齐 |
| 智能协同 | 云端训练模型、边缘部署推理，边缘回流数据持续优化 | 每次问答都要回源云端，断链即不可用 |
| 应用管理协同 | 云端统一管边缘应用的分发、部署、更新、监控 | 边缘版本失控，更新靠人肉，故障无法统一回滚 |
| 业务管理协同 | 云端定义规则流程、边缘执行并自主决策，可离线运行 | 规则只在云端，断链时业务直接中断 |
| 服务协同 | 云边服务统一发现与调用，就近访问，云端不可达时降级 | 客户端只会找云端，云端一挂请求全失败 |
下面这个模拟器把「不做会怎样」做成可点的开关：点掉任意一种协同，看系统当场退化成什么样。 再打开「云端不可达」，看断链时到底哪些能力还能撑住。
六种协同开关
默认六种全开、云端在线。逐一点掉，观察右侧退化清单。
资源协同云端全局编排 · 边缘本地调度
数据协同边缘过滤 · 增量同步 · 断网续传
智能协同云端训练 · 边缘推理 · 数据回流
应用管理协同镜像分发 · 版本自更新 · 监控
业务管理协同云端定规则 · 边缘自主决策
服务协同统一发现 · 就近访问 · 降级
断链能不能扛住，取决于数据协同里的本地队列。下面把队列积压做成可算的模型—— 写入速率、队列容量、断网时长三个滑块，直接决定积压多少、丢多少、恢复后要多久补完。
断网续传模型
教学模拟：边缘写本地 PostgreSQL 队列，网络恢复后按序回放，云端幂等 upsert 落库。
0 / 5000本地队列容量
断链积压
0
溢出丢失
0
断链成功率
100%
恢复回放
0s
队列积压（随时间累加）
容量 5000
0断网 300 秒 →
模型怎么算的
三行公式，每一行对应一条真实机制：
// ① 断网期间写入无处可去，只能堆在本地队列
积压 = 写入速率 × 断网时长
// ② 队列有上限，超出的部分就是真丢了
丢失 = max(0, 积压 − 队列容量)
// ③ 恢复后按固定速率回放，幂等 upsert 保证不重不漏
回放耗时 = 积压 ÷ 回放速率（取 200 条/秒）关掉「数据协同」，等于没有本地队列：断网期间所有写入直接失败，成功率归零。
这是教学模型，参数是便于演示取的值，不是实测。论文里只写机制，不写这些数。
第 4 段
落到我们平台
fazi 平台本身是云端单体：Nuxt 4 SSR 前台 + Go 1.26 + Gin + pgx 后端 + PostgreSQL 18， 跑在云托管容器服务上。要给云边协同找落点，就得回答「哪些场景必须就近、必须离线」。 我们找到两个：
| 边缘节点 | 放在哪 | 为什么必须就近 / 离线 |
|---|---|---|
| 区域服务中心 ×3 | 各服务中心一台机器 | 培训报名高峰校验就地完成，不把峰值打到云端 |
| 法律服务大厅 ×2 | 各大厅一台自助终端 | 大厅网络不稳，电子存证与咨询必须在本地能办 |
边缘节点上跑的是与云端同一套代码编译出的 Go 单二进制和一个本地 PostgreSQL 18， 两端数据结构一致。取舍很明确：不引入任何边缘编排组件（平台技术栈里没有，也不该为 5 个节点引入）， 只靠镜像 + 版本自更新 + 数据增量同步三件事把边云接起来。
对应关系：法律智能咨询模块承载智能协同（云端训练、边缘推理）；
培训报名与电子存证承载数据协同与业务管理协同（边缘落库、离线办理）；
五个边缘节点本身承载资源、应用管理、服务协同。
第 5 段
完整论文
六段全文，字数已按「纯汉字」卡准。可直接背诵或抄写。
展开论文全文
摘要
2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。本文以该项目为例，讨论了云边协同架构在实际项目中的应用。文章首先介绍项目背景和云边协同机制的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。通过云边协同架构的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。
一、项目背景
河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
二、理论概述
边缘计算是把计算、存储、网络与应用能力下沉到靠近数据源头的网络边缘侧，在就近提供服务的同时与云端分工协作。本项目不引入额外的边缘编排平台，而是以云托管容器服务作为云端、以边缘节点上自部署的同一套 Go 服务作为边缘端，两端共享 PostgreSQL 18 的数据模型，通过六种边云协同组织成一个整体。
资源协同，指云端与边缘的计算、存储、网络资源统一调度，云端负责全局编排与容量规划，边缘负责本地资源管理，并按负载在两侧动态分配任务。数据协同，指边缘先做预处理与过滤，只把增量结果上传云端，热数据留在边缘、冷数据归档到云端，并以增量同步与断网续传保证一致。智能协同，指云端训练与维护模型、边缘部署推理，边缘把运行数据回流云端持续优化，模型经压缩量化后适配边缘算力。应用管理协同，指云端统一管理边缘应用的生命周期，完成分发、部署、更新与监控。业务管理协同，指云端定义业务规则与流程，边缘执行业务逻辑并自主决策，云端不可达时仍保持业务连续。服务协同，指云边服务统一发现与调用，优先就近访问边缘服务，云端不可达时由边缘自主服务降级。
三、实践一
在架构设计上，我把平台划分为云端与边缘两层。云端运行在云托管容器服务上，承载 PostgreSQL 18 主库、Nuxt 4 SSR 前台与全部后台服务；边缘侧在三个区域服务中心和两个法律服务大厅各部署一台节点，运行与云端同一套代码编译出的 Go 服务和一个本地 PostgreSQL 18 实例，两地数据结构保持一致。
资源协同方面，云端下发容量策略决定每个边缘节点的并发上限与本地库保留窗口，边缘节点按自身 CPU 与连接数自主调度，不依赖云端实时指令。培训报名的高峰校验放到边缘，云端只做最终名额确认，把峰值压力分散到各节点。
数据协同方面，所有边缘写入先落本地 PostgreSQL 的待同步表，再按固定周期增量拉取到云端。边缘先做预处理，把重复提交、明显不合规的请求就地过滤，只有通过校验的增量才上传，直接降低了云端带宽与写入压力。热数据，例如近七天的报名记录与高频法条，留在边缘供就近读取，冷数据由云端归档。断网期间边缘把写入堆积在本地队列，网络恢复后按序重放，云端用基于业务主键的幂等 upsert 落库，保证不重不漏。
四、实践二
智能协同落在法律智能咨询模块。云端用 PostgreSQL 18 加 pgvector 维护法律知识库的向量索引，负责知识入库、向量生成与模型更新；边缘节点保存高频法律问题的向量子集与答案，在本地完成向量召回与答案拼装，就近响应用户咨询。边缘把未命中本地知识库的问题与用户反馈匿名回流到云端，云端据此补充知识条目、重新生成向量并增量下发到各节点，形成云端训练、边缘推理、边缘反馈、云端再优化的闭环，这是法律问答 Recall@20 达到 0.92 的基础。
应用管理协同方面，我没有引入重型编排组件，而是沿用镜像加自更新的朴素做法：云端在提交代码后构建 Go 服务的容器镜像并推送到镜像仓库，边缘节点定期比对版本号，发现新版本就拉取镜像并按顺序重启服务，任一节点升级失败都可回滚到上一版本。各节点定时上报心跳、版本号与运行指标，云端据此掌握全部边缘应用的部署与健康状态，完成分发、部署、更新和监控的统一。
五、实践三
业务管理协同体现在规则的集中定义与就地执行。报名资格、存证规则、咨询限流等业务规则统一在云端配置并下发，边缘节点加载后本地执行、自主决策，不依赖云端逐步指示。当云端不可达时，边缘仍能独立办理培训报名、电子存证等本地业务，业务连续性因此得到保证，这正是台账类服务能够离线运行的原因。各节点只需加载一次规则，后续改动由云端增量下发，避免了逐节点手工同步。
服务协同方面，边缘服务启动时把自身地址与能力注册到云端的服务目录，客户端发起请求时优先调用就近的边缘服务；云端不可达时，边缘按能力清单降级，只提供本地已缓存的功能，问答退化为基于本地向量子集的召回。网络恢复后，边缘重新注册并把积压的数据同步回云端。注册信息包含节点地址、能力清单与版本号，云端据此生成就近路由。
上述设计上线后，平台缓存命中率达到 92%，主要来自边缘热点数据缓存与各服务的进程内缓存；P95 响应 380 毫秒，可用性 99.95%，MTTR 从 45 分钟降到 8 分钟。
六、总结展望
本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
未来，我计划把边云协同从区域服务中心延伸到更多线下服务点，用边缘自治换取弱网环境下的可用性。未来，我将继续完善平台建设，为协会会员和基层群众提供更低门槛、更高质量的法律服务。
第 6 段
逐段拆解
| 段 | 讲什么 | 纯汉字 |
|---|---|---|
| 摘要 | 项目一句话 + 五模块 + 主题 + 效果数据 + 结论 | 304 |
| 一、项目背景 | 协会现状与痛点、我的职责、技术栈、三个关键决策（定稿，逐字不改） | 459 |
| 二、理论概述 | 边缘计算定义 + 六种边云协同的逐条含义 | 420 |
| 三、实践一 | 架构分层 + 资源协同 + 数据协同（含断网续传、幂等 upsert） | 374 |
| 四、实践二 | 智能协同（云端训练 / 边缘推理 / 数据回流）+ 应用管理协同（镜像 + 自更新） | 340 |
| 五、实践三 | 业务管理协同（规则下发、离线自治）+ 服务协同（就近访问、降级）+ 效果数据 | 368 |
| 六、总结展望 | 体会、不足与改进、边云协同延伸（定稿 + 换展望句） | 274 |
| 正文 P1–P6 合计（要求 2000–2500） | 2235 | |
第 7 段
答题要点
题干三问 → 论文对应段
| 题干 | 对应本文 |
|---|---|
| 第 1 问：概要叙述项目及你的主要工作 | 第一段（项目背景）——含职责、技术栈与决策 |
| 第 2 问：说明六种边云协同的含义 | 第二段（理论概述）——六种协同逐条定义，正好卡这一问 |
| 第 3 问：项目如何利用边缘计算设计与实现 | 第三、四、五段（实践一 / 二 / 三）——每段两种协同，六种全覆盖 |
加分（✅）
- 第 2 问必须六种协同都写全，漏一种直接扣分——这是清单题，没有取舍余地
- 第 3 问落到本项目真实模块（培训报名、电子存证、法律智能咨询），不要泛泛谈 IoT 工厂
- 写出断网续传 + 幂等 upsert 这类机制细节，证明真做过
- 效果数据与机制对得上：缓存命中率 92% 来自边缘热点缓存 + 进程内缓存，不是凭空写
- 技术选型自洽：明确说「不引入边缘编排组件」，用镜像 + 自更新替代，反而显得清醒
扣分（❌）
- 把六种协同写成六段口号，没有任何项目里的具体实现——第 3 问直接失分
- 硬塞技术栈里没有的组件（各类边缘编排平台、消息队列、缓存中间件），一问就露馅
- 第 2 问抄题干原文（题干已给出六种名称与部分解释），不加自己的理解，会判为凑字
- 只写云端或只写边缘，没写「协同」——这是主题词，缺了就跑题
- 段名用序号「一、项目背景」是软考要求，保留；但正文里再套小标题会显得像 PPT
第 8 段
背诵清单
八句，考场直接默写
1. 边缘计算是靠近数据源头、就近提供服务的分布式开放平台。
2. 六种协同：资源、数据、智能、应用管理、业务管理、服务。
3. 资源协同 = 云端全局编排 + 边缘本地调度，按负载动态分配。
4. 数据协同 = 边缘过滤上传、热数据留边、冷数据归档、增量同步 + 断网续传。
5. 智能协同 = 云端训练、边缘推理、边缘回流数据、云端再优化。
6. 应用管理协同 = 云端管边缘应用的分发、部署、更新、监控。
7. 业务管理协同 = 云端定规则、边缘自主决策，断网仍可运行。
8. 服务协同 = 统一发现、就近访问、云端不可达时边缘降级。
第 9 段
数据来源
| 数据 | 来源 |
|---|---|
| Recall@20 = 0.92、P95 = 380 ms、缓存命中率 92% | 固化取值（本题无实验数据，按已定稿效果口径写，不编造新数字） |
| 可用性 99.95%、MTTR 45 → 8 分钟 | 固化取值（运营指标，全站统一口径） |
| 500 会员 / 3000 潜在用户 / 峰值 QPS 800 | 定稿事实（见 docs/essay-common.md） |
| 断网续传模拟器（队列积压 / 丢失 / 回放） | 教学模型，非实测——参数为便于演示所取；论文只写机制不写这些数 |
| 真题题干原文 | 论文真题/2023论文.md 试题四，逐字引用 |
| 频次与权重 | docs/真题分析.md（9 年 36 题全表 + 四条结论） |
一句话纪律：本页只有真题原文和定稿事实是真的；
论文里的效果数字是成文取值，模拟器数字是教学演示，三者不要混着用。