黄金上门回收小程序整体架构设计：三端协同与微服务支撑

想象一家开遍全国的"黄金回收餐厅"。它没有一间真正的大门面，却在每一个城市都有三种接触顾客的方式：顾客在家用手机点单、上门的师傅带着手持终端收单、总部有一块实时调度大屏。每天成千上万笔回收，从预约、称重、检测到打款，要在几小时内跑完，还不能被算错一分钱。支撑它的，不是某一台超级电脑，而是一套分工明确、彼此咬合的软件架构。

这套架构可以分成四层，自上而下看，就像餐厅的"接单窗口—中央厨房—总账本—后勤车队"。我们把每一层翻译成业务语言，外行也能看懂它在干什么。

第一层：接入层，三个入口与一道统一闸口

接入层解决的是"客人从哪进来"的问题。这里有三条通道，对应三端。

用户端微信小程序，是顾客的主入口。它负责预审估价、预约上门、订单跟踪和电子凭证。对顾客来说，它就像餐厅门口的扫码点单屏：先看菜单、估个价、选个时间，剩下的交给后台。

鉴定师 APP 是上门师傅的手持终端。它负责接单派单、实名采集、检测仪器直连和影像上传。它像后厨师傅手腕上的出餐终端：哪桌的单来了、该做什么、做到哪一步，全在上面。

品牌方 PC 管理后台，是总部的运营大屏。金价管理、订单审核、派单调度、资金复核、风控日志都在这里。它像店长办公室那块实时看板，全局状态一屏掌握。

三端之外，还有一个关键角色：API 网关。它是一道统一闸口，所有请求——无论来自小程序、APP 还是后台——都必须先过这道门。它做统一鉴权、限流和路由，相当于餐厅的保安加引导员：认得出你是谁、拦得住捣乱的、把你领到正确的窗口。三端由此共用同一套后端，数据从入口就被规范起来。

第二层：业务中台，分工明确的六条流水线

如果接入层是窗口，业务中台就是中央厨房里一字排开的工位。它没有把"回收"写成一个巨无霸程序，而是拆成一组微服务，每个微服务只管一件明确的事。

订单微服务，管的是整笔交易的流转状态：预审、已预约、检测中、待审核、已打款。它像流水线的总调度，记住每一单走到哪了。

金价微服务，对接外部行情接口，定时拉取实时大盘金价并缓存。它像厨房墙上的那块价格牌，所有人都看同一块牌，避免有人按旧价算账。

派单微服务，把预约订单匹配给合适的鉴定师，支持上门、到店、邮寄三种履约通道。它像排班表，谁有空、谁离得近，就派给谁。

检测数据微服务，专门接收来自 XRF 光谱仪等仪器的直连数据：纯度、克重、检测时间。它像一台只认设备不认人的记录仪，仪器报多少，它就存多少。

支付微服务，负责把款项按银行卡、微信、支付宝或对公账户打出，并与订单绑定。它像收银台，钱从哪出、出给谁、对应哪单，一笔不少。

风控微服务，做异常交易识别、反洗钱校验和全程留痕。它像后厨里的质检员，盯着每一单有没有不对劲的地方。

这些微服务之间不直接硬绑，而是靠消息队列传递事件。比如检测数据微服务收到结果，就发一条消息，订单微服务听见后把状态推进到"待审核"。一个工位忙了，不影响其他工位，这正是它能撑住全国网络的根本。

把流水线拆开，业务上得到三样好处。其一是故障隔离：某天支付通道临时抖动，只影响打款这一个环节，预约、检测、审核照常进行，不会整站瘫痪。其二是独立迭代：金价展示策略要改版，只需动金价微服务，不必把整套系统停机重发。其三是按量伸缩：哪个环节压力大，就单独给哪个环节加机器，不必为闲置的模块买单。对一家想开遍全国、又不想被技术拖垮的回收品牌来说，这种"哪里忙扩哪里"的能力，比堆一台更贵的服务器实在得多。

值得一提的是，六个微服务各自记录的，都是同一笔订单在不同维度的真相：订单微服务记得"走到哪了"，金价微服务记得"按什么价"，检测数据微服务记得"货是什么成色"，支付微服务记得"钱去了哪"，风控微服务记得"有没有异常"。它们合起来，才是一笔回收的完整画像。

第三层：数据层，总账本、热缓存与检索索引

流水线再忙，也需要可靠的"仓库"。数据层就是仓库，它由三样东西组成。

MySQL 是主账本，存订单、用户、资金等核心数据，要求强一致——钱和货的账必须分毫不差，它来兜底。Redis 是热缓存，把金价、登录态这类高频读的数据放在内存里，像厨房灶台边随手可取的小料，不用每次都跑回冷库。ES（Elasticsearch）是检索索引，负责订单、日志的全文查询，像一本分类清晰的台账，店长要查"上周华东区所有驳回单"时，翻得飞快。

三类数据各司其职：账本保准确、缓存保速度、索引保查找。它们共同支撑上层微服务，不抢活、不越界。落到顾客能感知的地方，就是"报价秒出、查单秒回、账目分毫不差"。没有 Redis，高峰时每次询价都要回查主库，页面会卡；没有 ES，客服想调一笔半年前的订单要翻遍全表，效率低到无法服务；而没有 MySQL 的强一致，最要命的资金账目就可能出错。数据层选型的背后，其实都是在为"快、准、可查"这三个体验买单。

数据层之上还有一层看不见但极关键的设计：所有写入主账本的动作，都会附带操作人、角色与时间戳。这意味着任何一笔金额变动，事后都能回答"谁、在什么时候、因为什么改了它"。这恰是后面角色权限与风控章节能够成立的数据基础。

第四层：基础设施，后勤与合规底座

最底下是看不见的地基。消息队列负责异步解耦，像连接各工位的传送带；行情接口定时拉取，像定时播报的广播；电子签存证把每一份回收凭证固化为可溯源证据，像盖章的正式小票；蓝牙与串口直连，让天平、光谱仪这类仪器跳过人工转抄，像直接接进厨房的智能秤。

还有贯穿全栈的 RBAC 权限模型与 JWT 令牌，确保每一端、每一角色只能碰自己该碰的数据——这部分我们在角色权限篇会专门展开。

弹性：年夜饭与金价跳水两道洪峰

架构好不好，平时看不出，峰值见真章。黄金回收有两个典型洪峰。

其一是邮寄大促。遇到节假日营销，全国顺丰保价邮件涌入，预约量可能是平时的数倍。由于服务拆成了微服务，订单与派单可以单独横向扩容——多开几条"流水线工位"，而金价、支付不受影响，像餐厅年夜饭爆单时，临时加开几个出餐窗口，收银台照常。

其二是金价波动峰值。当大盘金价急跌，大量用户扎堆卖出，询价与下单请求瞬间飙升。Redis 缓存的实时金价扛住高频读，消息队列把写请求削峰填谷，避免系统被瞬间洪流冲垮。弹性不是靠某一台机器变强，而是靠"该扩哪扩哪"的分工。

更深层一点，弹性还体现在"降级"上。万一行情接口在某个时点抽风拉不到金价，系统不会让所有下单卡死，而是回退到最近一次成功缓存的牌价，并在界面标注"金价暂缓更新"，既保住交易不中断，又不让顾客在不知情下成交。这种"宁可标注、不可造假"的设计取向，本身就是对行业信任问题的技术回应。同理，若支付通道短暂不可用，订单会停在"待打款"状态并自动重试，而不是把钱算错或重复打。一个成熟的回收网络，真正考验的不是顺风顺水时的速度，而是出状况时能不能既不乱账、又不甩锅给用户。

把四层与弹性合起来看，这套架构的初心其实很朴素：让三端像同一家店的三个窗口，让六个工位像一条不会堵死的流水线，让账本像一位永不打盹的会计。技术是手段，信任才是目的。

三端如何真正同步

把四层叠起来，一次回收是这样流动的：顾客在小程序预审并预约，请求经网关进入订单微服务；派单微服务安排师傅，鉴定师 APP 接单后上门，实名采集经网关校验；XRF 数据经检测数据微服务直连入库，订单状态推进；PC 后台审核、财务复核，支付微服务打款；风控微服务全程留痕。三端看到的，是同一笔订单在不同阶段的状态——因为它们本就跑在同一套后端、同一张数据账本上。