本文整理自乐凯撒黄道泳在 Techo 大会的分享，文字部分约 5100 字。
下面，让我们一起回顾下黄老师在 Techo 大会的精彩演讲内容：
大家好！我是黄道泳。非常荣幸收到腾讯云的邀请，来给大家介绍一下腾讯云 Serverless 在乐凯撒新餐饮服务上的应用实践。
乐凯撒是一个披萨的餐饮门店，目前在深圳、广州、上海、苏州、佛山、惠州、东莞、昆明、重庆等地拥有140多家直营门店。乐凯撒是红山资本成员企业，是红杉资本在中国投资的第一家餐饮企业。11年首创了榴莲比萨，现已风靡全国。
今天分享四部分，第一部分讲一下 Serverless 的应用背景。第二部分是关于我们用 Serverless 做了什么，第三部分我会分享下 Serverless 解决了业务上哪些痛点，第四部分讲一下未来在Serverless 应用上的发展规划，以及Serverless 使用过程中有哪些挑战和注意事项。
应用背景
先看一下我们当时的应用背景。我们开始决定使用 Serverless 来做我们系统升级改造的时候，是在2017年的时候，当时我们业务系统信息孤岛严重，有二次开发困难，大量用户用的系统语言和接口都不一样。
17年底，我们做了我们自己的小程序点餐系统，这个系统本身需要和后台业务系统打通，这个时候需要解决多个系统之间的互联互通问题。另外就是业务系统耦合度高，业务拆分困难，系统稳定性差，各种紧急的业务需求和活动无法及时满足。所以我们尝试先通过 Serverless 做一些局部的改造。
新餐饮介绍
首先讲一下我们对新餐饮的思考，它在信息化数字化的要求，新餐饮本身也是人货场的重构，主要实现我们日常经营管理所有的数据能够全流程在线化，主要分为四块：
- 点餐、下单、支付、制作、出品实现实时在线化。
- 用餐评价，会员管理可以在线化，支持数字化营销。
- 供应链订货、收获、盘点、损耗在流程在线，数据打通。
- 人事、考勤、成本核算等在线化，工具化，高效化。这些方面是我们新餐饮转型在这方面要进行全方面的数字化改造。
下图是我们以前建成的系统的架构图，我们现在的系统就是在这个基础上进行完善的。中间是业务中台，对接很多第三方系统，小系统包括我们云打印系统、点餐系统、会员系统、配送系统、开店管理系统，还有第三方系统，比如说金蝶ERP系统、红海EHR系统，第三方系统又会产生数据交互。
云函数调用方式
- API网关提供http接口
- 定时触发。做一些定时数据处理，定时数据计算等等。
- 运用Websocket实时通讯，我们目前应用在云打印这一块，用来做实时打印通讯和打印机的管理。
- CMQ消息订阅触发。我们会把它用在会员计算这块。
- COS存储触发
- CKafka数据的处理。
前面四种我们都用到了。
乐凯撒应用 Serverless 的业务概况
我们用云函数实现的业务功能非常多。
- 微信小程序的服务应用，基于云函数实现的，而且目前腾讯云也支持云开发。
- 公众号消息推送服务。
- 实时通讯服务，刚才讲的云打印服务。
- 不同的业务系统数据同步，比如说金蝶的ERP系统以及WMS系统的对接和数据同步，SOS餐饮系统和金蝶ERP数据接口的同步。
- 统一的支付服务，订单的付款，订单的支付，定时异常数据邮件提醒。
- 第三方外卖平台、第三方系统的数据抽取及处理入库。需要临时上线的功能需求或接口对接。我们做完之后，直接可以不管它了。
以上都是用 Serverless 平台实现的。
云函数的应用场景及编程语言
我们常用云函数的应用场景及编程语言有多种，一般来说，
对接不同系统接口的应用用 Nodejs；
定时任务管理， Nodejs 和 Java 都用；
数据抽取、数据运算、数据同步用Nodejs 和 Python；
各类临时活动，做完就下架，用Nodejs 。
机器学习应用可以用Python。目前Nodejs 和Python比较多，Java 用的偏少。
Serverless 解决的问题和痛点
首先，Serverless 云函数它是天然微服务的架构，它本身是函数一个服务，它是微服务，我们看成是微服务的升级版，第4代架构，是云微服务版。本身微服务能解决很多，数据耦合度的问题。
第二，适合处理大量零散的定时任务，比如说我们可以极大的减少服务，减少部署独立的定时器服务，解决集群服务的定时任务管理的问题。尤其是并发的集群的定制任务。
第三，更低的开发难度，更高的开发效率，因为现成的资源可以直接用。针对不同的业务场景，可以借助不同语言特性，结合研发团队的能力，更快速的实现对应的需求。利用他们熟悉的语言，去做业务场景，而不是需要大家统一的技术架构。他们可以很灵活快速推进这个需求。
最后，运维成本。因为云函数有一个很强的特征，不运行则不产生费用。第二个不产生资源的占比，没有多大服务器的成本。另外扩容也是全自动的。它的运维成本很低。
早期，我们用云函数来做多个业务系统之间的对接，尤其是解决多个异构系统之间的数据连通，因为我们整个系统的重构不是一天就能完成的，是慢慢去做的，慢慢不断的反复，不断的去调整这些功能。一步一步慢慢去做，多个异构系统的黏合剂。
这里，我分享几个应用场景的案例：
应用案例：云打印服务——传统架构
首先，我介绍下用来解决云打印服务，这是一个打印的小系统。用来解决门店在下单之后，我们打印机打印小票。首先说一下传统架构的实现。
在传统的架构里，每一个门店都会有一个本地的服务器，这个本地的服务器会提供一个本地服务，我们门店需要有一个交银机，一个一体机，还有打印机，通过本地服务器进行管控。总部也需要有服务，总部进行数据的整合，例如：美团的订单，会先把订单下到总部的服务器上，总部服务器把这个数据推送到门店，门店服务器接到数据之后，它才能够通知到打印机进行打印小票，由此来完成整个门店业务的管理。
现在，基本上有大量的订单是线上下单，不管是小程序的订单也好，还是美团饿了么也好，都是通过网上下单，存在网络链路的问题。网络一断就不好办了。
我总结下传统架构存在以下痛点：
- 硬件及维护成本非常高。门店需要部署独立的本地服务器。
- 总部对于门店的服务情况无法快速掌控，因为这个数据每隔一段时间才会通讯，很难做到实时把数据同步下来。
- 我们收银电脑普遍配置极低，订单数据无法实时上传汇总，门店下单和美团总部接到的单是错位的，需要一段时间才能同步。
应用案例：云打印服务——新的云服务架构
新的架构是云服务架构，取消了本地服务器，无需门店本地部署服务器。在比较低端配置的收银电脑或 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%。这样的情况下，云函数参数会有比较大的优点在你峰值低的时候，会降到很低的成本。你的费用是按照运行次数和时间和运行内存来综合计算的。
最后，继续加强机器学习和大数据分析方面的云函数应用。包括明年会计划去做这个事情，能不能搞人脸识别的库，和图片识别，去做图像识别的应用，包括用户特征这一块。这个是我们的规划。
一些挑战和注意事项
- 工程化、模块化管理不便。其实是微服务共性的问题，微服务开的够多够细，需要我们做好规划。
- 云函数本身机制的问题，第一次运行或者函数长期未运行时，或者再次发出调用的时候，会有一个启动时间，比如说5到10秒，看你的启动资源花多少，启动慢的话会一秒两秒，可能造成接口会延时。调用方面要考虑。
- 本地化调试的不便问题。本地运行的代码到云函数上跟我想象中的不一样，尤其是Java 函数有比较大的区别。目前我们自己也做了类似的框架。本地它是一个开发，远端入口是基于打包。出来的结果是不一样的。近期云函数发布了在线调试功能，感兴趣的朋友可以尝试。
- 公共类库的复用问题。这个问题用 Python 语言可以解决。Java 问题类库不大好解决。Java 类库有重复引用，我们看到这一块，看看有没有更好的解决方案。
- 跨区域的网络稳定性引发的云服务灾备问题。这个是什么意思呢？这个也是我们过往产生过的，我们云服务部署按区部署，你在广州部署，在北京部署，在上海部署，是不能够跨区域的。如果这个区域的网络，如果一旦发生问题，你可能会导致云服务没法正常用。这个时候需要快速的灾备方案。目前我们在上海有一套，如果网络出现问题，快速切换，这样一定程度去避免问题。目前还没有全国性的切换。
- 在做云函数开发的时候，我们曾经犯过一个很严重的错误，因为我们一直以为云函数资源自己管理就好了，用完了就关了，这个不一定的。尤其涉及到数据库资源，云函数里面的链接，就是你自己开了一定要关，如果不关的话，有可能导致链接池，最终导致数据库崩溃。云函数刚开始做的时候，大家会忽略。我们一定要自己管理链接。这个是我们在使用过程中遇到的问题和挑战。
今天我就分享这么多，谢谢大家！
One More Thing
立即体验腾讯云 Serverless Demo，领取 Serverless 新用户礼包 👉 serverless/start
欢迎访问：Serverless 中文网！
