講師簡介
楊乾坤
2012年加入阿里，先後在阿里巴巴技術保障部、技術架構、搜索事業部任職，現任職於阿里巴巴計算平臺事業部，主要負責大數據相關的運維和運維平臺的開發。
前言
我今天分享的主題是《阿里巴巴實時計算平臺運維架構演進》。一共分四個部分：
實時計算平臺的運維挑戰
統一的運維自動化平臺
主動出擊，消除隱患
走向智能化
實時計算平臺的運維挑戰
大家知道最近兩年隨著AlphaGo的興起，算法成為各個公司，如阿里巴巴、騰訊重金投入的場景。實時計算平臺包括實時計算、流計算。
它在搜索、推薦、廣告、監控方面，對於實時的反饋效果的提升有非常大的幫助。實時計算最近兩年火起來，其面臨著與在線服務和離線計算不一樣的一些挑戰。
在去年雙十一時，阿里的實時計算平臺服務了20多個BU、有1K多的 Job、近萬臺機器，其計算峰值達到了4.72億QPS，大家在雙十一當天看到的阿里巴巴對外提供不斷滾動的大屏，其計算峰值達到1.8億QPS。
關於實時計算、離線計算和在線服務的差異。離線計算對 SLA 的要求不高，分鐘甚至小時的延時都是可以接受的。
實時計算就要求必須達到秒級，不得出現一分鐘卡頓的情況。大家比較熟悉的在線服務必須是毫秒級或者微秒級的要求。
針對不同的情況，容災方式也不一樣。在線服務需要有異地雙備或者多地單元化部署，保證能隨時互切。對於實時計算，它只會針對個別核心業務做雙備，大部分業務只有一個運行實例。
離線計算幾乎沒有雙備。針對這種容災方式造成資源利用率的不同。在線服務要保障隨時互切，資源利用率，比如CPU不能超過40%。
實時計算和離線計算對資源利用率有更高的要求，必須達到70%-80%以上，甚至達到90%以上。
現在實時計算面臨幾個挑戰：
第一，集群異構情況。我們的機器每年在更新換代，今年的機器和去年的機器相比，CPU和內存的提升，會導致集群機型的異構；
第二，熱點的情況。在離線計算的挑戰不大，可以接受一個小時或者幾分鐘的延時。對於實時計算來說，一旦出現熱點，必須能夠馬上進行實時自動化處理，否則會影響整個服務；
第三，軟硬件故障導致服務的可用性；
第四，資源利用率的提升對於穩定性的挑戰非常大。實時計算和離線計算對於資源利用率的要求幾乎一致，要達到80-90%的利用率。
統一的運維自動化平臺
這是阿里巴巴實時計算的平臺和運維架構的情況。
最下層是運行環境的管理，我們主要通過阿里自研的IDC系統以及大數據平臺自己做的代碼系統，做物理機和Docker的硬件管理，包括硬件的運行。往上一層對應存儲層、調度層、引擎。
我們的存儲主要有HDFS、HBase、Pangu。在調度層主要是Yarn和我們自研的Fuxi。在引擎層是阿里巴巴基於開源的Blink打造的引擎。
在運行層的管理，我們通過 Aquila 做了管理。Aquila 是我們基於社區開源做的企業版服務。之所以叫Aquila，因為類似像Hadoop、HBase等，是以動物的形象展現給大家。Aquila是我們在網上搜索到的非洲野生動物園，我們想通過Aquila 把類似Hadoop、Blink 的生態系統，將其全部管理起來。
阿里巴巴的開發平臺目前主要是StreamCompute 和 Porsche。
StreamCompute已經在阿里雲公開對外輸出，如果大家對實時計算感興趣，可以到阿里雲的官網做試用或者採購。
最上面一層實時計算支撐整個阿里的業務，包括搜索、推薦、廣告、大屏。整個的開發和應用層是通過阿里計算平臺事業部開發的 Tesla 系統做業務的管理和運營。以上是目前阿里實時計算的平臺架構和運維體系。
DAM 主要做的包括四部分：
硬件檢查。
故障預測。我們依賴很多底層算法及大數據相關的技術。
故障修復。機器自動化故障處理，自動化的提交報修單，囊括提報修單、現場維修、重新交付。
硬件運營。對於底層硬件運營情況的展示，包括資源利用率、機器上線情況，同時另一部分的工作是做多種機型故障率、維修時長等運營工作，可以幫助我們發現每種機型或者同機型不同廠商之間的硬件故障率，對我們後續硬件的採購產生影響。
Aquila，目標是把Aquila從工具到產品的升級。我們需要提供對運維自動化有幫助的能力，包括以下幾點：
運維操作百屏化；
服務統一的運維規範和模式；
可持續集成能力；
對自動化操作的支持能力。它能提供完整的API供外部接口做調用，支持自動化的操作。
Aquila：概念和功能需求的劃分為以下幾點：
第一，Stack管理。一組特定版本的服務集合，它本身有版本的概念，比如1.0-1.1中間的差異可以是其中某一個 Service 版本的變化或者多個Service版本的變化，通過Stack管理來做整個集群的升級管理。
第二，配置管理。我們面對的是集群管理異構的情況，所以它必須支持機器配置分組管理。配置代碼化，通過Git管理，有版本概念，支持Review和回滾。
第三，自動化方案。一是要支持完善的API，能夠做自動化的擴容，機器從故障預測、下線、機器修復和重新上線的自動化流程；二是支持服務的自動拉起和維持，現在集群會出現一些異常，它要保證隨時把停掉的進程拉起來。
第四，是通用接口。
Aquila設計和實現。其底層依賴DB，Server層包括幾部分，一是Heartbeat Handler，它負責和Agent通信；FSM是狀態機的管理。在Aquila裡，各種服務的管理是通過狀態機進行的。
Action Manager、Coordinator、Stage Pianner 負責從請求到生成對應的操作流程。 Agent和Server通信方式是由Agent主動發起，Server 端的命令下發、監控是通過 Heartbeat respond 方式完成，包括 Agent 監控的信息、動作執行情況，全部以主動向Server彙報的方式進行。
相比於開源社區，Aquila提供以下優勢：
服務更穩定
支持Server的HA架構，保障server的高可用。開源社區【英文】是單點服務，包括DB、Server。我們在此之上做了一個改造，就是HA的架構。保證我在一個Server掛掉的情況下，不影響整個集群的操作。
DB採用阿里雲數據庫，能夠保證數據的安全性。
增加配置Review流程。該流程可以保證我們的配置經過對應的開發、QA，做Review後的配置，才能分發到整個集群裡。
Bugfix達到100+。
這是我們改造後HA的情況。我們的後臺是RDS，RDS可以在出現故障的情況下做無縫遷移。在Server端，我們支持兩個Server，這兩個 Server 通過Zookeeper 保證一致性，保證只有一臺 Server 在運行狀態，另一臺準備狀態。
Agent的通信類似Hadoop的工作方式，當它向其中一臺Server發起通信受阻情況下，它會主動去另一臺做重試。通過這樣的方式來保障Aquila的高可用。
這是改造後的配置管理情況。我們通過Aquila WebUI或Json IDE發起配置變更，我們的配置保存在Git上。不管你是通過Aquila WebUI還是Json IDE，都會生成Review Borad。
這個Review是通過Facebook提供的開源工具來做，它已經集成到阿里的系統上。生成Review後，我們可以通過對應的開發和QA Review後，才可能進到Git。
只有進入Git才有可能被Aquila Server接受，下發到計算平臺的集群裡。大家看到的不是特別大或者特別複雜的改造，這對於生產環境來說，是一個非常重要，而且是必須要做的事情。
Aquila優勢：管理更高效。我們做了很多管理上的改造，讓整個集群的管理變得更高效。
Stack的管理。我們對Stack依賴管理重新設計，整體更加簡潔。我們原來會做得【英文】非常複雜，1.0有一個基礎，1.1某一個服務做了改動，其他的都會改為對1.0的依賴。這對於整個服務管理非常複雜，我們要對其中一個服務做操作上的改動，所有的Stack1.0、1.1要重新升級。改造後，Stack1.1-1.0的依賴類似拷貝的過程，從1.0-1.1做升級，對應做版本變更、操作變更，使整個依賴變得更加簡潔，對於我們的操作更加友好。
比較大的改動是我們的集群管理，支持多集群管理功能。Aquila Server的部署是一個比較複雜的過程，包括它的依賴情況。我們在此情況下做了多集群管理功能，一臺Aquila可以管理整個生產的多個集群。
我們增加配置導入導出的流程，方便我們做新集群部署，我們所有已經Review好的配置可以從GitLab上直接導入集群，做配置的複用，直接配置新集群。
支持機器自動註冊和服務自動部署，支持Docker服務自動部署。這是針對阿里現在的大環境做的，阿里在做統一調度系統，阿里所有的業務都要進容器。我們如何做服務擴容，我們要向一層調度，申請一部分資源。它反饋給我們的是Docker容器。我們做自動註冊服務，Docker只要把Aquila拉起來，我可以通過Server中的配置自動把服務拉起。
流程優化達到30+，包括部署嚮導、Batch升級、Rack信息導入等。
這是服務自動註冊和拉起的情況。Tesla是我們的大數據業務運營管理平臺，它可以探測我們集群的水位情況，水位是否超過我們預定的80%，如果超過，我們可以主動向阿里資源管理一層調度平臺 Sigma做資源申請。
申請下發後，如果Sigma可以滿足我們的資源申請，它會主動把容器拉起來交給我們。
我們拉起時做了一個動作，把對應的 Aquila Agent 拉起來。拉起來後，Aquila agent 會自動向 Server 做彙報，完成彙報後，Aquila Server 可以根據自己在服務端的配置，比如針對Docker需要部署的服務有哪些，它屬於哪些配置分組。
在這種情況下，Aquila Server 會下發部署和配置更新的命令，把 Agent 和容器內的服務部署好後，向 Sigma 返回，Sigma 知曉情況後，會向運營管理平臺做最後的確認。完成從水位檢測到資源擴容的整個自動化流程。
Aquila的優勢：服務接入更開放。
Stack 和 Server 做打包分離，加快 Stack的迭代，讓服務接入更方便。
我們對 Service 的 Meta 文件進行拆分，將版本信息、操作信息、依賴信息分離，Stack升級更加靈活。如果我們要對服務做操作方面的改造或者升級，它不需要專門做Stack的升級便能完成。
我們支持更靈活的安裝方式和源，如Rpm、Tar、Git、Oss等。
Aquila優勢：性能更高。我們在性能方面做了很多的改造，目前從 Aquila 社區看到，單集群支持2500+機器。現在我們通過對數據庫表結構的優化及Host管理優化，單集群可以支持 5000+ 機器和單 Server 支持 50+ 集群。其他性能優化 20+，包括鎖優化、事件管理優化及前端框架的優化。從整個平臺看來，有了 Aquila後，我們可以依賴這個產品做很多自動化的工作。
這是Tesla在業務運營層面的，統一的大數據運營平臺，包括業務中心、平臺運營和工具服務。
運維運營平臺提供分站開發框架、資源整合相關管理、運維數據化的支撐、智能分析工具，它的功能涵蓋業務中心、服務管控、平臺運營、工具服務、運營中心和運籌優化。
從運維/運營業務場景來看，它提供故障處理場景、監控分析場景、變更保障場景和值班、大促的場景。Tesla 面向的客戶包括業務開發、一線運維、IDC、財務，它涵蓋資源賬單情況。
主動出擊，消除隱患
這是我們在此平臺上做的自動化保障。對於實時計算平臺來說，機器出現故障，影響業務後再進行處理有比較大的風險。
我們通過引入DAM做硬件預測，在預測到故障時，主動通過 Aquila 完成服務的下線，把機器交還給 DAM，做硬件自愈，自愈完成後重新加入到集群中，形成一個完整的閉環。現在在運營工作中，我們不再需要主動做硬件故障管理的工作。
資源自動化擴容，Tesla 探測資源水位，在水位緊張的情況下啟動向 Sigma 的資源申請。通過容器做自動註冊，完成服務部署，最後加入集群，進行調度作業。
走向智能化
我們現在在做智能化的探索，實時計算對故障的要求比較敏感，我們在做異常分析。可以看到 Metrics 是時間序列的數據，像 ETS、EWMA 做預測，通過Sigma 做模型的生成。在模型生成中有參數是通過深度學習的方法，不停的做校驗。
下面是無監督機器學習的過程，包括特徵工程、基於密度和樹做LOF、DBSCAN，通過異常報警和人工反饋情況調整參數。
具體場景是機器熱點分析，我們通過 Metrics 的採集，做密度聚類，最後生成三個結果，一是 PCA 降維後的分組圖，它會歸類哪些機器可以歸到一個分組，另外的是不太正常的狀態；二是數據化的歸一，哪些分組的指標不一樣；三是指標明細，哪些分組發生哪些數據。
這種情況對我們的應用場景，在集群異構的情況下，由於配置的原因，我們難以發現機器積累的問題。比如一臺 64 核 256 G的機器，我在配置資源時出現配置錯誤，如配了10 核 128 G。
我們通過傳統的監控不太容易發現其問題。傳統監控，我們會配置這臺機器的CPU 超過多少，再做報警。
這不太適用我剛才所說的，我們可以通過聚類的分析，發現離群組的情況，它是因為CPU使用過低而被分在不太正常的組裡，我們可以根據分析發現問題。以上是我的分享，謝謝大家！
說明：本文根據 GOPS 2018 深圳站 楊乾坤老師的分享整理而成。
錯過 GOPS 2018 深圳站？GOPS 2018 上海站與您不見不散！
GOPS 2018 上海站 阿里專場精彩議題一覽：
意不意外，精不精彩？
閱讀更多 高效運維 的文章
