Serveless 助力新零售 —— 乐凯撒新餐饮服务落地实践

作者:
发布于: 2021-1-12
归档于:

标签:Serverless客户案例

本文整理自乐凯撒黄道泳在 Techo 大会的分享,文字部分约 5100 字。

下面,让我们一起回顾下黄老师在 Techo 大会的精彩演讲内容:

大家好!我是黄道泳。非常荣幸收到腾讯云的邀请,来给大家介绍一下腾讯云 Serverless 在乐凯撒新餐饮服务上的应用实践。

原文分享:黄道泳  
整理编辑:王天云  李永程

乐凯撒是一个披萨的餐饮门店,目前在深圳、广州、上海、苏州、佛山、惠州、东莞、昆明、重庆等地拥有140多家直营门店。乐凯撒是红山资本成员企业,是红杉资本在中国投资的第一家餐饮企业。11年首创了榴莲比萨,现已风靡全国。

今天分享四部分,第一部分讲一下 Serverless 的应用背景。第二部分是关于我们用 Serverless 做了什么,第三部分我会分享下 Serverless 解决了业务上哪些痛点,第四部分讲一下未来在Serverless 应用上的发展规划,以及Serverless 使用过程中有哪些挑战和注意事项。

应用背景

先看一下我们当时的应用背景。我们开始决定使用 Serverless 来做我们系统升级改造的时候,是在2017年的时候,当时我们业务系统信息孤岛严重,有二次开发困难,大量用户用的系统语言和接口都不一样。

17年底,我们做了我们自己的小程序点餐系统,这个系统本身需要和后台业务系统打通,这个时候需要解决多个系统之间的互联互通问题。另外就是业务系统耦合度高,业务拆分困难,系统稳定性差,各种紧急的业务需求和活动无法及时满足。所以我们尝试先通过 Serverless 做一些局部的改造。

新餐饮介绍

首先讲一下我们对新餐饮的思考,它在信息化数字化的要求,新餐饮本身也是人货场的重构,主要实现我们日常经营管理所有的数据能够全流程在线化,主要分为四块:

  1. 点餐、下单、支付、制作、出品实现实时在线化。
  2. 用餐评价,会员管理可以在线化,支持数字化营销。
  3. 供应链订货、收获、盘点、损耗在流程在线,数据打通。
  4. 人事、考勤、成本核算等在线化,工具化,高效化。这些方面是我们新餐饮转型在这方面要进行全方面的数字化改造。

下图是我们以前建成的系统的架构图,我们现在的系统就是在这个基础上进行完善的。中间是业务中台,对接很多第三方系统,小系统包括我们云打印系统、点餐系统、会员系统、配送系统、开店管理系统,还有第三方系统,比如说金蝶ERP系统、红海EHR系统,第三方系统又会产生数据交互。

云函数调用方式

  1. API网关提供http接口
  2. 定时触发。做一些定时数据处理,定时数据计算等等。
  3. 运用Websocket实时通讯,我们目前应用在云打印这一块,用来做实时打印通讯和打印机的管理。
  4. CMQ消息订阅触发。我们会把它用在会员计算这块。
  5. COS存储触发
  6. CKafka数据的处理。

前面四种我们都用到了。

乐凯撒应用 Serverless 的业务概况

我们用云函数实现的业务功能非常多。

  1. 微信小程序的服务应用,基于云函数实现的,而且目前腾讯云也支持云开发。
  2. 公众号消息推送服务。
  3. 实时通讯服务,刚才讲的云打印服务。
  4. 不同的业务系统数据同步,比如说金蝶的ERP系统以及WMS系统的对接和数据同步,SOS餐饮系统和金蝶ERP数据接口的同步。
  5. 统一的支付服务,订单的付款,订单的支付,定时异常数据邮件提醒。
  6. 第三方外卖平台、第三方系统的数据抽取及处理入库。需要临时上线的功能需求或接口对接。我们做完之后,直接可以不管它了。

以上都是用 Serverless 平台实现的。

云函数的应用场景及编程语言

我们常用云函数的应用场景及编程语言有多种,一般来说,

对接不同系统接口的应用用 Nodejs;

定时任务管理, Nodejs 和 Java 都用;

数据抽取、数据运算、数据同步用Nodejs 和 Python;

各类临时活动,做完就下架,用Nodejs 。

机器学习应用可以用Python。目前Nodejs 和Python比较多,Java 用的偏少。

Serverless 解决的问题和痛点

首先,Serverless 云函数它是天然微服务的架构,它本身是函数一个服务,它是微服务,我们看成是微服务的升级版,第4代架构,是云微服务版。本身微服务能解决很多,数据耦合度的问题。

第二,适合处理大量零散的定时任务,比如说我们可以极大的减少服务,减少部署独立的定时器服务,解决集群服务的定时任务管理的问题。尤其是并发的集群的定制任务。

第三,更低的开发难度,更高的开发效率,因为现成的资源可以直接用。针对不同的业务场景,可以借助不同语言特性,结合研发团队的能力,更快速的实现对应的需求。利用他们熟悉的语言,去做业务场景,而不是需要大家统一的技术架构。他们可以很灵活快速推进这个需求。

最后,运维成本。因为云函数有一个很强的特征,不运行则不产生费用。第二个不产生资源的占比,没有多大服务器的成本。另外扩容也是全自动的。它的运维成本很低。

早期,我们用云函数来做多个业务系统之间的对接,尤其是解决多个异构系统之间的数据连通,因为我们整个系统的重构不是一天就能完成的,是慢慢去做的,慢慢不断的反复,不断的去调整这些功能。一步一步慢慢去做,多个异构系统的黏合剂。

这里,我分享几个应用场景的案例:

应用案例:云打印服务——传统架构

首先,我介绍下用来解决云打印服务,这是一个打印的小系统。用来解决门店在下单之后,我们打印机打印小票。首先说一下传统架构的实现。

在传统的架构里,每一个门店都会有一个本地的服务器,这个本地的服务器会提供一个本地服务,我们门店需要有一个交银机,一个一体机,还有打印机,通过本地服务器进行管控。总部也需要有服务,总部进行数据的整合,例如:美团的订单,会先把订单下到总部的服务器上,总部服务器把这个数据推送到门店,门店服务器接到数据之后,它才能够通知到打印机进行打印小票,由此来完成整个门店业务的管理。

现在,基本上有大量的订单是线上下单,不管是小程序的订单也好,还是美团饿了么也好,都是通过网上下单,存在网络链路的问题。网络一断就不好办了。

我总结下传统架构存在以下痛点:

  1. 硬件及维护成本非常高。门店需要部署独立的本地服务器。
  2. 总部对于门店的服务情况无法快速掌控,因为这个数据每隔一段时间才会通讯,很难做到实时把数据同步下来。
  3. 我们收银电脑普遍配置极低,订单数据无法实时上传汇总,门店下单和美团总部接到的单是错位的,需要一段时间才能同步。

应用案例:云打印服务——新的云服务架构

新的架构是云服务架构,取消了本地服务器,无需门店本地部署服务器。在比较低端配置的收银电脑或 SDK 上部署轻量级客户端。

打开浏览器,就可以实时传回所有订单数据,可以追踪你所有的服务状态。打印机它是在门店的局域网内部,所以我们单独在我们云端的服务,就是我们SOS收银系统,还有云打印服务仍然实现云打印服务,通过它连接我们本地的收银机客户端,由它来定制我们的打印机,它是实时通讯的,随时知道门店的打印机是否能正常打印,是不是卡纸,是不是纸打完了,没有纸了,我们随时都可以知道。这个过程就解决了门店很多问题,由于订单是可追踪的,打印机会随时把故障解决。

应用案例:会员画像标签运算系统

第二个案例,我们用云函数结合 CMQ ,结合 API 网关,完成会员画像标签运算系统。

我们做会员系统,一般来说会员比较重要的一项数据要生成,就是会员画像,我们要基于会员消费行为消费轨迹生成用户会员它的画像,会员的爱好、消费频率、消费的档次等等。我们希望能够快速实时的跟踪这些数据,通过平台可以用极低的成本完成整个过程。

这个过程如何实现?

第一步,用户产生购买消费行为数据推送到我们柜员系统,通过消费订单产生统计数据。这个数据统计完之后,把数据装到数据库。因为它的消费是正常的,是正常订单的数据。我们会对信息推送到消息队列里面,我们 CMQ 会调用我们 API 网关,API 网关后面对接的是云函数。

Serverless 云函数,每一个云函数会对应一类标签,包括消费频次,消费偏好等等标签,这类云函数对它进行标签的实时运算,如果计算过程中产生错误,会把这个消息反馈给CMQ,CMQ告诉消费失败,如果正常的话,会拉取数据,拉取完之后标签计算,标签计算完成之后,我们会把标签保存入库,最终生成用户画像,最终消费成功,整个标签计算完成,整个消费完成。通过这样的方式,我们完成了整个会员画像实时计算系统。

我们目前这个系统从19年上半年的时候开始做,到现在为止,整个会员画像的标签有3000多万。

应用案例:智能营业额预测

第三个案例,我们今年做的,在云函数上使用机器学习的一个实践,我们可以做的智能化:

第一、智能销售

通过分层管理通过大量的集成学习,放到数据库,调取我们的数据库,进行云计算。

第二、订货

第三、人员的排班

以营业额预测为例,具体我们是怎么做的?拉取近两年门店的营业额,最长拉两年,没有两年也可以拉,最少是一到两个月。通过这个数据,我们生成每一家门店接下来 30 天的营业额,这是每天滚动生成的机器学习的过程。

首先,我们先会抽取数据处理,对我们营业额的数据做抽取,做相关的异常处理。

其次,我们会生成训练特征,为我们数据组合特征。

第三,我们会定期训练模型,会使用LightGBM模型训练多个模型,然后是多个模型预测数据加权融合,然后使用已有模型集预测数据特征值预测数据,我们不是每天都训练,一般两周到一个月做一次训练,整个代码都是在数据库上面,没有分开去做。很边界的实现营业预测。到目前我们运行下来有接近半年的时间,我们目前营业额,单店平均准确度到达87%,这个准确度蛮高的。

云函数的价值

这三个项目中云函数主要价值点是什么呢?

1、云打印服务

  • 通过使用腾讯云提供的Websocke服务,减少了地层框架的开发难度,使得研发人员只要关注业务开发即可。
  • 一个人大概花2周多时间就搞定了,人力和时间成本节省至少50%。

2、会员画像标签运算系统

  • 通过使用CMQ,API网关和云函数快速搭建起来一个高质量稳定的计算服务架构。目前我们从上线运行到现在,还没出过问题。基本上你不需要考虑太多你的服务器资源的问题,唯一的问题是你的数据库面临比较大的压力。
  • 一个中级的研发工程师三年的经验,从研究使用到搭建框架到开发完成不到 2 周时间。

3、智能营业额预测

  • 通过使用函数的分层管理,减少了代码的管理和调试的难度。
  • 用较低的成本和更高的效率实现了机器学习的智能应用。

服务运维及成本、服务稳定性和性能都有较好的保障,而且费用投入远低于自建服务的方式,至少节省了3台4核8G内存的服务器。

开发周期上面传统是百分之百,云函数是55%。研发难度传统是百分之百,云函数是45%。

成本的话传统是百分之百,云函数只有30%。类似定时器这种,可能有10%。定时器一天也就跑三五次。但是很高配的服务器,长期占用的话,这个成本是消不掉的。

未来的规划

第一、强化Java体系云函数的应用。

我们刚才看到比较多的是 Python ,我们真正大型的系统还是以 Java 为主,我们这块希望做很深度的应用,我们希望结合 springboot,强化Java云函数能力,实现既能本地调试,又能方便的进行云函数部署。

第二、对于多个云函数定时器提供统一调度和管理功能应用能力。

第三、结合其他的资源,如果只用云函数,只能发挥里面百分之四五十的功能,结合其他的资源后你就会发现整体效率,包括你的成本节省会非常多。

刚才提到的CMQ、COS、LB负载均衡用起来,你会发现极大的降低其他综合流程,整个研发效率都会有比较大的提升。包括我们系统稳定性,基本上扩容这个事情,绝大部分都不需要考虑。一般我们在建系统的时候,你要考虑的是你的各个系统,你的峰值。80%的时间,你的CPU只有10%或者是1%。这样的情况下,云函数参数会有比较大的优点在你峰值低的时候,会降到很低的成本。你的费用是按照运行次数和时间和运行内存来综合计算的。

最后,继续加强机器学习和大数据分析方面的云函数应用。包括明年会计划去做这个事情,能不能搞人脸识别的库,和图片识别,去做图像识别的应用,包括用户特征这一块。这个是我们的规划。

一些挑战和注意事项

  1. 工程化、模块化管理不便。其实是微服务共性的问题,微服务开的够多够细,需要我们做好规划。
  2. 云函数本身机制的问题,第一次运行或者函数长期未运行时,或者再次发出调用的时候,会有一个启动时间,比如说5到10秒,看你的启动资源花多少,启动慢的话会一秒两秒,可能造成接口会延时。调用方面要考虑。
  3. 本地化调试的不便问题。本地运行的代码到云函数上跟我想象中的不一样,尤其是Java 函数有比较大的区别。目前我们自己也做了类似的框架。本地它是一个开发,远端入口是基于打包。出来的结果是不一样的。近期云函数发布了在线调试功能,感兴趣的朋友可以尝试。
  4. 公共类库的复用问题。这个问题用 Python 语言可以解决。Java 问题类库不大好解决。Java 类库有重复引用,我们看到这一块,看看有没有更好的解决方案。
  5. 跨区域的网络稳定性引发的云服务灾备问题。这个是什么意思呢?这个也是我们过往产生过的,我们云服务部署按区部署,你在广州部署,在北京部署,在上海部署,是不能够跨区域的。如果这个区域的网络,如果一旦发生问题,你可能会导致云服务没法正常用。这个时候需要快速的灾备方案。目前我们在上海有一套,如果网络出现问题,快速切换,这样一定程度去避免问题。目前还没有全国性的切换。
  6. 在做云函数开发的时候,我们曾经犯过一个很严重的错误,因为我们一直以为云函数资源自己管理就好了,用完了就关了,这个不一定的。尤其涉及到数据库资源,云函数里面的链接,就是你自己开了一定要关,如果不关的话,有可能导致链接池,最终导致数据库崩溃。云函数刚开始做的时候,大家会忽略。我们一定要自己管理链接。这个是我们在使用过程中遇到的问题和挑战。

今天我就分享这么多,谢谢大家!


欢迎访问:Serverless 中文网,您可以在 最佳实践 里体验更多关于 Serverless 应用的开发!