云原生实践｜Serverless如何为世纪联华降本超40%？作者|朱鹏导读：2020年双11

作者 | 朱鹏
导读：2020 年双11 ，世纪联华基于阿里云函数计算 (FC) 弹性扩容，应用于大促会场 SSR、线上商品秒杀、优惠券定点发放、行业导购、数据中台计算等多个场景，业务峰值 QPS 较去年提升 230% ，研发效率交付提效超过 30% ，弹性资源成本减少 40% 以上。当双11 走过 11 个年头，传统企业正在凭借云原生技术悄然逆势崛起，参与到这场全球购物狂欢节中。
联华华商旗下的世纪联华超市近期迎来了一年一度的 “双11” 大促活动。
时光回到 2014 年的双12 ，支付宝联合杭州多家线下品牌和商场门店，推出五折优惠促销活动。在这一次消费狂欢中，滨江区世纪联华店所有的柜员 POS 机前排起了长队，队伍移动速度异常缓慢，商场工作人员表示，服务器出现异常导致支付出了问题。
6 年后的今天，视线再次回到世纪联华超市双11 大促现场，人潮涌动，却井然有序。参与大促的人数是 6 年前的几倍，但现场支付却稳定又顺滑，这种天壤之别的转变，源于世纪联华对云原生技术的大胆尝试。
文章插图
世纪联华大促现场
技术架构演进之路我们有幸采访到世纪联华的技术人员，了解到世纪联华在技术架构演进一路走来的不容易。
2014 年及以前：物理单机架构的灾难过去所有 POS 机及会员卡支付机器全部部署在各个门店，这套架构持续了近十年之久。
这套架构的最大好处是不受网络影响，在当年网络基础建设还不完善的情况下，商家可以尽最大可能地保障单个门店的交易稳定性不受外界影响。这套架构的最大问题是：当门店机器出现故障时，专业的技术管理员很难第一时间赶到现场及时修复，系统维护工作变得十分困难。
2014 年世纪联华的双12 活动中，因为业务遭遇爆炸性流量，多个门店支付时好时坏，短时间也无法维护，导致用户体验差，这让世纪联华的技术人决心改进这套使用了十多年的老系统。
2014~2018 年：中央机房部署架构的演进在 2014 年经历了双12 大促活动的问题后，联华技术人决心改进各项系统，于是将交易系统和会员系统陆续迁移到自建的中央物理机房，商品系统也改迁为中央下发机器，在浙江省各个门店的 POS 机，通过互联网连接至中央机房。
相比 2014 年以前的架构，新架构主要解决了三个问题：

问题修复可集中维护处理
商品调整价格下发全走网络
数据可以集中查询统计

然而新架构遗留的最大的问题是：

管理人员需要掌握所有机器细节
运维过程中可能出现宕机、断网等事件，调查相对困难，应急处理方案薄弱

2018 年~2019 年年中：全面上云随着国内公共云建设的进一步发展，世纪联华也开始全面使用阿里云产品，将本地业务包括 MySQL 等全部迁移到了阿里云 ECS 上。
全面上云很好地应对了宕机、计算节点断网等事件的发生，这也坚定了世纪联华使用阿里云的决心。
然而业务急剧的扩展，数据库的查询写入越来越多，全面上云的架构在 2019 年中促销活动中，某台 16 核 32G 的 MySQL 数据库所在的 ECS，因为会员查询业务实现未做好弹性扩容准备，定时业务陡增导致请求延迟巨大，严重影响了用户体验。
世纪联华开始探索新的业务架构方式，琢磨如何使用简洁的架构实现出更高可用的业务系统。
2019 年年中至 2019 年双11：Serverless 的探索和尝试随着线上业务不断发展，世纪联华的业务量不断扩大。在经历了 2019 年中数据库事件后，世纪联华经过尝试探索后，发现阿里云的表格存储服务比较适合自己的弹性业务：陡升陡降的业务不需要提前做预算来准备购买多少台存储服务器。这让联华的技术人很兴奋，因为很难算准突发的定时抢购业务量，这就导致很难预估准备多少机器来应付相应的业务量。表格存储的出现让联华技术人了解到一个词：Serverless！
在探索 Serverless 的道路上，联华的技术人偶然接触到了阿里云的函数计算，在紧张的测试验证后，技术人员发现函数计算的优异表现很契合联华的业务高度弹性的会员查询系统。
从 2019 年 7 月开始，联华技术人在不到 3 个月的时间里，将原有的会员数据全部副本镜像迁移到表格存储，并将所有渠道商的 API 全面迁移到阿里云 API 网关做分发，会员查询业务的计算业务也全面迁移到阿里云函数计算。