{"componentChunkName":"component---src-templates-best-practice-detail-tsx","path":"/best-practice/2021-01-12-lacesar","result":{"data":{"currentBlog":{"id":"7b4f03ab-952b-54c1-969a-54543aef68a8","frontmatter":{"thumbnail":"https://main.qcloudimg.com/raw/6f783dfe4d7c1d441e71cc51bebc7090.jpg","authors":["黄道泳"],"categories":["best-practice"],"date":"2021-01-12T00:00:00.000Z","title":"Serveless 助力新零售 —— 乐凯撒新餐饮服务落地实践","description":"云打印服务、会员画像系统、智能营业额预测应用案例分享","authorslink":null,"translators":null,"translatorslink":null,"tags":["Serverless","客户案例"],"keywords":null,"outdated":null},"wordCount":{"words":554,"sentences":106,"paragraphs":106},"fileAbsolutePath":"/opt/build/repo/content/best-practice/2021-01-12-lacesar.md","fields":{"slug":"/best-practice/2021-01-12-lacesar/","keywords":["serverless","云函数","函数","系统","Serverless","数据"]},"html":"

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

\n

\n

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

\n

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

\n

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

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

\n

\n

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

\n

\n

应用背景

\n

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

\n

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

\n

\n

新餐饮介绍

\n

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

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

\n

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

\n

云函数调用方式

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

前面四种我们都用到了。

\n

\n

乐凯撒应用 Serverless 的业务概况

\n

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

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

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

\n

\n

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

\n

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

\n

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

\n

定时任务管理， Nodejs 和 Java 都用；

\n

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

\n

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

\n

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

\n

\n

Serverless 解决的问题和痛点

\n

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

\n

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

\n

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

\n

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

\n

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

\n

\n

这里，我分享几个应用场景的案例：

\n

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

\n

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

\n

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

\n

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

\n

\n

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

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

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

\n

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

\n

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

\n

\n

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

\n

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

\n

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

\n

这个过程如何实现？

\n

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

\n

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

\n

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

\n

\n

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

\n

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

\n

第一、智能销售

\n

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

\n

第二、订货

\n

第三、人员的排班

\n

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

\n

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

\n

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

\n

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

\n

\n

云函数的价值

\n

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

\n

1、云打印服务

\n\n

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

\n\n

\n

3、智能营业额预测

\n\n

\n

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

\n

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

\n

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

\n

\n

未来的规划

\n

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

\n

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

\n

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

\n

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

\n

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

\n

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

\n

\n

一些挑战和注意事项

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

\n

今天我就分享这么多，谢谢大家！

\n

\n
\n

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

","tableOfContents":""},"previousBlog":{"id":"246a3099-2bf9-54f8-9182-0156347330e7","frontmatter":{"thumbnail":"https://main.qcloudimg.com/raw/2e90a9a7efa86ed3e180d4628ba5fbea.jpg","authors":["Barrie"],"categories":["best-practice"],"date":"2021-01-14T00:00:00.000Z","title":"输入几行代码，轻松迁移 SpringBoot 应用上云","description":"快来体验一下吧！","authorslink":null,"translators":null,"translatorslink":null,"tags":["Serverless","SpringBoot"],"keywords":null,"outdated":null},"wordCount":{"words":289,"sentences":42,"paragraphs":42},"fileAbsolutePath":"/opt/build/repo/content/best-practice/2021-01-14-serverless-springboot.md","fields":{"slug":"/best-practice/2021-01-14-serverless-springboot/","keywords":["go","java","serverless","ssr","云函数","应用","部署","Serverless","创建","控制台","tencent"]}},"nextBlog":{"id":"829120a2-4f13-50a8-a876-9ffe985c3f26","frontmatter":{"thumbnail":"https://main.qcloudimg.com/raw/0693730f68cc5d3b3a9398bb02b863dc.jpg","authors":["susu"],"categories":["best-practice"],"date":"2021-01-11T00:00:00.000Z","title":"Serverless 音视频转码 —— 芒果 TV 落地实践（下）","description":"实现音视频转码服务的详细操作步骤，两种方案任你选！","authorslink":null,"translators":null,"translatorslink":null,"tags":["Serverless","转码"],"keywords":null,"outdated":null},"wordCount":{"words":368,"sentences":79,"paragraphs":79},"fileAbsolutePath":"/opt/build/repo/content/best-practice/2021-01-11-serverless-mangguo2.md","fields":{"slug":"/best-practice/2021-01-11-serverless-mangguo2/","keywords":["go","serverless","云函数","日志","转码","函数","transcode","配置","tencent","异步"]}}},"pageContext":{"isCreatedByStatefulCreatePages":false,"blogId":"7b4f03ab-952b-54c1-969a-54543aef68a8","previousBlogId":"246a3099-2bf9-54f8-9182-0156347330e7","nextBlogId":"829120a2-4f13-50a8-a876-9ffe985c3f26"}}}