我今天分享的主題是《阿裡巴巴實時計算平台運維架構演進》。一共分四個部分：
實時計算平台的運維挑戰
統一的運維自動化平台
主動出擊，消除隐患
走向智能化
大家知道最近兩年随着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使用過低而被分在不太正常的組裡，我們可以根據分析發現問題。以上是我的分享，謝謝大家！
原文釋出時間為：2018-07-19
本文作者：楊乾坤
本文來自雲栖社群合作夥伴“
高效運維”，了解相關資訊可以關注“
”。