作者 | 劉東東，好未來AI中台技術負責人
前言
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 主要的功能有，應用服務發現與注冊、路由追蹤、鍊路追蹤，以及健康檢查。
今天我的演講到此結束，非常感謝各位的聆聽。謝謝大家。