本文整理自樂凱撒黃道泳在 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 中文網！