作者 | 劉東東
來源 | 凌雲時刻（微信號：linuxpk）
前言
AI 時代的到來，給企業的底層 IT 資源的豐富與敏捷提出了更大的挑戰。利用阿里雲穩定、彈性的 GPU 雲服務器，領先的 GPU 容器化共享和隔離技術，以及 K8S 集群管理平臺，好未來通過雲原生架構實現了對資源的靈活調度，為其 AI 中臺奠定了敏捷而堅實的技術底座。
在 2020 年雲棲大會上，好未來 AI 中臺負責人劉東東，分享了他對 AI 雲原生的理解與好未來的 AI 中臺實踐，本文為演講內容整理。
大家好，我是好未來 AI 中臺技術負責人劉東東。今天我給大家帶來的演講主題是《好未來 AI 雲原生的淺談》。
我的分享主要分成四個部分：
第一，AI 服務對雲原生的挑戰。
第二，AI 與雲原生的服務部署。
第三，AI 與雲原生的服務治理。
最後想談一談， K8S 與 Spring Cloud 的有機結合。
AI 服務對雲原生的挑戰
首先，我們來講一講 AI 服務對雲原生的挑戰。在雲原生時代，AI 服務其中最大的一個特點就是，需要更大的算力支持，以及更強大的一個服務的穩定性。
我們的服務不單單只是原來的一個單體服務，現在已經轉入到一個集群服務。同時對性能的穩定性要求，已經從 3 個 9，開始向 5 個 9 發起了挑戰。
那麼這些問題，已經不再是原有的傳統技術架構能夠解決的。所以我們需要一個新的技術架構。
這個新的技術架構是什麼呢？就是雲原生。
我們來看一看，雲原生對我們帶來的變化。雲原生帶來的最大變化，我總結為四個要點和兩大方面。
四大要點分別是，DevOps、持續交付、微服務、容器的四個特點。兩個方面則是服務部署和服務治理。當然，它還有 12 個要素的整體系統總結。
今天重點來講的是服務部署和服務治理。
在雲原生浪潮下，我們是如何處理服務部署和服務治理呢？
首先我們通過 AI 與雲原生的服務部署，即通過 K8S，加上一個資源的虛擬化，資源的池化等技術，解決了 AI 服務對各種硬件資源的數量級增長需求。
第二個，AI 服務與雲原生的服務治理進行有機結合。通過服務治理的技術，包括服務發現、HPA、負載均衡等，解決 AI 服務對 5 個 9 的 SLA 的需求。
AI 服務的雲原生部署
第一點談一下是怎麼把 AI 與雲原生的服務部署結合起來的。
首先看一下，在 AI 時代下服務部署有哪些特點呢？
第一個就是硬件資源需求與費用增長的一個矛盾。AI 服務對於硬件的需求成數量級增長，但是硬件預算並沒有成數量級增長。
第二，AI 服務對硬件的需求是多樣化的。如，對高 GPU 的需求、高 CPU 的需求、高內存的需求，甚至還有部分混合的需求。
第三，AI 服務對資源的隔離是有需求的。每一個 AI 服務都能夠獨立使用這些資源，並且相互之間不會打擾。
第四，AI 服務能夠對資源池化有要求。AI 服務不需要去感知機器的具體配置，一旦將所有的資源進行池化，即可降低資源碎片，提升使用率。
最後一點，AI 服務對突發的資源是有請求的。因為流量是不可預知的，企業需要隨時保持，能夠隨時擴充資源池的能力。
我們的解決方案是什麼呢？
首先，我們使用 Docker 的虛擬化技術，實現資源的隔離。
然後使用 GPU 共享技術，將 GPU、內存、CPU 等資源進行池化，然後將整個資源進行統一的管理。
最後，使用 K8S 的 resources，包括汙點（taints）、容忍度（tolerations）等這些技術特性，實現服務的靈活配置。
另外，建議大家要買一些高配置的機器，這些高配置的機器，主要是為了進一步降低碎片。
當然，還要實現對整個集群硬件的監控，充分利用 ECS 可以各種複雜的時間規則調度特性（下圖的 cron 是一個基於時間的作業調度任務），應對高峰流量。
接下來，我們更仔細地看看好未來 AI 中臺是如何解決這些 AI 部署問題的。
這個頁面是我們的一個 Node 的服務管理，通過這個業務，我們是可以清晰看到每一個服務器上面的部署情況，包括資源使用情況、部署哪些 pod、哪些節點等等。
第二個實際上是 AI 中臺的服務部署頁面。我們是可以通過壓碼文件，精準地控制每一個 pod 的內存、CPU、GPU 的使用。同時，通過汙點等技術，讓服務器的多樣化部署得到滿足。
根據我們的對比實驗，使用雲原生的方式部署對比用戶自行部署，成本大概節省了 65%。而且，這樣的優勢會隨著 AI 集群的增長，在經濟收益上和臨時流量擴容上，將會受益更多。
AI 與雲原生服務治理
接下來再討論一下 AI 與雲原生的服務治理。
簡單介紹一下什麼叫微服務？其實微服務，只是服務的一種架構風格，它實際上是將單個服務，作為一整套的小型服務開發，然後每一個應用程序都有自己進程去運行，並且通過輕量級的一些，比如說 HTTP、API 等進行通信。
這些服務，實際上是圍繞著業務本身去構建的，可以通過自動化的部署等手段去集中管理。同時，通過不同的語言去編寫，使用不同的存儲資源。
總結起來微服務有哪些特點？
第一，微服務它足夠小，甚至它只能做一件事情。
第二，微服務是無狀態的。
第三，微服務相互之間是相互獨立的，並且它們是面向接口的。
最後，微服務是高度自治的，每個人只對自己負責。
看到這些微服務的特點之後，再去想一想，AI 服務與微服務特點，我們發現，AI 服務天生適合微服務。每一個微服務，其實本質上只做一件事情。比如 OCR，OCR 服務，只做 OCR 服務；ASR，主要做 ASR 服務。
繼而，每一個 AI 服務的請求都是獨立的。舉個簡單例子，一個 OCR 請求和另外一個 OCR 請求，在本質上是沒有什麼關聯的。
AI 服務對橫向擴容是有天生苛求的。為什麼？因為 AI 服務隊資源的渴求非常大。於是，這種擴容就顯得非常有必要性了。
AI 服務之間的依賴性也特別小。比如說像我們的 OCR 服務，可能對 NLP 的服務，或者是對其它的 AI 服務，可能沒有什麼太大的要求。
所有的 AI 服務，都可以通過寫申明式的 HTTP，甚至 API 的方式，提供 AI 能力。
進一步去看一下 AI 服務，會發現，並不能將所有的 AI 服務進行微服務化。於是，我們做了什麼事？
第一，需要將 AI 服務做成一個無狀態的服務，這些無狀態服務，都是有畜牲化、無狀態、可丟棄，並且不採用任何的一些磁盤或者內存的請求方式，去做一些存儲功能。這樣就可以讓服務部署在任何的一個節點，任何一個地方。
當然，並不是所有的服務都能做到無狀態。如果它有狀態了怎麼辦呢？我們會通過配置中心、日誌中心、Redis、MQ，還有 SQL 等數據庫，存儲這些請求狀態。同時，確保這些組件的高可靠性。
這個就是好未來 AI 中臺 PaaS 的整體架構圖。首先可以看一下最外層是服務接口層。最外層接口層是面向外部提供 AI 能力的。
平臺層裡最重要的層是服務網關，主要是負責一些動態路由、流量控制、負載均衡、鑑權等。再往下就是我們的一些服務發現，註冊中心，容錯、配置管理、彈性伸縮等等一些功能。
再下面是業務層，這些業務層就是我們所說的，一些 AI 的推理服務。
最下面就是阿里雲給我們提供的 K8S 集群。
也就是說整體的一個架構是，K8S 負責服務部署，SpringCloud 負責服務治理。
我們是怎麼通過技術手段來實現剛才說的一個整體架構圖？
首先是通過 Eureka 作為註冊中心，實現分佈式系統的服務發現與註冊。通過配置中心 Apoll 來管理服務器的配置屬性，並且支持動態更新。網關 Gateway，可以做到隔離內外層的效果。熔斷 Hystrix，主要是分為分時熔斷和數量熔斷，然後保護我們的服務不被阻塞。
負載均衡加上 Fegin 操作，可以實現整體流量的負載均衡，並且將我們的 Eureka 相關注冊信息進行消費。消費總線 Kafka 是異步處理的組件。然後鑑權是通過 Outh2+RBAC 的方法去做的，實現了用戶的登錄包括接口的鑑權管理，保證安全可靠。
鏈路追蹤，採用的是 Skywalking，通過這種 APM 的一個架構，我們可以追蹤每一個請求的情況，便於定位和告警每一個請求。
最後日誌系統是通過 Filebeat+ES，分佈式收集整個集群的日誌。
同時我們也開發了一些自己的服務，比如說部署服務、Contral 服務。主要是負責與 K8S 進行通信，收集整個 K8S 集群裡面服務的服務部署、K8S 相關的硬件信息。
然後告警系統是通過 Prometheus+Monitor 去做的，可以收集硬件數據，負責資源、業務等相關的告警。
數據服務是主要用於下載，包括數據迴流，然後截取我們推理場景下的數據情況。
限流服務是限制每個客戶的請求和 QPS 相關功能。
HPA 實際上是最重要的一個部分。HPA 不單單隻支持內存級別的，或 CPU 級別的 HPA，還支持一些 P99、QPS、GPU 等相關規則。
最後是統計服務，主要是用於統計相關調用量，比如請求等。
我們通過一個統一的控制檯，對 AI 開發者提供了一站式的解決方案，通過一個平臺解決了全部的服務治理問題，提升了運維的工作自動化，讓原來需要幾個人維護的一個 AI 服務的情況，變成了一個人能夠做到維護十幾個 AI 服務。
這個頁面展示的就是服務路由、負載均衡、限流相關的配置頁面。
這個頁面展示的是我們在接口級別的一些告警，以及部署級別的硬件告警。
這是日誌檢索，包括實時日誌相關功能。
這個是手動伸縮和自動伸縮操作頁面。其中自動伸縮包括 CPU、內存級別的 HPA，也包括基於相應響應時長制定 HPA、定時的 HPA。
K8S 與 Spring Cloud 的有機結合
最後來聊一下 K8S 與 SpringCloud 的有機結合。 
可以看一下這兩張圖。左圖是我們 SpringCloud 數據中心到路由的圖。右邊是 K8S 的 service 到它的 pod 的圖。
這兩個圖在結構上是非常接近的。我們是怎麼做到呢？實際上是將我們的 Application 與 K8S 的 service 進行綁定，也就是說最終註冊到我們 SpringCloud 裡面 LB 的地址，實際上是把它轉成了 K8S service 的地址。這樣就可以將 K8S 與 SpringCloud 結合起來。這是路由級別集合。有了這個集合，就能達到最終的效果。
SprigCloud 它是一個 Java 的技術語言站。而 AI 服務的語言是多樣化的，有 C++、Java，甚至有 PHP。
為了實現跨語言，我們引入了 sidecar 技術，將 AI 服務與 sidecar 通過 RPC 去通信，就可以屏蔽語言的特性。
Sidecar 主要的功能有，應用服務發現與註冊、路由追蹤、鏈路追蹤，以及健康檢查。