簡(jiǎn)介：好未來通過阿里云云原生架構(gòu)實(shí)現(xiàn)了對(duì)資源的靈活調(diào)度，阿里云為其 AI 中臺(tái)奠定了敏捷而堅(jiān)實(shí)的技術(shù)底座。

作者 | 劉東東

來源 | 凌云時(shí)刻（微信號(hào)：linuxpk）

前言

AI 時(shí)代的到來，給企業(yè)的底層 IT 資源的豐富與敏捷提出了更大的挑戰(zhàn)。利用阿里云穩(wěn)定、彈性的 GPU 云服務(wù)器，領(lǐng)先的 GPU 容器化共享和隔離技術(shù)，以及 K8S 集群管理平臺(tái)，好未來通過云原生架構(gòu)實(shí)現(xiàn)了對(duì)資源的靈活調(diào)度，為其 AI 中臺(tái)奠定了敏捷而堅(jiān)實(shí)的技術(shù)底座。

在 2020 年云棲大會(huì)上，好未來 AI 中臺(tái)負(fù)責(zé)人劉東東，分享了他對(duì) AI 云原生的理解與好未來的 AI 中臺(tái)實(shí)踐，本文為演講內(nèi)容整理。

大家好，我是好未來 AI 中臺(tái)技術(shù)負(fù)責(zé)人劉東東。今天我給大家?guī)淼难葜v主題是《好未來 AI 云原生的淺談》。

我的分享主要分成四個(gè)部分：

第一，AI 服務(wù)對(duì)云原生的挑戰(zhàn)。

第二，AI 與云原生的服務(wù)部署。

第三，AI 與云原生的服務(wù)治理。

最后想談一談， K8S 與 Spring Cloud 的有機(jī)結(jié)合。

AI 服務(wù)對(duì)云原生的挑戰(zhàn)

首先，我們來講一講 AI 服務(wù)對(duì)云原生的挑戰(zhàn)。在云原生時(shí)代，AI 服務(wù)其中最大的一個(gè)特點(diǎn)就是，需要更大的算力支持，以及更強(qiáng)大的一個(gè)服務(wù)的穩(wěn)定性。

我們的服務(wù)不單單只是原來的一個(gè)單體服務(wù)，現(xiàn)在已經(jīng)轉(zhuǎn)入到一個(gè)集群服務(wù)。同時(shí)對(duì)性能的穩(wěn)定性要求，已經(jīng)從 3 個(gè) 9，開始向 5 個(gè) 9 發(fā)起了挑戰(zhàn)。

那么這些問題，已經(jīng)不再是原有的傳統(tǒng)技術(shù)架構(gòu)能夠解決的。所以我們需要一個(gè)新的技術(shù)架構(gòu)。

這個(gè)新的技術(shù)架構(gòu)是什么呢？就是云原生。

我們來看一看，云原生對(duì)我們帶來的變化。云原生帶來的最大變化，我總結(jié)為四個(gè)要點(diǎn)和兩大方面。

四大要點(diǎn)分別是，DevOps、持續(xù)交付、微服務(wù)、容器的四個(gè)特點(diǎn)。兩個(gè)方面則是服務(wù)部署和服務(wù)治理。當(dāng)然，它還有 12 個(gè)要素的整體系統(tǒng)總結(jié)。

今天重點(diǎn)來講的是服務(wù)部署和服務(wù)治理。

在云原生浪潮下，我們是如何處理服務(wù)部署和服務(wù)治理呢？

首先我們通過 AI 與云原生的服務(wù)部署，即通過 K8S，加上一個(gè)資源的虛擬化，資源的池化等技術(shù)，解決了 AI 服務(wù)對(duì)各種硬件資源的數(shù)量級(jí)增長需求。

第二個(gè)，AI 服務(wù)與云原生的服務(wù)治理進(jìn)行有機(jī)結(jié)合。通過服務(wù)治理的技術(shù)，包括服務(wù)發(fā)現(xiàn)、HPA、負(fù)載均衡等，解決 AI 服務(wù)對(duì) 5 個(gè) 9 的 SLA 的需求。

AI 服務(wù)的云原生部署

第一點(diǎn)談一下是怎么把 AI 與云原生的服務(wù)部署結(jié)合起來的。

首先看一下，在 AI 時(shí)代下服務(wù)部署有哪些特點(diǎn)呢？

第一個(gè)就是硬件資源需求與費(fèi)用增長的一個(gè)矛盾。AI 服務(wù)對(duì)于硬件的需求成數(shù)量級(jí)增長，但是硬件預(yù)算并沒有成數(shù)量級(jí)增長。

第二，AI 服務(wù)對(duì)硬件的需求是多樣化的。如，對(duì)高 GPU 的需求、高 CPU 的需求、高內(nèi)存的需求，甚至還有部分混合的需求。

第三，AI 服務(wù)對(duì)資源的隔離是有需求的。每一個(gè) AI 服務(wù)都能夠獨(dú)立使用這些資源，并且相互之間不會(huì)打擾。

第四，AI 服務(wù)能夠?qū)Y源池化有要求。AI 服務(wù)不需要去感知機(jī)器的具體配置，一旦將所有的資源進(jìn)行池化，即可降低資源碎片，提升使用率。

最后一點(diǎn)，AI 服務(wù)對(duì)突發(fā)的資源是有請(qǐng)求的。因?yàn)榱髁渴遣豢深A(yù)知的，企業(yè)需要隨時(shí)保持，能夠隨時(shí)擴(kuò)充資源池的能力。

我們的解決方案是什么呢？

首先，我們使用 Docker 的虛擬化技術(shù)，實(shí)現(xiàn)資源的隔離。

然后使用 GPU 共享技術(shù)，將 GPU、內(nèi)存、CPU 等資源進(jìn)行池化，然后將整個(gè)資源進(jìn)行統(tǒng)一的管理。

最后，使用 K8S 的 resources，包括污點(diǎn)（taints）、容忍度（tolerations）等這些技術(shù)特性，實(shí)現(xiàn)服務(wù)的靈活配置。

另外，建議大家要買一些高配置的機(jī)器，這些高配置的機(jī)器，主要是為了進(jìn)一步降低碎片。

當(dāng)然，還要實(shí)現(xiàn)對(duì)整個(gè)集群硬件的監(jiān)控，充分利用 ECS 可以各種復(fù)雜的時(shí)間規(guī)則調(diào)度特性（下圖的 cron 是一個(gè)基于時(shí)間的作業(yè)調(diào)度任務(wù)），應(yīng)對(duì)高峰流量。

接下來，我們更仔細(xì)地看看好未來 AI 中臺(tái)是如何解決這些 AI 部署問題的。

這個(gè)頁面是我們的一個(gè) Node 的服務(wù)管理，通過這個(gè)業(yè)務(wù)，我們是可以清晰看到每一個(gè)服務(wù)器上面的部署情況，包括資源使用情況、部署哪些 pod、哪些節(jié)點(diǎn)等等。

第二個(gè)實(shí)際上是 AI 中臺(tái)的服務(wù)部署頁面。我們是可以通過壓碼文件，精準(zhǔn)地控制每一個(gè) pod 的內(nèi)存、CPU、GPU 的使用。同時(shí)，通過污點(diǎn)等技術(shù)，讓服務(wù)器的多樣化部署得到滿足。

根據(jù)我們的對(duì)比實(shí)驗(yàn)，使用云原生的方式部署對(duì)比用戶自行部署，成本大概節(jié)省了 65%。而且，這樣的優(yōu)勢(shì)會(huì)隨著 AI 集群的增長，在經(jīng)濟(jì)收益上和臨時(shí)流量擴(kuò)容上，將會(huì)受益更多。

AI 與云原生服務(wù)治理

接下來再討論一下 AI 與云原生的服務(wù)治理。

簡(jiǎn)單介紹一下什么叫微服務(wù)？其實(shí)微服務(wù)，只是服務(wù)的一種架構(gòu)風(fēng)格，它實(shí)際上是將單個(gè)服務(wù)，作為一整套的小型服務(wù)開發(fā)，然后每一個(gè)應(yīng)用程序都有自己進(jìn)程去運(yùn)行，并且通過輕量級(jí)的一些，比如說 HTTP、API 等進(jìn)行通信。

這些服務(wù)，實(shí)際上是圍繞著業(yè)務(wù)本身去構(gòu)建的，可以通過自動(dòng)化的部署等手段去集中管理。同時(shí)，通過不同的語言去編寫，使用不同的存儲(chǔ)資源。

總結(jié)起來微服務(wù)有哪些特點(diǎn)？

第一，微服務(wù)它足夠小，甚至它只能做一件事情。

第二，微服務(wù)是無狀態(tài)的。

第三，微服務(wù)相互之間是相互獨(dú)立的，并且它們是面向接口的。

最后，微服務(wù)是高度自治的，每個(gè)人只對(duì)自己負(fù)責(zé)。

看到這些微服務(wù)的特點(diǎn)之后，再去想一想，AI 服務(wù)與微服務(wù)特點(diǎn)，我們發(fā)現(xiàn)，AI 服務(wù)天生適合微服務(wù)。每一個(gè)微服務(wù)，其實(shí)本質(zhì)上只做一件事情。比如 OCR，OCR 服務(wù)，只做 OCR 服務(wù)；ASR，主要做 ASR 服務(wù)。

繼而，每一個(gè) AI 服務(wù)的請(qǐng)求都是獨(dú)立的。舉個(gè)簡(jiǎn)單例子，一個(gè) OCR 請(qǐng)求和另外一個(gè) OCR 請(qǐng)求，在本質(zhì)上是沒有什么關(guān)聯(lián)的。

AI 服務(wù)對(duì)橫向擴(kuò)容是有天生苛求的。為什么？因?yàn)?AI 服務(wù)隊(duì)資源的渴求非常大。于是，這種擴(kuò)容就顯得非常有必要性了。

AI 服務(wù)之間的依賴性也特別小。比如說像我們的 OCR 服務(wù)，可能對(duì) NLP 的服務(wù)，或者是對(duì)其它的 AI 服務(wù)，可能沒有什么太大的要求。

所有的 AI 服務(wù)，都可以通過寫申明式的 HTTP，甚至 API 的方式，提供 AI 能力。

進(jìn)一步去看一下 AI 服務(wù)，會(huì)發(fā)現(xiàn)，并不能將所有的 AI 服務(wù)進(jìn)行微服務(wù)化。于是，我們做了什么事？

第一，需要將 AI 服務(wù)做成一個(gè)無狀態(tài)的服務(wù)，這些無狀態(tài)服務(wù)，都是有畜牲化、無狀態(tài)、可丟棄，并且不采用任何的一些磁盤或者內(nèi)存的請(qǐng)求方式，去做一些存儲(chǔ)功能。這樣就可以讓服務(wù)部署在任何的一個(gè)節(jié)點(diǎn)，任何一個(gè)地方。

當(dāng)然，并不是所有的服務(wù)都能做到無狀態(tài)。如果它有狀態(tài)了怎么辦呢？我們會(huì)通過配置中心、日志中心、Redis、MQ，還有 SQL 等數(shù)據(jù)庫，存儲(chǔ)這些請(qǐng)求狀態(tài)。同時(shí)，確保這些組件的高可靠性。

這個(gè)就是好未來 AI 中臺(tái) PaaS 的整體架構(gòu)圖。首先可以看一下最外層是服務(wù)接口層。最外層接口層是面向外部提供 AI 能力的。

平臺(tái)層里最重要的層是服務(wù)網(wǎng)關(guān)，主要是負(fù)責(zé)一些動(dòng)態(tài)路由、流量控制、負(fù)載均衡、鑒權(quán)等。再往下就是我們的一些服務(wù)發(fā)現(xiàn)，注冊(cè)中心，容錯(cuò)、配置管理、彈性伸縮等等一些功能。

再下面是業(yè)務(wù)層，這些業(yè)務(wù)層就是我們所說的，一些 AI 的推理服務(wù)。

最下面就是阿里云給我們提供的 K8S 集群。

也就是說整體的一個(gè)架構(gòu)是，K8S 負(fù)責(zé)服務(wù)部署，SpringCloud 負(fù)責(zé)服務(wù)治理。

我們是怎么通過技術(shù)手段來實(shí)現(xiàn)剛才說的一個(gè)整體架構(gòu)圖？

首先是通過 Eureka 作為注冊(cè)中心，實(shí)現(xiàn)分布式系統(tǒng)的服務(wù)發(fā)現(xiàn)與注冊(cè)。通過配置中心 Apoll 來管理服務(wù)器的配置屬性，并且支持動(dòng)態(tài)更新。網(wǎng)關(guān) Gateway，可以做到隔離內(nèi)外層的效果。熔斷 Hystrix，主要是分為分時(shí)熔斷和數(shù)量熔斷，然后保護(hù)我們的服務(wù)不被阻塞。

負(fù)載均衡加上 Fegin 操作，可以實(shí)現(xiàn)整體流量的負(fù)載均衡，并且將我們的 Eureka 相關(guān)注冊(cè)信息進(jìn)行消費(fèi)。消費(fèi)總線 Kafka 是異步處理的組件。然后鑒權(quán)是通過 Outh2+RBAC 的方法去做的，實(shí)現(xiàn)了用戶的登錄包括接口的鑒權(quán)管理，保證安全可靠。

鏈路追蹤，采用的是 Skywalking，通過這種 APM 的一個(gè)架構(gòu)，我們可以追蹤每一個(gè)請(qǐng)求的情況，便于定位和告警每一個(gè)請(qǐng)求。

最后日志系統(tǒng)是通過 Filebeat+ES，分布式收集整個(gè)集群的日志。

同時(shí)我們也開發(fā)了一些自己的服務(wù)，比如說部署服務(wù)、Contral 服務(wù)。主要是負(fù)責(zé)與 K8S 進(jìn)行通信，收集整個(gè) K8S 集群里面服務(wù)的服務(wù)部署、K8S 相關(guān)的硬件信息。

然后告警系統(tǒng)是通過 Prometheus+Monitor 去做的，可以收集硬件數(shù)據(jù)，負(fù)責(zé)資源、業(yè)務(wù)等相關(guān)的告警。

數(shù)據(jù)服務(wù)是主要用于下載，包括數(shù)據(jù)回流，然后截取我們推理場(chǎng)景下的數(shù)據(jù)情況。

限流服務(wù)是限制每個(gè)客戶的請(qǐng)求和 QPS 相關(guān)功能。

HPA 實(shí)際上是最重要的一個(gè)部分。HPA 不單單只支持內(nèi)存級(jí)別的，或 CPU 級(jí)別的 HPA，還支持一些 P99、QPS、GPU 等相關(guān)規(guī)則。

最后是統(tǒng)計(jì)服務(wù)，主要是用于統(tǒng)計(jì)相關(guān)調(diào)用量，比如請(qǐng)求等。

我們通過一個(gè)統(tǒng)一的控制臺(tái)，對(duì) AI 開發(fā)者提供了一站式的解決方案，通過一個(gè)平臺(tái)解決了全部的服務(wù)治理問題，提升了運(yùn)維的工作自動(dòng)化，讓原來需要幾個(gè)人維護(hù)的一個(gè) AI 服務(wù)的情況，變成了一個(gè)人能夠做到維護(hù)十幾個(gè) AI 服務(wù)。

這個(gè)頁面展示的就是服務(wù)路由、負(fù)載均衡、限流相關(guān)的配置頁面。

這個(gè)頁面展示的是我們?cè)诮涌诩?jí)別的一些告警，以及部署級(jí)別的硬件告警。

這是日志檢索，包括實(shí)時(shí)日志相關(guān)功能。

這個(gè)是手動(dòng)伸縮和自動(dòng)伸縮操作頁面。其中自動(dòng)伸縮包括 CPU、內(nèi)存級(jí)別的 HPA，也包括基于相應(yīng)響應(yīng)時(shí)長制定 HPA、定時(shí)的 HPA。

K8S 與 Spring Cloud 的有機(jī)結(jié)合

最后來聊一下 K8S 與 SpringCloud 的有機(jī)結(jié)合。

可以看一下這兩張圖。左圖是我們 SpringCloud 數(shù)據(jù)中心到路由的圖。右邊是 K8S 的 service 到它的 pod 的圖。

這兩個(gè)圖在結(jié)構(gòu)上是非常接近的。我們是怎么做到呢？實(shí)際上是將我們的 Application 與 K8S 的 service 進(jìn)行綁定，也就是說最終注冊(cè)到我們 SpringCloud 里面 LB 的地址，實(shí)際上是把它轉(zhuǎn)成了 K8S service 的地址。這樣就可以將 K8S 與 SpringCloud 結(jié)合起來。這是路由級(jí)別集合。有了這個(gè)集合，就能達(dá)到最終的效果。

SprigCloud 它是一個(gè) Java 的技術(shù)語言站。而 AI 服務(wù)的語言是多樣化的，有 C++、Java，甚至有 PHP。

為了實(shí)現(xiàn)跨語言，我們引入了 sidecar 技術(shù)，將 AI 服務(wù)與 sidecar 通過 RPC 去通信，就可以屏蔽語言的特性。

Sidecar 主要的功能有，應(yīng)用服務(wù)發(fā)現(xiàn)與注冊(cè)、路由追蹤、鏈路追蹤，以及健康檢查。

原文鏈接：https://developer.aliyun.com/article/778683?

版權(quán)聲明：本文內(nèi)容由阿里云實(shí)名注冊(cè)用戶自發(fā)貢獻(xiàn)，版權(quán)歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。具體規(guī)則請(qǐng)查看《阿里云開發(fā)者社區(qū)用戶服務(wù)協(xié)議》和《阿里云開發(fā)者社區(qū)知識(shí)產(chǎn)權(quán)保護(hù)指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權(quán)投訴表單進(jìn)行舉報(bào)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的AI 云原生浅谈：好未来 AI 中台实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。