本文整理自樂凱撒黃道泳在 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 中文網！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/256634.html
標籤：其他