小米彈性調度平臺Ocean——從PaaS到DCOS

內容來源：2017 年 12 月 3 日，小米資深架構師孫寅在「IAS2017互聯網架構峯會」進行《小米彈性調度平臺Ocean——從PaaS帶DCOS》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方、演講者以及微信公衆號——小米運維（微信id：MI-SRE）審閱受權發佈。

閱讀字數：3244 | 9分鐘閱讀

嘉賓演講視頻及PPT回顧： suo.im/4GX9J0

摘要

本次將爲你們分享小米的彈性調度平臺Ocean以及想過的體系建設歷程。

平臺演進

Ocean起源於2015年年末，當時小米的第一代運維基礎平臺已經成熟，擁有包括監控、發佈、域名、服務器流轉等一系列核心組件。可是咱們不只僅知足於工具型的平臺，還但願平臺擁有PaaS 的能力，進而能夠演進成爲DCOS，甚至是DCBrain。

SCOPE

Ocean SCOPE 圖

圖中綠色的部分表示建設完成，橙黃色是正在建設，灰藍色則是尚未建設或者未完成。

左側部分爲所依賴的基礎架構的組件，右側是但願得到的功能，中間是主要的基礎架構。

Ocean相比其餘的PaaS平臺有兩點不一樣，首先Ocean很注重與基礎設施的聯合設計，保障基礎設施的總體性。其次不一樣於其餘將無狀態做爲主要目標的PaaS平臺，Ocean更重視有狀態服務的PaaS與在此之上建設的SaaS系統與其所帶來的能力。

收益

前四項是全部的PaaS平臺都具有的能力，後兩項則須要和基礎設施配合共同聯合設計才能完成的功能。

PaaS

服務樹

服務樹是很是重要核心的基礎組件，主要定義組件和服務之間的關係。數據結構很簡單，就是爲服務器打TAG，再經過定義這些TAG的順序來展示整個樹的結構。

服務是服務樹內以8個TAG一組定義的全局惟一的服務標識，做爲整個運維基礎設施全部組件的統一串聯的粒度。Ocean每啓一個容器都會在容器內植入docker init進程，把本容器的IP經過打TAG的方式註冊進服務樹，而後經過註冊的動做聯動其它基礎設施組件產生效果。

免密安全登陸

免密安全登陸基於服務樹節點受權，同時每次登陸都須要進行雙因素的認證。Ocean在啓用容器後，同時也會在容器內植入免密安全登陸的服務端，這樣當任意用戶的帳號擁有了某一個服務樹節點的權限後，就能在登陸時完成認證和受權，從而使得物理機和容器的登陸效果一致。

監控——全Push採集

咱們的監控系統叫作Open Falcon，目前已被開源。而全Push採集是Falcon比較重要的設計，全部的監控數據都是經過Falcon-agent推到serever端。這有兩方面的優勢，一方面和彈性環境更加親和， 由於Agent會從部署的位置自動採集數據而後上報。另外一方面使設備具備策略自發現能力。

自動擴縮

自動擴縮經過與Open Falcon對接完成。Falcon會自動採集CUP IDLE、MEM FREE、PROC QPS、PROC DELAY這四個基礎指標，以此來提供自動擴縮的能力。

當某個用戶要基於某個指標進行擴縮，就會自動的爲該條指標添加一條集羣監控策略。當監控策略知足預值要求時會自動經過HooK方式回調Marathon API完成自動擴縮。目前咱們最短5s觸發伸縮。

日誌查詢

雲原生環境與物理機運行不一樣，在物理機不管出現什麼問題均可以在原先的位置查看日誌，而在彈性環境中容器掛掉後，要從整個資源池找回已經掛掉的容器的日誌是比較麻煩的，即使找到了也很難暴露給用戶查看。

所以咱們採用了ELK的解決方案，並將其中的L改爲更輕量的客戶端FileBeat。若是FileBeat運行在容器上，一旦容器掛掉後，FileBeat的一些日誌就會來不及傳輸，因此咱們將FileBeat運行在物理機上，同時在容器退出後延遲清除容器。

咱們還制定了用戶日誌目錄規範，經過修改FileBeat讓它與目錄的規範相配合，自動爲日誌添加標籤數據。

動態環境引入新問題

服務發現

雲原生若是沒有服務發現整個彈性環境就沒法動態起來，對於服務發現，不一樣類型的服務獲得的最佳實踐也不一樣。通常業務的程序會使用比較成熟的RPC框架，而對於第三方開源組件每一個都會有不一樣的最佳實踐。

動態安全

不少時候有些業務的數據或接口有很強的敏感性，在物理環境下咱們會使用IP白名單的方式進行認證受權以及保障安全。可是這種方法在動態環境下並不適用，因此要提供一種在動態環境下的動態安全的解決方案。

假設在模型中客戶端被部署在Ocean平臺內，Docker init會把這些運行在Ocean平臺的Job對應的IP和Job信息註冊進集羣 ，這時服務端就僅需嵌入白名單SDK和配置客服端的JobName，還能夠經過IP加JobName共同防護ZK故障。

MySQL方面也存在動態安全問題，一般狀況下咱們會對庫和IP進行受權，而動態環境下則要考慮如何進行動態IP受權。 與以前不一樣，數據庫並不須要用戶去植入SDK，可是要新增數據庫實例受權的過程。咱們這裏是將Docker init和AppA Proc做爲認證信任源，Docker init會向MySQL Auth宣告本身所屬的Job，接着MySQL Auth會到Marathon內查詢來源IP與JobName匹配狀況，匹配成功認證經過。

DCOS

ELB（負載均衡）

建立ELB時須要綁定Ocean的中一個Job，當Job部署到Ocean後不管實例IP發生任何變化，咱們都要作到LVS相應的RS都要跟隨變動。

所以咱們每建立一個ELB其實都會同時建立一個域名，而且按照運營商自動劃分線路，這樣就能讓用戶在使用時不感知的獲得最佳實踐，同時節省帶寬資源。另外docker-init和ELB服務都會動態更新LVS配置，這主要是爲了讓ELB服務的可用性依賴降低。

DBaas

在彈性環境下無狀態服務都相對簡單，改造也很是容易。可是有狀態服務就存在不少麻煩的地方，例如數據狀態須要遷移、服務發現的最佳實踐也要植入。所以咱們將這些有狀態的服務抽象成服務化組件的形態，讓用戶能夠方便運行一個服務集羣。

當用戶經過提交參數建立MySQL集羣時，會由Manger模塊提供所要建立的數據庫原信息數據給Marathon，而後在Marathon內建立DB APP Group，這個Group中會有DB Proxy 和DB 兩種App。

在啓動時候DB APP內會經過搶鎖的方式產生三種角色，這些角色再經由所提供的配置運行起來。

DB Proxy APP在運行的時候會自動感知到搶鎖獲得的角色，並接收流量和配置。最後經過Mesos-Dns將 DB Proxy的域名暴露給用戶。

整個流程中會使用Zookeeper自動恢復數據包括主庫切換等一系列的事。

緩存服務

緩存服務通常使用分片方式，可是每一個分片保存一個實例的話，當前實例掛了就會形成緩存失效，還會穿透到數據庫，對業務產生影響。

理想的解決方案是每分片多副本。而咱們提供了Memcached和Redis兩種緩存服務，因爲Memcached自己不支持每分片多副本，因此要在此之上引入Memcached Router。Redis則能夠直接使用Redis cluster。

故障自愈

故障自愈用到了開源框架StackStorm，它是事件觸發自動化處理的框架。

整個過程當中由Sensors收集信息源，Rules完成須要統計計算或者判斷觸發的邏輯定義，當觸發時隨之啓動一個Workflows,每一個Workflows對應一組Actions。另外中心還有着能夠貫穿全部模塊的Audit模塊，可以知道整個生命週期內所發生的狀況。

在實際的建設時咱們會將內部可以產生信息的基礎設施做爲輸入對接到StackStorm中，StackStorm內的觸發組件則對接到咱們內部的控制系統。