专访乐凯撒CTO黄道泳：看一盒披萨背后的技术之路

关注

原创 2022-11-03 18:57:23 1k 阅读 AI 写同款· GEO 优化 ›

当一盒热腾腾的披萨端到你的面前，你是否想过，背后会有怎样一段耐人寻味的技术故事？一块“数字化”披萨是如何诞生的？一家餐饮企业又是怎样做到核心系统完全自研？带着这些问题，TVP技术指针栏目，专访乐凯撒 CTO、腾讯云TVP 黄道泳老师，和他一起探寻一盒披萨背后的技术之路。

一、意外结缘，却打造没有边界的IT团队

乐凯撒，除了大家所熟知的榴莲披萨开创者，它也是餐饮业内少有的投入千万元构建数字化生态系统，实现核心业务系统完全自研的企业。作为这个“没有边界的”自研 IT 团队的掌舵人，乐凯撒 CTO、腾讯云 TVP 黄道泳老师谈及加入乐凯撒时，却直言“真的是个意外”。

其实我从来没有想过要加入一家餐饮企业。我是 2005 年毕业于电子科技大学。迄今为止工作快有 17 年了，前 10 年基本上都在做电子政务、ERP 等 To B 的企业级应用产品或项目的开发。加入乐凯撒后，才正式开始去做面向大众消费的业务。当时加入真的是个意外，我们的创始人陈宁（饼哥）和我是同一届的同学，毕业十周年庆的时候机缘巧合下的一次聊天，饼哥就邀请我过来参与这个事业，过去我在乙方的工作一直是帮别人做信息化系统，就像帮别人养孩子，不如加入甲方企业，自己来养这个孩子。

和 To B 或 To G 按时交付的单一任务型业务不同，在甲方企业最大的差异就是需求永远在变，所以我向团队传达的理念是“唯一不变的就是需求在变”，首先要接受并适应需求变化的存在；同时，在做技术设计、实现时要预先考虑到需求变化可能产生的影响，保持高度的兼容性。

乐凯撒的IT团队在餐饮界里面算是少有的，大部分系统都是自研的团队，自研团队相当于是“没有边界”的：企业需要什么，团队就做什么。目前像 POS、收银、会员等核心系统都是我们自研的。另外我们还做了一个门店的盒子，一方面实现低能耗，一方面也可以作为今后边缘计算的节点，以及智能门店和智能设备的接入口。它属于工业级的工控盒子，功耗很低，大概只有市面上收银机的 20% 左右，1 家门店 1 年省下来的电费可以有 500～1000 元，节省下了一笔不小的成本。

二、疫情危机，成为修炼内功的最好时机

从门店盒子的降本，到核心系统自研的提效，黄道泳老师在采访的诸多细节中，都展现了作为 CTO，对业务的高度关注与敏锐洞察。这也与餐饮行业所历经的疫情寒冬密切相关，对于黄道泳老师和他的团队而言，疫情是危机，同时也是迎难而上，修炼“数字化内功”的最佳时机。

疫情确实对整个餐饮行业都带来了很大的冲击，目前能够扛住风险的可能也只有上了一定规模的企业，比如乐凯撒这种自营的连锁企业。从内控的角度讲，需要有比较强的精细化管理的能力，包括供应链管理、成本管理、商务谈判能力等。另外，是要想方设法提升增长，基本上是通过扩大外卖在整个营收盘子中的占比，可以和外卖平台去要资源做一些推广活动，并且加大私域流量的建设。

面对疫情，风险和机遇是并存的。大家难的时候不是只是我一家难，是每一家都难，那在这个时候如果你能够解决这个难点，那就能得到很好的发展。因为从商业机会上来说，现在有大量的店铺倒闭空出来，只要你能接得住，你就能把这个困难变成一个机遇，但是你也不能跑崩了，忽略了对风险的预估。

有很多企业是一出问题就全盘皆崩了，因为它的内功没有修炼好。这在上升期往往是很难看出来的，但寒冬一来，企业的内功修炼程度就很显而易见了。如果这家企业在每一个环节都管理到位，并且都通过系统互联互通，那么出问题的时候也很容易去发现和定位。但实际上很多企业是只能看到账上还剩多少钱，至于它为什么还剩这么多钱，却可能算不清楚，问题出在哪里也并不了解，直到崩盘了才知道挂了。

其实不仅仅是餐饮企业，所有企业基本上都会经历信息化、数据化和智能化三个阶段。信息化、数据化和智能化不是一个阶梯式发展的过程，而是一个交叉进行的过程。信息化，指的是业务能够在线上流通，也就是实现无纸化。在这个基础之上，再去做数据分析、报告、决策等一系列的数据化工作，所以我们说数据化是在信息化建设到一定程度之后产生的结果。而智能化则是在信息化运行了较长时间后，数据有了一定的积累，基本业务流程可以进行规律预测时，就可以考虑去做智能化。智能化里还包含了自动化，一个是减少人的经验依赖，另一个是减少人之间的交互互动，也就是尽量把业务变成系统可以自动跑完，人只在几个关键节点参与即可。

目前乐凯撒基本完成了信息化建设，数据化的应用达到 70%，实现了所有的核心业务在线化，并且 90% 数据相关的追踪和报表，都已经摆脱了手工做表、手工做统计、手工出 PPT。我们智能化的应用程度在 25%，主要是在成本管控方面，是以营业额预测为基础，产生销量预测、排班预测、订货预测，从而让门店实现合理排班、合理订货，减少产生浪费。

我们规划在未来三年内把智能化加深，做到订货更智能、更自动。各方面异常的预警由原本需要人参与，变成系统自动发单给后台，后台基于发单的结果直接执行到门店，这是我们今后要去做的一个方向。现阶段我们已经做到了基于营业额预测生成的智能推荐，门店的小伙伴会基于这个推荐值再做出判断，准确度有一定的保证。

三、携手腾讯云，不断深化数字化布局

谈及数字化系统的建构，“效率”是黄道泳老师提到最多的关键词之一，这也正是乐凯撒选择携手腾讯云，借力腾讯云函数 SCF、消息队列 CMQ、TDSQL 等现有的成熟的云产品的原因所在：不重复造轮子，通过好的工具有效实现降本增效，不断深化乐凯撒的数字化布局。

企业的业务需求很多时候都是很紧急的，你没有时间去慢慢从头开始造轮子，必须有快速响应的方案。我们内部团队一个大的基本原则就是：除非是非常复杂的系统，正常的功能需求和产品开发，必须在两周之内搞定。那就需要借用很多现有的工具。在我看来，一个真正有能力的人，并不是说你的技术有多牛，而是说你成功解决过多少问题，这些问题给业务带来了多少价值。有的是绕很多圈才能解决问题，有的是直接解决问题，还有的是又经济又简单地解决问题，这就是不同人的水平。我个人还是比较擅长去借轮子，而不是造轮子。我们使用腾讯云，核心也是希望能够用现成的轮子去减少开发成本、提升效率。

就比如消息队列，一开始团队说要自己搭一个，我说，我知道消息队列有很多开源的产品，我们自己搭的会比开源的更好用吗？更关键是搭完之后还有维护的工作，运维谁来做呢？而用腾讯云现成的消息队列产品，这些问题基本上就都解决了，因为腾讯云已经建好了整个基础建设，我们只需要使用就好了，而且腾讯拥有广泛的生态优势，能够连通很多其他的业态。

我们用的链路最长的其实是会员画像标签，我们乐凯撒自己的会员系统在接收顾客订单之后，会把这个订单的计算丢给 CMQ，CMQ 的队列完成之后会丢给云函数，再分发给不同的云函数分别去计算不同的用户画像指标，比如消费频次、消费喜好、复购率等，最终再回到 BI 系统里，去呈现整个的会员用户画像。

如果是我们自己去做的话，可能一个月都不一定能搞定，但是借用腾讯云现成的工具就很简单。而且腾讯云的这些工具都有配套的日志和保障机制，如果出问题都可以直接去看，还可以提工单给腾讯云的后台，我们也和腾讯云的同学建立了微信群，有腾讯云的同学帮我们解决，对我们来说就非常省事。

我们用得最多的应该是腾讯云函数，我们算是最早使用云函数的“小白鼠”了，当时的目的还是想以最低的成本，最快的速度来解决企业的问题。云函数首先是跨语言、跨平台的，它提供了一个相对开放的选择，非常适用于我们当时团队的情况，每个人都可以基于自己的技术特长，选择所擅长的语言去做。其次云函数的优势在于不需要部署，也免去了运维的问题。我们想用的特性，在腾讯云函数里面全都有，云函数团队也一直在不断地迭代优化。

我们用腾讯云函数最早做的是小程序的点单服务，后来逐渐扩大，到门店的云打印、会员标签的计算等等，总的来说包括独立应用、分布式计算和定时任务这三类业务。以门店打印为例，我们的打印是由云端服务来决定的，传统的 POS 在云端只做数据存储，所有的计算都在门店，门店有一台主机，因此它的打印是局域网的，如果这个打印机出问题，就只有本地的店员才能知道。而我们乐凯撒是一个云端的架构，顾客下单会统一进到云端，并根据订单类型同步分发到会员系统、打印系统等，并基于订单生成差异化的打印模板，比如外卖和堂食打印出来的小票就是不同的。我们可以在总部办公室就更改所有门店的打印模板，每一个门店的打印机是否通畅、是否断电、网络是否正常连接，总部都一览无余。

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

我们选 TDSQL，最大的需求就是解决分库、分表和存储。虽然我们自己搭建也可以，但考虑到整体的稳定性、性能和可扩展性，还是决定选择用 TDSQL 来完成。现在我们的订单、会员标签等大数据的业务都会放在 TDSQL 上，用它来做分布式的存储、查询和计算，解决了系统扩容的问题，也提升了查询的效率。因为腾讯已经有很好的后台基础了，所以对于开发同学来说，他们只需要对接 API 就可以了，屏蔽了很多数据库技术的细节，开发同学只需要专注业务，解决问题。

比如我们在系统运维慢查询的预警上，这个事情我们以前要做是挺麻烦的，需要自己去写很多的代码去检测我们的日志，现在腾讯云有现成的，只要谁写了一个慢查询，立马就会收到一个警告，谁跑了一个什么 SQL，跑了多长时间，查了多少数据，SQL 长什么样就都出来了。

我觉得腾讯的能力一直都在进步，服务意识也很好，会不断听取用户心声和问题反馈，以顾客为中心，而不是以利润为中心，我觉得这一点非常好。

携手腾讯云，乐凯撒在数字化的路上行远至深。展望乐凯撒未来的技术布局，黄道泳老师提出了独到的见解：比起响应需求，更重要的是主动提升业务的水平。

一个企业发展到后期，信息化达到一定程度后，所有的业务都要通过信息化来承载，因此IT部门作为核心的中间部门，必须要对业务有很深入的了解，所以我们部门的同学可能比公司其他部门的同学更懂他的业务，业务更熟悉之后，做出来的东西也就会少走弯路。

大部分的 IT 部门还是以响应需求为主，提什么就做什么，不提就不做，把自己当乙方看。但我们不是，我们在做的时候，首先响应需求，其次我们会评估需求，然后去优化这个需求。我们需要主动跟业务部门探讨，这样做合不合理，是不是有更好的方案？所以通过这种方式，我们也能够提前和产品及业务部门探讨沟通后续可能发生的变化，避免走很多弯路，以及一些不合理的需求，有所为，有所不为。

现在我们不仅是在做响应需求的事情，还在做业务改进的事情。比如说门店盒子，没有人来提出这个需求，我们其实是基于业务的改善，要降低能耗，也为未来的边缘计算和智能化做准备，因此有了这个盒子。我们最近也在做门店的高速生产系统。

在未来，我们会持续加大加深云函数的应用，也会尝试往大数据的计算上去做迭代升级，用 ClickHouse 来做订单和用户画像的计算和分析。

业务到一定阶段后，它是没有需求的，普通的需求已经解决了，剩下的就是我们如何基于自己的思考，通过信息化、数据化的手段提升业务的水平。