加速SaaS规模化演进,餐道基于K8s的云上创新底座
作者|溪洋、蔡金輝
審核&校對(duì):溪洋、海珠、葉仔
編輯&排版:雯燕
摘要:餐飲正在成為數(shù)智化轉(zhuǎn)型在實(shí)體經(jīng)濟(jì)運(yùn)用中的最大試驗(yàn)場(chǎng),推動(dòng)著 SaaS 演進(jìn)為餐飲行業(yè)新的基礎(chǔ)設(shè)施。作為國內(nèi)最早一批涉足餐飲 SaaS 的企業(yè),餐道正在以云原生的方式幫助餐飲企業(yè)進(jìn)一步解決成本控制、效率提升等需求。通過將業(yè)務(wù)平臺(tái)遷移至阿里云容器服務(wù) ACK,使服務(wù)器資源利用率提升超過 30%,擴(kuò)容效率提升近 80%,版本發(fā)布周期縮短近 40%,并以 0 集群故障為業(yè)務(wù)連續(xù)性提供充分保障。
“民以食為天”,這是一句刻在每個(gè)中國人 DNA 里的老話。餐飲行業(yè)也從來不乏激烈的競爭。消費(fèi)升級(jí)和支付習(xí)慣變化、人力和經(jīng)營成本攀升、由疫情帶來的不確定性等種種趨勢(shì)的不斷蔓延,使餐飲企業(yè)對(duì)成本控制、效率提升、精細(xì)化運(yùn)營等需求越來越迫切。
全云開發(fā)新趨勢(shì)與 SaaS 的演進(jìn)
《2020 年中國企業(yè)級(jí) SaaS 行業(yè)研究報(bào)告》顯示,到 2022 年,中國企業(yè) SaaS 市場(chǎng)的規(guī)模預(yù)計(jì)將突破千億元。與此同時(shí),餐飲 SaaS 等深耕垂直領(lǐng)域的企業(yè)服務(wù)已經(jīng)進(jìn)入規(guī)模化應(yīng)用階段。
作為國內(nèi)最早一批涉足餐飲 SaaS 的先行者,餐道創(chuàng)始人李振宏認(rèn)為,傳統(tǒng)餐飲走向互聯(lián)網(wǎng)化是順應(yīng)時(shí)代的必然選擇。這也帶動(dòng)了餐飲 SaaS 逐漸成為餐飲企業(yè)增強(qiáng)管理水平、優(yōu)化成本結(jié)構(gòu)的重要選擇。如今,哪怕是街邊一個(gè)小吃攤,都在用互聯(lián)網(wǎng)進(jìn)行著結(jié)算;各大商圈的餐飲門店,也幾乎都在使用 SaaS 的收付款系統(tǒng)。從技術(shù)上而言,餐飲 SaaS 已經(jīng)能從最初的采購,貫穿到顧客買單、顧客維護(hù)、外賣訂單、騎手配送、人力管理以及供應(yīng)鏈、數(shù)據(jù)中臺(tái)等各個(gè)環(huán)節(jié)。
云計(jì)算是 SaaS 發(fā)展的根基。在云原生帶來的全云開發(fā)新趨勢(shì)下,下一代 SaaS 將向何處演進(jìn)?本文將通過餐道基于阿里云容器服務(wù) ACK 的實(shí)踐案例,分享以 Kubernetes 為基礎(chǔ)的云原生架構(gòu)如何助力餐飲 SaaS 實(shí)現(xiàn)更加穩(wěn)定、可靠的服務(wù),并進(jìn)一步幫助企業(yè)優(yōu)化資源和人力成本。
餐道打造基于 ACK 的融合創(chuàng)新云上底座
餐道將自身定位為餐飲新零售行業(yè)“連接器”。截至 2021 年 10 月,其服務(wù)已覆蓋了全國 400+ 個(gè)城市,80000+ 家門店,日處理訂單 350 萬+。在餐道看來,未來餐飲企業(yè)一定會(huì)以“數(shù)據(jù)服務(wù)化”、“全渠道服務(wù)化”和“新業(yè)務(wù)拓展敏捷化”的交融與創(chuàng)新為發(fā)展方向。
為了幫助商家建立全鏈路業(yè)務(wù)的一站式管理方式,實(shí)現(xiàn)降本增效,餐道基于 SaaS 架構(gòu)打造了一體化數(shù)據(jù)智能應(yīng)用,能夠?qū)油赓u平臺(tái)、商家自建系統(tǒng)、收銀系統(tǒng)、會(huì)員系統(tǒng)、配送供應(yīng)商、后廚、ERP 系統(tǒng)、線上支付系統(tǒng)等。
餐道業(yè)務(wù)架構(gòu)圖
餐道非常重視客戶對(duì)服務(wù)的體驗(yàn),并將系統(tǒng)穩(wěn)定性、業(yè)務(wù)功能的迭代效率、問題的快速定位和解決視為構(gòu)建核心競爭力的基石。餐飲行業(yè)業(yè)務(wù)流量的波峰波谷現(xiàn)象明顯,且經(jīng)常會(huì)通過促銷活動(dòng)的方式來吸引顧客,如果由于資源分配不合理導(dǎo)致高峰時(shí)期訂單溢出、運(yùn)力不足,會(huì)極大影響顧客和商家的體驗(yàn);此外,餐道提供了訂單管理系統(tǒng)、CDBI、小程序、聚合配送、DMS、代運(yùn)營等諸多垂直業(yè)務(wù)功能,在市場(chǎng)需求的快速變化下,產(chǎn)品功能創(chuàng)新和迭代效率問題也是對(duì)技術(shù)架構(gòu)的一大挑戰(zhàn)。
這些現(xiàn)狀的解法和云原生架構(gòu)帶來的核心能力不謀而合。餐道將主要的業(yè)務(wù)應(yīng)用,包括前端 Web 容器、網(wǎng)關(guān)、后端微服務(wù)通過 Kubernetes 集群部署,以云原生的方式幫助業(yè)務(wù)快速迭代,靈活響應(yīng)商業(yè)需求。
餐道基于 ACK 的 SaaS 服務(wù)架構(gòu)
云原生趨勢(shì)下,Kubernetes 已經(jīng)成為企業(yè)新一代云IT架構(gòu)的基礎(chǔ)設(shè)施。但是在企業(yè)部署和運(yùn)維 Kubernetes 集群的過程中,復(fù)雜性依然較高。對(duì)于 SaaS 服務(wù)商來說,如果選擇自建 Kunernetes,那么只要有虛擬機(jī),就能夠創(chuàng)建 Kubernetes 集群,并在集群上運(yùn)行整個(gè)應(yīng)用系統(tǒng),無論這些虛擬機(jī)是來自本地 IDC 還是云平臺(tái)。如果是為了滿足存在私有化部署需求的客戶,采用自建方式可以方便地調(diào)用所需的計(jì)算資源。
但當(dāng)規(guī)模達(dá)到一定程度之后,自建 Kunernetes上會(huì)出現(xiàn)許多問題,比如由 DNS 解析帶來的不穩(wěn)定。另外遇到商家活動(dòng)等流量高峰場(chǎng)景,需要自行購買服務(wù)器擴(kuò)容, 并進(jìn)行各種初始化安裝操作、集群配置等一系列繁瑣的工作、增加一臺(tái)服務(wù)器至少需要花費(fèi) 15 分鐘,無論是資源、時(shí)間還是維護(hù)成本都比較高。
隨著容器化應(yīng)用在生產(chǎn)環(huán)境下的普及,企業(yè)對(duì)于托管 Kubernetes 的需求持續(xù)增長。在 2021 年最新的 CNCF 云原生調(diào)查中,26% 的受訪者表示正在使用托管 Kubernetes 服務(wù),高于一年前的 23%,正迅速逼近本地安裝的比例(31%)。
為了在更好地保證業(yè)務(wù)系統(tǒng)穩(wěn)定性的同時(shí)節(jié)省運(yùn)維人力成本,近期,餐道選擇將其部署在自建 Kubernetes 集群上的業(yè)務(wù)應(yīng)用遷移至阿里云容器服務(wù) ACK,構(gòu)建其餐飲 SaaS 平臺(tái)。
ACK 以阿里云可靠穩(wěn)定的 IaaS 平臺(tái)為底座,向下封裝了 30+ 款云產(chǎn)品,形成了自動(dòng)化運(yùn)維和云平臺(tái)交互的新界面,從而提升企業(yè)業(yè)務(wù)系統(tǒng)的彈性和自動(dòng)化運(yùn)維能力。對(duì)內(nèi),ACK 支撐了集團(tuán) 100% 應(yīng)用的云原生化,同時(shí)為云上上萬企業(yè)實(shí)現(xiàn)現(xiàn)代化應(yīng)用改造升級(jí)提供升級(jí)服務(wù)。
阿里云容器服務(wù) ACK 產(chǎn)品家族
餐道技術(shù)架構(gòu)負(fù)責(zé)人蔡金輝介紹稱,選擇 ACK,我們主要看重以下能力:
首先是服務(wù)的穩(wěn)定性,ACK 是經(jīng)過阿里云大規(guī)模場(chǎng)景實(shí)踐驗(yàn)證和優(yōu)化的,很多坑不需要我們自己去踩,也不需要我們花費(fèi)很多精力去做應(yīng)用的優(yōu)化適配。在提升系統(tǒng)穩(wěn)定性的同時(shí),節(jié)省了很多運(yùn)維人力成本。
其次是 ACK 的擴(kuò)容速度,可以一次性擴(kuò)容多臺(tái),而且不管擴(kuò)容多少臺(tái),都是在 10 分鐘以內(nèi)就能完成,這樣當(dāng)遇到一些計(jì)劃外的突發(fā)流量的時(shí)候,我們可以較快地應(yīng)對(duì)。
除此之外,ACK 整合了阿里云云原生的多種能力,可以幫助企業(yè)高效運(yùn)行云端 Kubernetes 容器化應(yīng)用,比如 ACK 中集成的 Prometheus 監(jiān)控服務(wù),可以幫助快速定位性能問題,更好地保證業(yè)務(wù)的連續(xù)性。
對(duì)于像餐道這樣已經(jīng)在企業(yè)自有 IDC 中或云上自建 Kubernetes 集群的企業(yè),阿里云提供了完整的遷移解決方案,可同時(shí)支持幾百個(gè)服務(wù)平滑向云上 ACK 遷移。依托自研工具庫,可實(shí)現(xiàn)經(jīng)典網(wǎng)絡(luò)與 VPC 網(wǎng)絡(luò)打通、經(jīng)典 Kubernetes 集群中的 pod/service 與 ACK 中的 pod/service 打通、為各類數(shù)據(jù)庫遷移設(shè)置白名單等能力,提高遷云效率,竭力將遷移期間對(duì)企業(yè)業(yè)務(wù)的影響降至最低,保證業(yè)務(wù)可靠性、穩(wěn)定性、安全性和靈活性。
自建 K8s 平滑遷移 ACK
ACK 也是全球首批通過 Kubernetes 一致性認(rèn)證的服務(wù)平臺(tái),其在標(biāo)準(zhǔn)的 Kubernetes 基礎(chǔ)之上,大幅提升了企業(yè)生產(chǎn)環(huán)境下關(guān)注的安全防護(hù)、高可用保障和穩(wěn)定升級(jí)等一站式服務(wù)能力。因此遷移至 ACK 后,構(gòu)建在餐道 SaaS 平臺(tái)中的應(yīng)用發(fā)布流程基本沒有任何變化,而且集群更加穩(wěn)定,運(yùn)行至今沒有出現(xiàn)一例 Kubernetes 的運(yùn)維問題,使企業(yè)本身可以將更多精力聚焦于業(yè)務(wù)的創(chuàng)新和快速發(fā)展。
同時(shí),在餐道業(yè)務(wù)平臺(tái)遷移至 ACK 的這段時(shí)間里,在成本、穩(wěn)定性、效率、賦能業(yè)務(wù)等四個(gè)維度獲得顯著成效:
- 資源利用率提升:服務(wù)器資源利用率提升了 30%+;
- 支撐業(yè)務(wù)快速發(fā)展:出現(xiàn)問題后可快速隔離,當(dāng)面對(duì)急劇增長的業(yè)務(wù)量,可以在短時(shí)間內(nèi)完成擴(kuò)容,原本自建集群需要 15 分鐘擴(kuò)容一個(gè)節(jié)點(diǎn),而現(xiàn)在 ACK 集群平均只需要 3 分鐘即可擴(kuò)容出一個(gè)節(jié)點(diǎn),擴(kuò)容效率提升了近 80%;
- 迭代效率提升:版本迭代期間,服務(wù)的更新速度有了明顯的改善,縮短了近 40% 的版本發(fā)布時(shí)間;
- 0 集群故障:集群的穩(wěn)定性也給系統(tǒng)提供了充分的保障,截至目前,餐道各業(yè)務(wù)平臺(tái)上的集群故障次數(shù)為 0。
可以預(yù)見,未來隨著商家業(yè)務(wù)量的上升,ACK 提供的容器化應(yīng)用全生命周期管理能力將助力餐道發(fā)揮更大價(jià)值。
云原生重新定義餐飲 SaaS 市場(chǎng)需求
可以說,餐飲正在成為數(shù)智化轉(zhuǎn)型在實(shí)體經(jīng)濟(jì)運(yùn)用中的最大試驗(yàn)場(chǎng)。不久的將來,SaaS將演進(jìn)為餐飲行業(yè)的基礎(chǔ)設(shè)施,通過將更先進(jìn)、更高效的技術(shù)、運(yùn)營方式與傳統(tǒng)的餐飲品類相結(jié)合,為餐飲企業(yè)帶來更多發(fā)展機(jī)會(huì)。
與此同時(shí),隨著 Kubernetes 為代表的云原生技術(shù)、架構(gòu)及服務(wù)的發(fā)展,未來企業(yè)在任何需要云的地方,都能夠享受到統(tǒng)一的云上運(yùn)維和資源管控能力, 使研發(fā)、運(yùn)維人員無需關(guān)注系統(tǒng)可靠性、可用性、穩(wěn)定性,將精力專注于業(yè)務(wù)創(chuàng)新,進(jìn)一步釋放人力和資源成本。
從互聯(lián)網(wǎng)到新零售、餐飲、金融、制造、交通, ACK 正在支撐著越來越多的行業(yè)利用云原生的方式解決業(yè)務(wù)問題,加速場(chǎng)景創(chuàng)新。阿里云容器服務(wù) ACK 也期待著與越來越多的“餐道”一起,幫助更多有潛力的企業(yè)激發(fā)創(chuàng)新活力,與各行各業(yè)的時(shí)代變革者共同生長。
👇👇點(diǎn)擊這里,了解阿里云容器服務(wù) ACK 產(chǎn)品詳情!
了解更多相關(guān)信息,請(qǐng)掃描下方二維碼或搜索微信號(hào)(AlibabaCloud888)添加云原生小助手!獲取更多相關(guān)資訊!
總結(jié)
以上是生活随笔為你收集整理的加速SaaS规模化演进,餐道基于K8s的云上创新底座的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 基于 KubeVela 的 GitOps
- 下一篇: 基于 Istio 的全链路灰度方案探索和