商协会办年会、论坛，报名往往集中在开放通道的那几分钟，几百人同时点进来，瞬时并发能把单体应用打挂。平时流量又很低，为这几分钟常驻高配服务器不划算。函数计算 FC 的弹性扩缩容正好对上这个场景。
思路：报名接口做成 FC 函数，前面挂 API 网关收流量，数据落表格存储，峰值自动扩容，闲时缩到零。
用 FC 的 HTTP 触发器或 API 网关对接。
# FC 报名处理函数（Python 运行时）
def handler(environ, start_response):
body = json.loads(environ['fc.request.body'])
item = {
'activity_id': body['aid'],
'member_id': body['mid'],
'created_at': datetime.now().isoformat()
}
table.put_item(Item=item)
start_response('200', [('Content-Type','application/json')])
return [b'{"ok":1}']
弹性配置上，FC 实例数下限设 0、上限按预估峰值，API 网关做限流和鉴权，表格存储按量计费，不用预先买容量。
几个实践。第一，冷启动要压测，报名函数逻辑轻、依赖少，冷启动控制在几百毫秒内。第二，幂等，会员重复点击报名，函数里用会员加活动做唯一约束，重复写直接返回已报名。第三，库存类字段，剩余名额，用原子操作扣减，别先查后减，并发下会超卖。第四，降级，FC 或存储异常时，先收报名到队列，恢复后回放，别直接报错把会员拒掉。
闲时缩到零是 FC 的省成本点。一个几百人的商会，一年就几场活动，常驻服务器大半时间在空转，FC 按调用计费，平时不花钱。
我们这边在用的未来漫城商协互联平台，活动报名这类突发流量场景，也是走弹性扩缩容的思路，开放报名时扛得住峰值，平时不占资源。
商协会系统的流量特征是典型的脉冲型，平时低、活动时高。把脉冲型接口交给 FC 这类弹性计算，比常驻高配更经济，也更能抗突发。架构顺着流量特征走，成本和稳定性才能同时稳住。
再补充一点成本视角。函数计算按调用和时长计费，商协会活动一年就几场，平时几乎零开销，只在报名开放那几天有费用。相比常驻两台服务器按月付费，长期省不少。尤其多分会、多活动的商会，弹性计费的收益更明显。
还有监控。FC 配合日志和指标，能看到每次报名的耗时、失败数，异常时告警。别等会员反馈报名点不开才发现问题，监控前置，活动当天才稳。
幂等和降级前面提过，这里再强调。报名是会员感知强的动作，失败一次体验就很差。函数里做好唯一约束和失败重试，配合队列削峰，峰值再高也不会把会员拒之门外。
弹性扩容适合所有脉冲型场景，不只报名。会费集中缴纳、活动集中签到，都能用同一套思路。把商协会系统里平时低、活动时高的接口识别出来，交给 FC，成本和稳定性就同时稳了。
再说一个落地顺序。先拿一场活动试水，别一上来把所有接口都改。试水跑顺了，再逐步把其他脉冲接口迁移过来。迁移时保留原接口做兜底，确认 FC 稳定后再切流量，平滑过渡不冒险。
架构顺流量特征走，是商协会系统性价比最高的选择。常驻高配抗偶发峰值，是花钱买安心；弹性计算按用量付费，是花在刀刃上。
弹性计算值不值，看峰谷差。商会活动峰谷差大，平时空转、活动时挤爆，正好是弹性计费该用的场景。
