【51CTO.com原創稿件】2018年5月18-19日，由51CTO主辦的全球軟件與運維技術峰會在北京召開。來自全球企業的技術精英匯聚北京，暢談軟件技術前沿，共同探索運維技術的新邊界。而在本次大會上，除了眾星云集的主論壇環節，12場分論壇更是各具特色，在19日下午的“微服務架構設計”分論壇上，來自餓了么計算力交付部資深工程師李健先生發表了精彩演講。

作為餓了么企業內部多個基于容器的云計算項目的開發負責人，李健擁有多年豐富的容器系統建設經驗，推進了餓了么平臺容器化進程。尤其擅長將容器的敏捷性和標準化進行企業級落地。為應對萬物互聯時代持續計算帶來的機遇與挑戰，李健致力于打造更加便捷的計算力服務，促進高性能計算、大數據和云計算等多元計算模式的深入融合。

餓了么計算力交付部資深工程師李健演講

李健此次的演講主題是“eleme容器平臺”，這個平臺是基于容器的一個管理系統，談及管理系統，李健認為，雖然現在公有云比較多，但大家都要面臨的一個場景就是混合云。他的演講主要分為四個部分，即計算力交付、技術選型、算力外賣和基于kubernetes的拓展方案。他坦言，最初在業務快速增長的過程中，資源規模增長非常迅速，導致我們服務器的類型特別多，管理的任務也很重。因為要適應業務，交付的需求也多種多樣。

一、計算力交付

李健認為，計算力交付作為一個抽象的概念，實際上是我們把物理資源抽象出來的一種輸出，是對于開發人員的一種輸出。餓了么的物理資源，訊息資源量很大，人力有限，我們不可能無限的去擴張，于是我們就想實現一種方式，將它標準化，這樣可以極大的減少成本，也可以更輕松的去管理更多機器?；谝陨?，我們計算交付部門出現了。我們認為一切的交付行為都是應用，所以餓了么面臨的關鍵變成了怎么樣去交付這個應用，怎么去管理這個應用。

    說到這里，就不得不提容器技術。容器技術很早就出現了，Docker為容器做了很大的貢獻，它真正面向了應用，可以移植，可以跨平臺的特性，特別是它打包方式，使得所有的服務，都變成一種統一的打包方式。這就是應用的一個標準，在這種標準之上，我們可以把這個應用跑在我們想跑的任何一個平臺上。只有這樣的話，我們才有可能進一步的去做到，不論是自動化運維，還是AIOPS或者是大數據等等，這些更加的降低人力成本，提高資源使用率的目標。

    具體看來，我們會交付三個事情，首先是用戶數，就是你把應用交給我，我來幫你部署，讓服務跑起來。其次是標準服務的一鍵交付，比如大數據需要一套環境，或者某某部門他需要一套環境，一套環境里面他包含了ABC很多服務，這些服務和其他服務有隔離性，服務之間又必須建立起一種聯系，而且具有可復制性。第三是服務器的交付，其實也被劃撥進來。開發需要一臺服務器，這個時候我們就很好的可以將計算力作為服務器的一種交付。

二、技術選型   

技術選型現在有很多,kubernetes是比較風靡的一種，選擇kubernetes即是建立了標準，它帶來的利好就是成本下降。當我用跟別人一樣的東西，我成本下降了，解決問題時的優勢不言而喻。如果我選熱度很高的項目，這個項目，首先對于我中小公司來說，我遇到問題至少可以在谷歌上，可以查到這個問題，有據可依。另外還考慮到的一個場景，即你需要的東西和你的選型是否契合，這也是非常值得關注的問題。此外，擴展性、生態發展、大公司的容易建立起生態，亦有前瞻性可循。

三、算力外賣   

談起算力外賣，李健津津樂道。據他介紹，餓了么做外賣，有好多東西容易要跟吃的結合起來。例如我們會議室可能叫“榴蓮酥”。算力外賣我們需要的就是一個場景，例如說我們去飯店吃飯，這就是一個場景。再比如說一個開發環境，在使用完了這套環境之后就可以銷毀了，或者我可以點一個套餐，點一套“環境”，好像我們去訂外賣，購買一個套餐一樣，包含很多內容。

    在應用層面，李健把它描述得跟我們的胃口很像，包括各種不同類型的服務。所以會有這樣一個box，box實際上可以把它抽象成一桌飯或者是一個外賣盒。在這里面我們可以看到，我們把每一個服務相互之間的調用，都通過domain去調用。而且這個box它有復制性，無論從這個模板里面創建出來box有多少，在每個box內部調不同服務的時候，它的域名是唯一的。

    例如，從第一個服務調第二個服務的時候，第二個服務的域名是JOB，第一個服務調第二個服務的時候它從B就可以調用，這樣就減少了開發人員復雜度。我們啟用個服務的時候，自動給它生成唯一網絡標識，可能是IP或者域名。想要更改我的配置，不需要更改它的配置，只需要把這個環境拉起來，這個應用就可以跑起來了。因為我的配置，我所對應那些服務，他們的網絡標識是一樣的，他們都是叫X。

四、基于kubernetes的拓展方案   

李健演講的最后一部分是“基于kubernetes的拓展方案”。其具體的實現就是用kubernetes去做底層的容器引擎。在里面可以看到，在一個Internal里面，包括domainl，pod我們可以在這個服務，它有自己的一個副本，做一個副的均衡。這些服務之間可能有依賴關系，例如A服務依賴B服務，如果B服務宕機，A服務要做一些處理。A服務依賴B服務，會有個啟動數，我們在box里面也做了同樣的事情。

    當然從技術發展來講，很多時候大家認為，新技術里面，不應該有依賴關系。但是我們現在遇到的問題，確實存在依賴。我們的服務業務在這個場景下，要推動標準化就一定要兼容開發的目前的一些項目或者它的習慣。

    還有一些服務啟停，那就是初始化。比如說有些服務完成之后會調另外一個pod進行初始化。還有一些公共服務，有些數據是需要傳遞的。我們就可以把外面的服務，通過內部標識轉換到外部標識，我們內部標識實際上是永遠是不變的，外面關系通過服務發現或者機制關聯上來，這樣就完全的不用考慮配置變更，或者服務發現等等問題了。

這個是我們的一個最簡單的通過外賣的方式對我們服務的一個抽象。當然了我們在這個過程當中會考慮我們服務的規模，規模擴大后會發生什么問題。kubernetes依賴etcd，etcd，我們知道它實際上在kubelet場景下，它支持不了那么大規模，但是我們又對穩定性有一些要求。所以我們就只能說把它進行拆分，盡量的進行拆分。

如果我們人為的通過三個或者四個kubelet機群給它拆分了，如果拆得太細，資源利用率就會降低，有些機群可能餓死了，有些機群可能飽死了。我們就是通過一種方式，我們希望說讓這些服務，kubelet是不同的etcd這個機群，有一個方式讓服務可以在機群之間進行飄移，可以調度。這樣既解決了資源效率的問題，又解決了可靠性的問題。

從上圖的結構看來，除了黃色的部分，其他部分就是kubelet原先的一些組件。我們開發了一個類似于kubelet的API Server的服務。按照我們本來的想法，例如我現在調度完成之后，分兩級調度，我們以為把資源調到A機群還是調到B機群就可以了，后來發現實際上很難做到。我們在現在使用的docker上加了一個小版本，小版本主要問題是，日志量很頻繁的時候（毫秒級別）就會亂序，導致業務部門排查不下去。因此我們在docker里面增加了一個序號。

     李健坦言，我們企業的軟件環境，實際上是自己生長出來的，我們不可能因為一個開源軟件更改現有的內容，我們希望通過某種方式讓開源軟件來適應現在的軟件狀態。這就是docker的一些監控，例如我們發現一些問題或者bug，都是通過監控來發現的。

    此外，我們在容器管理當中，如果遇到一些問題，比如說將傳統的業務進行容器化的時候，我們就進行改進。所有的東西都是在容器里面，internal進程是我們定制的，internal進程是切換技術層管理的一些目錄和環境變量，另外一個是基礎配置文件的一個宏代換替換。我們服務在跑這個的過程當中，有些服務遷移，以前是配置的，現在改成了容器。在環境變量里面，把這個配置從環境變量里面讀，可能會產生一些成本。所以我們提供了一種方式，把變量寫在里面，會根據容器這些環境變量自動替換這個配置。特別是在容器環境里面，如果這個容器沒起來之前，不清楚它的IP，問題就必須在internal進程里面去解決。

本次WOT峰會講師演講稿件由51CTO采編整理，如欲了解更多，敬請登錄www.jxzklqfsx.com進行查看。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】