新零售：从上云到云原生 Serverless

Posted 2021-07-03 CSDN云计算

作者 | 七凌

来源 | 阿里巴巴中间件

头图 | 付费下载于 IC Photo

某零售商超行业的龙头企业，其主要业务涵盖购物中心、大卖场、综合超市、标准超市、精品超市、便利店及无人值守智慧商店等零售业态，涉及全渠道零售、仓储物流、餐饮、消费服务、数据服务、金融业务、跨境贸易等领域。为了持续支持业务高速且稳定地发展，其在快速上云后，将核心业务改造为全 Serverless 架构的中台模式，采用函数计算 + API 网关 + 表格存储 OTS 作为计算网络存储核心，弹性支撑日常和大促峰谷所需资源，轻松支撑 618/ 双11/ 双12 大促。

传统企业为什么更需要关注 Serverless

为了降低技术研发成本、提升运维效率，越来越多的企业选择使用 Serverless 作为基础研发底座，大力发展业务。在 CNCF Serverless 研究报告中显示，大量的国内开发人员正在将传统架构往 Serverless 上做迁移。Serverless 的出现给传统企业数字化转型带了更多机遇。

传统企业为什么更要关注 Serverless ？

现如今，大量尖端技术人才更偏向在互联网公司就业，传统企业又面对着大量技术升级和重构技术架构的刚需，人才缺口和技术升级之间产生了对云原生技术的需求。Serverless 的出现抹平了研发人员在预算、运维经验上的不足。在帮助企业对抗业务洪峰的情况下，研发人员能轻易掌控处理，不仅极大地降低了研发技术门槛，而且大规模提升了研发效率。对于开发者而言，线上预警、流量观测等工具一应俱全，关键是免去了运维负担，切实为广大开发者提供了普惠技术红利。对传统企业而言，Serverless 缩短了互联网公司与传统企业之间技术竞争力的距离。

从上云到云原生

2016 年以后，随着国内公共云的迅速发展，全面上云势不可挡。某知名大型商场在 2018~2019 年期间，把自建机房中的各个系统模块逐渐迁移到了公有云，整体架构没有太大改变，因此迁移工作比较顺利。

系统全面迁移上云后一些改进和不足：

1

改进

不再需要关心网络、操作系统的硬件细节

比如阿里云的 ECS 会提前做调度和预警，把用户数据转移并做多份数据的备灾，防止磁盘坏掉的情况发生。

升级快捷简单

比如用户使用的是 4 核的机器，当发现业务增长迅速需要做硬件升级时，就只需要做一个镜像。比如在夜间做一个磁盘快照，重新申请一台新机器，然后把快照恢复上去，就可以完成一键迁移。对用户来说这是非常快捷的方式，对开发者来说也是较好的体验。

机器扩容时间大幅缩短

上面提到的是单机扩容，比如 4 核升到 8 核、16G 升到 32G 的内存。除此之外还有横向的扩容，例如用户交易系统的 API 接口，随着业务的发展需要由原来的 2 台机器扩到 8 台机器，这种情况下用户只需去申请机器，然后将镜像扩展到不同的机器上即可。

2

不足

资源预算困难

无法预估业务遇到大促活动时所能达到的体量，因此无法准确计算出所需硬件的数量。

水平扩展

水平扩展对研发有较高的要求。比如数据是否要做到无状态，无状态的话水平扩展会比较容易，而如果是有状态，数据可能就需要做缓存，这就会涉及到数据库相关的问题，例如数据过期、一致性等。如果对这些了解不够透彻，做水平扩展就会比较困难。

水位监控

许多开发者在水位监控上处理得并不完善，如果将各个业务系统混在一台机器上，当遇到机器水位较高，想要快速排查问题并及时进行流控、拆分、临时修复等就显得尤为困难。

财务预算困难

与资源预算困难类似。

硬件升级成本高

要做到用户无感无损升级，可能会涉及到连接上的处理与数据库一致性的问题。如果多个模块需要同时升级，还要注意数据结构的兼容问题。

数据库单点故障

许多厂家将数据全部放在一个数据库中，如果处理不妥当可能会造成单点故障。这就要做数据拆分，粗拆的话，需要注意事务和锁相关的问题，效率会大打折扣；细拆的话，做查询和排序时就会比较困难，给业务实现造成一定麻烦。

业务挑战

在一次年中大促时，由于线上业务用户访问不可控，数据量过大，mysql 单机访问被打爆，导致了存储数据库出现问题，影响到了多个系统，造成了一定的损失。因此在后续服务化改造过程中，数据库选型由 MySQL 更改为表格存储 OTS，表格存储最大的优点是用户不需要关心访问量和机器数的比例关系。只要访问量扩大，后台会自动扩容增扩机器，满足高并发的数据读取；在数据并发请求降低处于低峰期时，后台就会将机器回收，用户不再需要关心机器的数量及如何调动。

Severless改造

针对用户流量不可控问题，客户引入了阿里云的产品“API 网关”，API 网关可以针对不同渠道商做管控发布及流量控制。比如发现微信渠道流量有异常，就可以借助 API 网关进行限流。

另外计算也是一个非常重要的问题，客户经过探索发现阿里云函数计算 FC非常契合其业务场景。比如定时抢购、优惠券投放等活动造成巨大的 burst 冲击，当发现计算资源不够的时候再去买机器肯定是来不及的，而函数计算及时扩容的功能就很好地解决了这个问题。另外其数据观测和异常报警功能，也吸引到了客户。

今年 3 月，权威咨询机构 Forrester 发布 2021 年第一季度 FaaS 平台评估报告，阿里云函数计算凭借在产品能力、安全性、战略愿景和市场规模等方面的优势脱颖而出，产品能力位列全球第一，这也是首次有中国云厂商进入 FaaS 领导者象限。

在紧张的测试验证后，技术人员发现函数计算的优异表现很契合自身业务高度弹性的会员查询系统。从 2019 年 7 月开始，客户的技术团队在不到 3 个月的时间里，将原有的会员数据全部副本镜像迁移到表格存储，并将所有渠道商的 API 全面迁移到阿里云 API 网关做分发，会员查询业务的计算业务也全面迁移到阿里云函数计算。

2019 年的 双11，函数计算作为计算模块，表格存储作为存储模块，顺利地帮助客户渡过大促，扛住高峰流量的同时确保了应对业务的弹性。而未使用 Serverless 的业务因为预估不足，出现了一些异常。正是因为函数计算在 双11 中的表现让客户技术人很振奋。在顺利度过大促活动后，客户就在所有业务中全面使用函数计算及表格存储！

新零售商超整体架构图

• 全 Serverless 架构：函数计算 + API 网关 + 表格存储；

• 弹性高可用：毫秒级弹性扩容、充足的资源池水位、跨可用区高可用；

• 敏捷开发免运维：函数式极简编程可专注于业务创新，无采购和部署成本、提供监控报警等完备的可观测能力。

2019 年下半年，阿里云函数计算宣布推出 2.0，支持预留模式，全面解决冷启动延迟大的问题；推出单实例多请求问题，较少实例支持重 IO 高并发类型请求调用；支持自定义运行时，支持一键迁移传统 Web 架构服务器。2.0 的出现让函数计算在业务和规模上实现了巨大升级。

在经历了过去的线下场景考验后，客户将各渠道商的业务及旗下的移动 App，以及线上交易、定时抢优惠券、秒杀业务也全部从 ECS 迁移到了函数计算 2.0，在开启预留模式调整好单实例多并发的模式后，顺利地扛过了是平时数十倍的洪峰流量请求。

比较上述的“时间-流量图”及“时间-延迟”两图可以看到，急剧上升的突发流量对用户造成的延迟变化影响非常小，从实际用户反馈来看确实也证实了用户体验非常顺滑。

所有的数据和业务上云，减轻的不只是研发人员的心理压力，更为研发人员大量减负，从而让大家可以做更聚焦在业务逻辑上的事情。函数计算可以让研发人员不用管理服务器这些基础设施，只要编写代码上传，系统就会准备好计算资源，还提供日志查询、性能监控、报警等功能。如果是按照以前的模式，超市搞 双11 大促，相关的技术团队都睡不着觉，只靠扩展机器支撑大体量的流量和业务，谁心里都没谱。现在扩容的问题交给阿里云，水位远远高于客户原有的储备能力的极限。

今年，Serverless 迎来重大升级。函数计算重磅发布容器镜像加速技术，容器启动延时缩短 50%-80%，将原本属于开发者的镜像优化负担转由函数计算承担，进一步帮助开发者提高生产效率，专注业务创新。该技术源于阿里集团超大规模和场景高度复杂的容器环境，对镜像存储、加速技术有深厚的积累，并出色地承担了 3 年双十一、双十二、春节等大促秒杀场景的严苛的挑战。

同时，Serverless 应用引擎(SAE)重磅发布 Java 应用启动加速功能，首度将 Alibaba Dragonwell(阿里云开源的 Open JDK 长期支持版本)的冷启动加速技术、多线程运行加速技术和 SAE 自身的原地升级策略、镜像预热策略相结合，实现了 Java 应用的端到端启动速度提升 45%，最快仅需 15s，多线程性能提升 30%。

由于业务场景、用户习惯迅速变化，许多行业数字化业务出现急速增长，加快数字化业务发展成为传统企业的必然选择。云原生是企业数字化最短路径，越来越多的传统企业正在拥抱云原生，借助更加快速、灵活的开发和交付模式，满足市场快速变化的需求，进而加速业务创新。传统零售企业借助 Serverless 保证了一次次大促的成功，正是这一趋势的最好证明。