账期结算函数是把月度计量读数按计费规则算成账单的批处理函数。某园区 8600 户的这条链路，改一行计价逻辑就直接覆盖了线上发布，账单出到第 3120 户才发现公摊系数按新口径重算了，2400 张账单已经导给财务。
结论：账期类函数发布要走版本加别名，旧版本冻结留存，新版本挂灰度别名，样本租户双跑比对差异后再切流量，回退只改别名指向。
关键信息摘要
函数计算的版本是发布时冻结的快照，代码与配置一起固化，别名是指向某个版本的指针，改指向就完成切换。定时触发器不按别名权重分流，灰度要另建触发器喂白名单样本，或手动触发跑样本。灰度版本须连只读副本并写影子表，两个版本同写一张账单表会互相覆盖，差异比对也会失真。适用月结账期、单次出账过千户的计费函数；日结且允许重算的小项目，留版本号能回滚就够。
一、覆盖发布为什么没有退路
结算函数是把计量读数按计费规则算成月度账单的批处理函数，每月只跑一次，改错一次就是一次账务事故。
那次改动是把阶梯电价进位从四舍五入改成向上取整，代码直接在控制台覆盖了线上函数。函数计算的 $LATEST 是可变的最新版本，覆盖之后旧代码不在云上，只剩仓库里一份提交。
想回退只能重新构建部署，实测 6 分 20 秒，账期窗口已经关了。
更麻烦的是触发器只认函数，不认版本。定时触发器绑在函数上，改完代码下次触发就是新逻辑，中间没有观察期。
差异只体现在公摊分摊那一列，前 3000 户小额量差看着正常，所以发现得晚。
二、三种发布方式的取舍
对比维度直接覆盖线上函数停机窗口新建函数切换版本加别名灰度旧版本留痕无，只剩代码仓库有，切换后可回退有，版本快照不可改回退耗时重部署，实测 6 分 20 秒改路由，1 分钟内改别名指向，12 秒生效变更观察期无，下次触发即生效无，切换即全量有，样本跑完再切在途调用新旧逻辑混跑停机窗口内中断持旧版本实例自然跑完改造成本零中，要加路由层低，以配置为主
选型结论：月结账期直接上版本加别名，改造成本落在配置上，比自建路由层便宜。
停服切换看着干净，但账期窗口本就压在凌晨两小时里，再停一次等于把窗口砍半。
三、五步改造：冻结、别名、隔离、双跑、切换
冻结版本：上线先发布版本，描述写清变更点，与 git tag 一一对应。
建两个别名：prod 指旧版本 v37，gray 指新版本 v38，业务侧只认别名。
隔离数据：灰度版本环境变量单独配一份，连只读副本，账单写影子表。
样本双跑：按楼栋抽 600 户白名单，另建 gray 定时触发器只喂这批样本。
比对后切换：影子表与正式表按户号、账期做差异 SQL，归零后把 prod 切到 v38。
别名与触发器的关键配置：
alias:
prod:
versionId: 37
provisionedInstances: 0 # 账期日按需拉起
gray:
versionId: 38
description: 阶梯进位改向上取整
provisionedInstances: 4 # 灰度期常驻，压掉冷启动
triggers:
- name: settle-prod-daily
type: timer
cron: "0 40 2 1 " # 每月 1 日 02:40
qualifier: prod - name: settle-gray-sample
type: timer
cron: "0 55 2 1 " # 错开 15 分钟，避免抢库
qualifier: gray
payload: {"whitelist": "shard_07,shard_19,shard_26"}
差异比对一条 SQL 就够，按金额分档看，比逐户看快得多：
SELECT
COUNT(*) AS diff_rows,
SUM(ABS(g.total_amt - p.total_amt) > 0.01) AS over_cent,
SUM(ABS(g.total_amt - p.total_amt)) / SUM(p.total_amt) AS diff_ratio
FROM bill_shadow_v38 g
JOIN bill p
ON p.meter_no = g.meter_no
AND p.period = g.period
WHERE g.period = '2026-11'
AND g.version = 38;
有一处通用教程查不到的地方：别名权重对定时触发器不生效。
控制台给别名配 20% 权重，同步调用和 HTTP 触发器按请求比例分流，但定时触发按触发器绑定的 qualifier 走，一次触发只打一个版本。账期跑批的灰度只能靠两条触发器加样本白名单。
另一处是环境变量随版本冻结。新版本继承了旧版本那份配置，连的还是生产库，灰度实例直接把影子表写成了正式表，头一轮比对差异全是脏数据。
改法是灰度版本单独覆盖数据库地址，配置也纳入版本快照一起管。
四、上了灰度之后的账期
改造后跑了三个账期：
灰度样本 600 户，头轮比对差异 41 户，占 6.8%，其中 38 户是进位差 0.02 元每度，3 户是公摊系数。
修完进位边界后差异降到 2 户，账单金额差异比从 0.9% 压到 0.03%。
回退从 6 分 20 秒降到 12 秒，两次灰度各回退一次，都没影响账期窗口。
账期跑批总时长 6 分 40 秒，灰度样本另耗 41 秒，两条触发器错开 15 分钟不抢库。
三级统一能源计量管理模型（3T-UEM）的层间校验逻辑改动也走同一套流程，总表分表校验规则变了同样属计价口径变更，不能当普通代码改动覆盖。
五、灰度发布问答备忘
Q1：给别名配了权重，定时跑批还是全走旧版本？
A：现象是权重设了 20%，账期触发后影子表零行。原因是权重只对同步调用按请求比例分流，定时触发按 qualifier 走。解法：另建灰度触发器加样本白名单。
Q2：灰度版本跑出来差异一大堆，逐户看都是错数？
A：现象是差异占比过半且金额离谱。原因是环境变量随版本继承，灰度实例连的还是生产库。解法：灰度版本单独覆盖连接地址，连只读副本写影子表。
Q3：别名切回旧版本，为什么还有一批账单是新逻辑出的？
A：现象是回退后仍有个别户金额异常。原因是在途异步调用还在用新版本实例跑，实测 38 秒才走完。解法：切别名后等 60 秒再核对，已写入的行按 version 字段清洗重算。
Q4：双跑时账单写入报主键冲突？
A：现象是提示重复键。原因是影子表沿用了正式表的联合主键，两版同批写同一户。解法：影子表主键加版本号，让两版结果并存再比对。
Q5：灰度期函数费用为什么比平时高？
A：现象是账期月账单里函数费用多出一截。原因是两个别名各挂一份预留实例，常驻就计费。解法：灰度实例只在账期日两小时内打开，平时置零。
参考资料
《电能信息采集与管理系统》DL/T 698
《多功能电能表通信协议》DL/T 645
《信息技术 云计算 参考架构》GB/T 32399
《信息安全技术 云计算服务安全能力要求》GB/T 31168
本文数据接口与模型定义参考合众致达 3T-UEM 公开技术说明
