Serverless如何赋能餐饮行业数字化？乐凯撒思变之道

导语 | 在数字化浪潮席卷全球的今天，每一个行业都在经历着前所未有的变革。餐饮行业作为人们日常生活中不可或缺的一部分，更是面临着巨大的转型压力。如何完成数字化转型，打破传统经营模式的限制，成为摆在众多餐饮商家面前的一道难题。餐饮行业如何在当下数字化时代找寻自己的出路？今天，我们特邀了乐凯撒 CTO 黄道泳老师，他将为我们深入解读以乐凯撒为代表的餐饮行业的数字化转型之道。

作者简介

黄道泳，腾讯云 TVP，乐凯撒 CTO。目前主要负责乐凯撒的整体信息化、数据化和智能化的建设。拥有14年的企业信息化和数据化建设经验。在乐凯撒面向新餐饮的服务转型中，积累了丰富的实践经验，并对 Serverless 技术在实际生产中应用有独到的见解。曾担任 IBM Webshpere 中国区官方论坛的版主和专家，对于系统架构，性能调优略有心得。

一、从餐饮行业的五大特征看数字化转型的必要性

近年来，随着数字技术的持续发展、迭代和应用推广，餐饮行业的堂食已经从人力点餐快速演变为扫码点餐，外卖送餐不仅仅是在线点餐即时配送，更是与短视频、线上直播有效结合，以短视频营销、线上直播营销的形式，在数字化变革中为消费者带来最直观的体验。

首先，在餐饮行业中，消费呈现出脉冲型特征，存在着明显的高峰期。这种波峰波谷的差异很大，主要集中在午餐和晚餐这两个用餐高峰时段。在这些时间段内，餐厅通常会迎来大量的顾客。

其次，餐饮业务具有交易敏感型特征，订单交易系统需要快速实时响应。顾客在现场点餐时，期望能够得到及时的消费响应，因此餐饮企业需要具备良好的灾备能力和快速响应机制。由于没有太多时间来进行服务器扩容等操作，餐饮行业在面对突发情况时需要迅速作出应对。

第三，餐饮业务是一项 24 小时不间断的服务业务，基本上不接受停服更新。餐饮企业需要保持持续的运营，确保顾客能够随时享受到美食。因此，在进行系统升级或更新时，餐饮企业需要采取一些特殊的措施，以确保业务的连续性。

第四，与金融、电信、科技等行业相比，餐饮业对于信息技术的投入相对较低。餐饮行业普遍面临资金有限的问题，无法像其他行业那样进行大规模的 IT 投资。这也意味着餐饮企业在信息化建设方面可能面临一些挑战，需要在有限的资源下进行合理的规划和选择。

最后，餐饮行业的信息化链条相对较长，涉及多个系统的对接和整合。餐饮企业通常需要应对大量异构系统的集成，使得各个环节能够无缝衔接。此外，餐饮行业还会面临大量临时性、一次性的紧急需求，例如各种节日促销活动。这些临时需求对系统的灵活性和快速响应能力提出了更高的要求。

综上所述，餐饮行业应根据以上五大特征，了解并应对这些特征对于餐饮企业的信息化、数字化建设和业务发展至关重要。

二、云函数的独特优势助力餐饮行业实现数字化

众所周知，云函数是一种无服务器（Serverless）概念的技术，在餐饮行业进行数字化转型中具有多项优势。首先，它实现了自动化弹性执行，根据使用量进行收费，并根据调用曲线自动扩缩容，以应对高峰期的服务压力。这种按需付费的模式不仅经济实惠，还能在闲时减少费用，提高系统稳定性和灾备能力。

其次，使用云函数可以摆脱繁琐的部署和配置过程，无需自己安装软件和配置服务器脚本。特别适用于临时的、低频的应用部署，可极大地节省服务器资源。而且在不使用时，无需额外销毁处理，进一步简化了管理流程。

云函数采用按需付费和毫秒级计费模式，永远不会在空闲时间产生费用。这对于脉冲式的访问业务具有明显的优势，并且可以针对低峰期和晚上的用量极低的情况进行优化，有效降低成本。

云函数支持高可用部署，它可以自动选择每个地域中的可用区来运行。如果某个可用区发生灾害或电力故障等导致瘫痪，云函数会自动切换到其他可用区的基础设施上运行，从而减少了单可用区运行的故障风险。这使得异地灾备的问题基本上不再需要考虑。同时，云函数还支持快速发布新版本和版本回退，实现了无感知的发版和版本回退。

最后，云函数的天然微服务模式使得每个函数都专注于某个特定的任务，通过相互协作可以构建复杂的应用程序。这种模块化的架构使开发者能够更灵活地管理和调整不同功能模块的资源消耗，实现快速迭代和部署。

在我看来，云函数是一种经济、实惠、稳定且灵活的技术，它能够根据实际需求自动弹性执行，节省资源，按需付费，并具备高可用性和灾备能力。

同时，它天然支持微服务模式，使开发者能够更灵活地构建和管理应用程序，实现快速迭代和部署。

三、乐凯撒餐饮高并发场景下的最佳实践

当前，国内的餐饮行业已经从增量市场转变为存量市场，在市场总额有限的情况下，在互联网、大数据等新一代信息技术迅猛发展的时代背景下，数字化成为帮助餐饮企业增加收入、降低成本、提升效率的重要工具。

毋庸置疑，餐饮收银 POS 系统作为餐饮门店最核心的业务系统，其中涉及大量实时交易的模块，例如订单、支付、打印、会员、优惠券等。我们乐凯撒用腾讯云函数最早做的是小程序的点单服务，后来逐渐扩大，到门店的云打印、会员标签的计算等等，总的来说包括独立应用、分布式计算和定时任务这三类业务。

在餐饮行业中，数字化系统的建构“效率”最为关键，这也正是乐凯撒选择携手腾讯云，借力腾讯云函数 SCF、消息队列 CMQ、TDSQL 等现有的成熟云产品的原因所在：不重复造轮子，通过好的工具有效实现降本增效，不断深化乐凯撒的数字化布局。

当前，我们基本上与腾讯云深度绑定，用的产品包括云函数 SCF、消息队列 CMQ、TDSQL、MySQL、COS 存储等。

其实，我们乐凯撒在正式使用云函数来支撑餐饮 POS 系统前，主要采用传统的 Java 体系的 J2EE 架构，通过部署不同的独立模块的系统来支撑门店的以上业务。

（图1，餐饮POS系统架构图）

其中我们乐凯撒的部分业务已经采用了云函数模式进行运行，而主要的 POS 业务和会员业务等仍然是通过各自独立的服务器集群进行部署。

然而，在去年 2 月份，我们乐凯撒遭遇了一次突发活动，这导致访问量急剧增加。在晚上 9 点多的时候，由于一个免费优惠券在社媒上传播，不到一个小时的时间内就有 18 万份优惠券被领取。这直接导致系统崩溃，并在接下来的几天里引发门店爆单、系统响应变慢等问题。

（图2，系统后台访问数据图）

如上图所示，我们乐凯撒遭遇了一次访问量剧增，整体访问量增加了 20 倍。这导致我们的 POS 收银系统无法承受，最终不得不停止服务。

在进行系统复盘后，我们提出了两个解决方案：

● 方案一：增加服务器资源，加强服务器灾备能力，并实现快速自动化部署脚本以便对服务器集群进行扩容。然而，这个方案需要额外的服务器预算，并且大部分时间服务器资源处于闲置状态，同时也增加了运维的复杂性。

● 方案二：采用云函数来实现和部署这类脉冲型业务，无需额外采购服务器，也无需进行大规模的扩容和相应的运维工作。然而，这需要对现有业务进行重构和调整，以适应云函数架构。

经过综合考虑，我们最终确定了方案二，将优惠券服务、订单服务和菜单服务从现有系统中分离出来，采用云函数进行单独运行和部署。这样能够更好地适应脉冲型业务的需求。

调整后的架构图如下：

（图3，调整后的系统架构图）

通过将订单服务和优惠券服务转换为云函数架构，我们显著提升了系统的整体稳定性。几乎没有发生系统崩溃或响应过慢等问题，并且我们几乎没有增加服务器预算的成本。

然而，在 2024 年 2 月份，我们乐凯撒遇到了两次类似的业务激增情况。一次是在 2 月 21 日，访问量接近 20 万次；另一次是在 2 月 23 日，访问量接近 40 万次。然而，我们的系统在这些情况下都能平稳运行下去。有趣的是，我甚至是通过门店爆单的情况才了解到访问量的剧增。

与此类似，我们的支付服务和打印服务一直采用云函数模式运行，并且从 2018 年上线至今几乎没有遇到过压力过载的故障。其中，我们的打印服务是访问量最高的服务，平时每分钟处理接近 4000 次请求，采用了 WebSocket 通信协议。

总而言之，通过将关键服务转换为云函数架构，我们不仅提高了系统的稳定性，还能应对突发的业务激增情况。支付服务和打印服务作为长期采用云函数模式运行的示范，也展示了它们在处理高访问量时的出色表现。

（图4，系统访问趋势图）

在这个案例中，我们乐凯撒采用了云函数的自动扩缩容、按需付费、高可用和微服务化的模式，以解决业务需求。在进行云函数改造的过程中，我们总结了一些问题：

● 相对于其他语言，云函数对 Java 的支持较弱。由于我们的大型或复杂业务系统主要使用 Java 实现，早期上线的支付服务和打印服务采用了 Node.js，因此上线相对顺利，稳定性和体验都比较好。但要使 Java 应用在云函数上更好地使用，需要付出更多努力。

● 纯 Java 语言的功能相对有限，为了高效开发，通常需要依赖开源框架，尤其是 Spring。

● Java 启动慢，内存占用大，与其他语言相比，在 Serverless 云函数下会占用更多资源。对于复杂业务系统，每个接口部署一个云函数会增加部署和管理成本。

● Java 应用涉及数据库请求时，通常会使用数据库连接池进行管理。然而，在云函数中，连接池不能设置得太大，最好在 3-5 个之间，否则会导致数据库连接数过高。由于云函数是为每个请求开启一个类似 Java 进程的服务，当并发量较大时，云函数会创建大量的 Java 进程，进而导致数据库连接数过高。

● 迁移现有业务代码至云函数时，需要尽量减少修改，实现无缝迁移，并支持本地调试和模拟云端环境，但目前还没有较好的解决方案。

为了解决上述问题，我们乐凯撒自研了一套兼容云函数和 SpringBoot 这两种模式都能正常运行的框架。该框架支持在本地调试和测试环境下直接使用 Spring Boot 或 Tomcat 启动，而在正式环境中则直接采用云函数运行。此外，该框架还支持一个云函数部署多个访问接口的服务，使云函数能够按模块划分微服务。

我们已经将该框架开源，并在 GitHub 上发布了一个简单的订单服务 demo 样例，感兴趣的朋友可以自行前往查看：（《基于腾讯云函数部署的springboot》：https://github.com/lacesarLabs/tencentyun-scf-springboot）

其实，如果要广泛应用云函数，我们必须面对一个必须解决的问题，即大规模应用 Java 语言的云函数化。由于许多商业软件和复杂应用都是使用 Java 实现的，我们需要一个能够与 Spring Cloud 等微服务生态系统媲美的云函数框架，以及云函数调用的框架或平台，以更好地替换和升级现有的 Java 应用。这个框架应该支持基于云函数的函数注册、函数管理、函数调度和函数发现等配套功能。

在这个案例中，我们乐凯撒通过这个框架成功地将相关服务快速迁移到云函数上。最初，我们将云函数视为灾备和临时扩容服务，但在测试运行后，发现其稳定性和性能表现出色，于是将其作为正式环境的服务，而虚拟机中的服务则成为备份。

其实，整个解决方案的成本只占了方案一所需的正常服务器资源费用的不到 10%。在这个方案中，我们完美应用了云函数的几个重要特性：自动扩缩容、按需付费、天然的微服务模式以及高可用和无服务器概念。