from:?http://geek.csdn.net/news/detail/97887

聲明：本文為CSDN原創投稿文章，未經許可，禁止任何形式的轉載。?
作者：袁曉沛，目前在七牛云的主要工作是基于容器平臺構建分布式應用，借助容器的優勢，實現大規模分布式應用的自動化運維以及高可用，以PaaS服務的形式提供服務器后端應用，同時致力于讓開發者從繁瑣的后端運維工作中解放出來。曾參與盛大網盤EverBox、EMC備份服務Mozy后端存儲的設計、開發工作，主要方向在分布式系統的架構設計、開發、性能調優以及后期運維優化。?
責編：錢曙光，關注架構和算法領域，尋求報道或者投稿請發郵件qianshg@csdn.net，另有「CSDN 高級架構師群」，內有諸多知名互聯網公司的大牛架構師，歡迎架構師加微信qshuguang2008申請入群，備注姓名+公司+職位。

七牛云研發架構師袁曉沛日前結合七牛云自定義數據處理平臺業務的容器化實踐，從平臺的業務特點、為什么容器化、如何實現容器化以及容器實踐的具體效果等角度進行了分享。以下是對他演講內容的整理：

數據處理業務簡介

數據主要有三種處理方式：

官方數據處理：?
提供基礎的數據處理服務，包括但不限于圖片的轉碼、水印、原圖保護、防盜鏈等，以及音視頻的轉碼、切片和拼接等。

自定義數據處理：?
允許用戶構建、上傳自定義的私有數據處理服務，并無縫對接七牛云存儲上的數據以及其他數據處理服務。

第三方數據處理：?
一個開放的應用平臺，提供大量功能豐富的第三方數據處理服務，比如圖片鑒黃、人臉識別、廣告過濾、語言翻譯、TTS 等。

圖 1

圖1是數據處理的一個調用示例。無論是七牛云的官方數據處理，還是自定義數據處理，或者第三方數據處理，都是以這種形式調用的。最左邊的是一個URL，代表一個文件，中間綠色的Facecrop是數據處理命令，右邊的200×200是請求參數。

圖 2

如圖2所示，從左邊的人物肖像圖原圖到右邊200×200的小圖片，這個服務可以把人臉從原圖中剪裁出來。通過管道操作，還可以把圖片再存到存儲中，以后直接使用這個小圖，不需要再走數據處理計算。這是一個典型的數據處理調用。

官方數據處理的挑戰

第一，請求量非常大。目前，系統每天有近百億的數據處理請求量。年底，可能會在目前近千臺的計算集群基礎上翻好幾倍，整個存量、增量都非常大;

第二，突發流量非常頻繁。很多客戶是從其它云遷到七牛云，首次把大量文件遷移到七牛存儲后，往往會發起大量的數據處理請求，這會帶來大量突發流量;

第三，CPU密集型計算。目前后端集群中，絕大部分的機器都是用來跑圖片、音視頻轉碼的，這些都是CPU密集型的計算，這意味著后臺需要很多臺機器，而且CPU的核數越多越好;

第四，IO操作頻繁。IO分為磁盤IO和網絡IO，數據處理前，往往需要先把原始文件從七牛存儲中下載到本地磁盤，所以磁盤IO和網絡IO都很頻繁。

官方數據處理的架構演化

圖 3

圖3是數據處理早期的一個架構圖。當時比較簡單，所有請求都經過FopGate，每個節點上都部署了很多圖片、音視頻或者文檔處理的Worker，是具體做轉碼的計算服務。整個架構，Worker在網關上是靜態配置，增加新的Worker時需要改網關配置重新加載，做起來會很麻煩。另外，請求進來時，對應要處理的數據也是通過網關服務進入，控制流和數據流放在一起，網關整體壓力非常大，當時出了很多問題。

圖 4

圖4是數據處理目前的主體架構。右圖左上角增加了一個Discovery組件，收集Agent上報的信息，Agent和Worker把自己能做什么事都上報到Discovery。每增加新的主機Agent和Worker時，不再需要靜態配置，只需指向的該Discovery服務。網關可以通過Discovery獲取信息，根據進入的具體請求，將這個請求路由到不同的Agent，Agent再把請求轉到Worker處理。Agent組件還有負載均衡的作用，請求會選擇后端相應的節點執行，另外也起到下載文件的作用。下載文件的數據流不經過網關服務，Worker向Agent發起一個下載請求，然后這個Agent到存儲上下載數據，放到自己的緩存中。

這個架構解決了一些問題，但是之前提及的挑戰依然存在。主要的問題是FopGate在過載時依然會崩潰，每個主機會過載出問題，造成請求變慢或宕機。接下來討論一下如何解決這些問題。

如何應對官方數據處理的挑戰

系統測量

第一，測量FopGate的服務能力。按照線上的配置，針對同比例縮小的集群做性能測試，測試出FopGate單機最大的請求數和句柄數，根據實際的業務量，確定機器配置和數量。

第二，測量某種數據處理的資源使用范式。大多數據處理是CPU密集型計算，我們需要找到單個處理的資源使用規律。測試方式如下：取線上約10萬或100萬個請求，針對一臺測試機器壓力測試。比如測Image，測試這臺機器的變量有以下三個：Image 實例數，并發處理數和隊列長度。最終拿到的一個結果是，做圖片剪裁、圖片處理、圖片轉碼等服務，一個進程一個CPU的邏輯核，同時處理一個任務，對它來說是最快的，多個任務同時處理反倒會讓CPU的處理變慢。

第三，測量單實例的服務能力。一個程序實現得很好，可以把多核利用起來。針對這樣的實例，分配多個CPU線程、調大并發、并壓測這個的實例，試圖用10萬個請求看整體處理速度，發現整體處理速度并沒有起多個實例，但每個實例限制CPU線程數、限制并發好。所以最終的結論是操作系統對于CPU的調度，比進程要好；相比起一個大實例、接受高并發請求，我們更傾向于運行多個實例、但每個實例限制并發。

增加隊列

這個主要的考慮是提高服務質量，避免單實例過載。前面得到結論，一個圖片處理的實例，一個核，并發量為1時最快。我們為每臺節點機器加了一個排隊機制，排隊之后不爭搶資源，整體處理速度反而變快。

另外，從運營角度講，可以用隊列長度來區分免費用戶和付費用戶。比如，可以將免費用戶的排隊長度設置得長一點，比如設成10，意味著最后一個請求要等前面9個請求處理完才能處理。而對于付費用戶，可以將隊列長度調短一點，只有3或者5，這樣平均等待時間就變短。總原則是區別付費用戶和免費用戶，免費用戶保證高可用，但是不能保證高質量和低延遲，因為資源有限；對于付費用戶可以保證高質量，因為可以通過排隊長度控制這個事情。

限流

為什么有了隊列之后還要限流？兩個原因：

第一，大量長鏈接影響FopGate性能。因為七牛云處理最多的是圖片、音頻和視頻三種請求。圖片請求往往比較快，高峰期時可能幾秒、幾十毫秒完成，但是視頻和音頻轉碼往往比較慢，可能需要好幾分鐘或者好幾十分鐘，它取決于一個具體的轉碼參數和轉碼時長。如果不限流，網關會維持大量的長鏈接，累積大量句柄，輕則影響的性能，嚴重的情況下會造成宕機。

第二，突發流量，導致隊列過長。隊列太長，有大量任務積壓的情況下，會有任務在處理之前就超時。與其超時，還不如直接限流，拒絕處理不掉的請求。

限流手段有三種：

第一，并發HTTP請求限制。超過這個限制，直接拒絕請求并返回。但這并不是最好的方式，因為超時的請求已經解析處理過，這對于性能是有一定損耗的。最好的做法是用一個信號量控制TCP accept，比如控制信號量個數是1萬個，1萬個請求正在并發處理時就不accept 。這是最好的方式，但實現略復雜。

第二，單用戶請求數限制。有些用戶可能會在特殊情況下發起大量的請求，為了不讓他影響別的用戶，系統會限制單個用戶的請求量。

第三，Cmd數限制。主要指具體某個操作，比如圖片查看，要對Cmd數進行限制。因為不能讓大量同樣的Cmd把資源消耗殆盡，影響其他Cmd的操作。

合理協調IO和CPU

為什么要合理協調？因為數據處理的流程是：下載、寫盤、處理、寫盤、返回，涉及到網絡IO和磁盤IO。整個優化方式總原則是就近計算，將下載和計算部署在一起。目前，新的架構中是混合部署的。本來可以設計，將下載部署在其他機器上，但這樣會增加一次網絡的路由次數。所以，從一臺機器的Agent下載后，直接在本機處理，不會再經過一次網絡路由。另外一種方式是掛載ramfs，直接把下載內容放在內存中。比如內存分8G，下載完成后直接放在內存中，要用的時候直接進內存讀，這樣可以節約磁盤IO的開銷，也能整體加快單個請求處理速度。

前面這些是官方數據處理的一些挑戰、架構演化以及我們采取的一些對策，后面講一下自定義數據處理所面臨的挑戰。

自定義數據處理的挑戰

第一，處理程序由客戶提供，我們不知道客戶在程序里做了什么事情，也不知道客戶的程序會使用多少資源，這意味著我們至少要做兩點：一是安全性，不能訪問到別的資源，二是隔離性，單個程序不能無限制使用資源。

第二，業務規模不確定性，無法估算量有多大。這個帶來的挑戰是業務可伸縮性，需要客戶可控。

基于這三個需求：安全性、隔離性、可伸縮性，Docker非常適合這個業務場景，整個自定義數據處理在14年開始基于Docker實現。

圖 5

圖5是自定義數據處理的業務流程：

第一，用戶要創建一個自定義數據處理，即注冊一個UFOP；

第二，用戶在本機上開發自定義數據處理程序。開發這個程序要遵循七牛UFOP范式；

第三，把這個程序提交一個構建版本；

第四，切換到這個版本，設置實例數。實例啟動后，該UFOP就可以訪問了。

這是迭代的，有一個箭頭直接指回開發自定義數據處理程序，意味著升級程序、構建另一個新版本、切換到新版本實例的一個過程。

業務流程-注冊

圖 6

圖6是注冊的過程，第一個qufopctl是客戶端工具，第二個是reg注冊，第三個ufop-demo是名字，最后-m 2是模式，支持私有和公有模式。

圖 7

圖7是自定義數據處理后端注冊的流程，qufopctl把前面描述的注冊命令，發到ufop-controller，它會進一步走鑒權服務，鑒權成功之后通過Keeper服務存盤到DB。注冊成功后，用戶開始在本地實現UFOP應用。

圖 8

圖8左邊是一個最小的UFOP代碼，簡單來說就是在UFOP請求路由上加一個UFOP請求，拿到待處理文件URL后下載對應文件，然后獲取文件的類型和長度，并作為結果返回。右上角是我們定義的一個描述性文件。2014 年，我們做的時候Docker還沒有那么火，所以沒有直接用Dockerfile，而是自己定義描述模式。第一行是引用源；第二行是構建腳本，把外面的程序改成可寫；第三是執行，怎么執行這個程序。右下角是要打包成tar包的本地目錄。

業務流程-構建

圖 9

如圖9所示為構建命令，是把本地的程序上傳到服務端，并構建一個版本。

圖 10

圖10是構建的后端。整個后端的過程如下：qufopctl把程序tar包上傳到Kodo，發起構建請求，再把構建請求轉發到構建機器，接著把UFOP描述文件轉化為Dockerfile，基于Dockerfile構建Docker image，最后推送到Docker Registry。

下面是構建后端我們踩過的一些小坑。

使用Debian鏡像服務

原先使用AppRox，是Debian包下載、緩存服務，但實際上經常下載超時，而且下載出錯后，自己沒辦法辨別本地文件存在問題，需要手動清除，比較糟糕。后來，搭建了一個鏡像源。鏡像源的做法是首次全量下載，全部下載完畢后，設置一個定時增量同步的時間，在凌晨，一天一次，每天更新的量只有幾十兆，幾分鐘便可完成。從此，再也沒有出現過這方面的問題。

避免Docker構建緩存

圖 11

Docker的構建緩存比較容易出錯。圖11第一個是錯誤用法：第一步，下載一個jdk的壓縮包；第二步，創建一個目錄，將壓縮包解壓到這個目錄，并且把原來的壓縮包刪除。分了兩條命令，但是容器其實會對每一條命令做緩存。

假如我們第一次運行這兩條命令時是沒有問題的。第二次運行時，我們覺得第二條命令中OPT目錄不好，想到另外一個目錄，于是對第二條語句做了更改，那么就會出問題。為什么？因為第一條命令沒有任何變化，所以容器構建系統認為，沒有任何的變化就不去執行，于是直接跑第二條命令，第二條在前一次執行時，已經將壓縮包刪除，因此會跑失敗。這種錯誤很容易犯，解決方法是把壓縮包的下載、目錄的創建、解壓縮和刪除壓縮包，都放在同一條命令里。當這條命令被修改后，每次都會重新執行，就不會出現這個問題了。

調整實例數

圖 12

圖 13

接下來是調整實例數，前面已經構建完成，程序已經上傳到服務器端。qufopctl resize ufop-demo -n 3，這條命令會增加3個實例。

整個后端的過程如圖13所示，qufopclt發送請求到ufop-controller，中心調度器Scheduler下面有很多個node，運行著我們實現的Daemon服務，所有容器都是由Scheduler下發給某個Daemon，這些Daemon啟動對應的容器。Daemon會把所在機器剩余資源的情況，包括CPU、內存和磁盤，實時報給Scheduler，Scheduler會根據實例的規格要求找到相應滿足要求的node。這些容器實例創建成功后，Daemon會把具體的端口信息返回到Scheduler，Scheduler再通過Keeper服務持久化，這樣就結束了。Docker Registry是Docker的鏡像倉庫。

升級實例

圖 14

到前面這一步，UFOP已經運行起來并且可以使用，如圖14所示為升級實例的過程。我們有一個Upgrade的命令，-r是一個實例，現在要做的是升級前兩個實例，后端會發生什么事情呢？

圖 15

圖15所示為一個灰度升級階段。首先原始階段有三個實例，假設每個版本都是V1，現在要升級兩個實例，后端的做法是增加兩個實例，實例4和實例5，這兩個對應的版本是V2，圖15中橙色部分。等V4和V5徹底被啟動后，我們將老的實例刪除，它的結果是原來的一個V1, 兩個V2，整體灰度升級過程就是這樣子。

有些細節值得注意：

第一，新實例WarmUp，往往剛開始很多內部組件沒有初始化，像內存池、線程池、連接池需要初始化，所以初始請求處理得往往比較慢，但是又不能不發請求，因為不發請求永遠熱不起來。做法是設定預熱時間段，定時間段的權重，保證在這個時間段預熱好之后就承擔正常的流量。

第二，老實例CoolDown。如果直接刪除老實例，對服務的可用性沒有影響，因為老的請求正在被處理。做法是：使用Docker StopWait，當用Docker Stop停止一個容器時，它默認的行為是先發一個SIGTERM，如果不指定StopWait時間，就會馬上發一個SIGKILL信號，這樣你的容器將被直接殺死。若一個容器正在處理請求，那么我們希望能有一段時間讓我們將請求處理完后，優雅的關閉，否則會影響可用性。所以使用這個命令時，可以設置StopWait時間，若等待超過設置的時間，卻發現容器沒有優雅關閉，再發SIGKILL信號。另外在業務層面，老實例在CoolDown時，應該設成一個關閉中的狀態，避免新的請求再打進去。

第三，保留足夠的計算冗余。這個是如何考慮的呢？因為升級需要考慮步長，如果升級的步長大于計算的冗余實例數，意味著剩余的等待實例會承擔更多的請求，多于預期的請求會影響服務的質量，因為請求的時間會變長。所以選用的升級步長應該小于冗余的實例數。

數據流

圖 16

剛才講的是控制流，包括如何注冊、如何創建一個新的實例。而這些數據流的請求過來是什么樣的？這涉及到一些內部組件，即云存儲的服務器。服務器后面有數據處理，自定義數據處理會從之前說的狀態服務中獲取某一個后端實例列表，由它做負載均衡傳給后端。在后端數據流的維度上，每臺機器還有一個Fetcher，它接收到請求后會把請求路由到本機，并執行實例。同時，它會做數據下載的工作，我們出于對用戶隱私安全的考慮做了一些混淆，不允許他直接下載，而是轉化成本地的。這是數據流的流程。右邊有一個組件叫DiskCache，是一個緩存集群。

圖 17

圖17是數據鏈路的V2版本，是一個思路，還沒有完全實現。唯一的改動是在實例之間加了一個隊列，當然這個隊列是可選的。當前所有請求都放在這個隊列中，由UFOP實例獲取請求，處理完成后將結果返回，這是一步處理的過程。這個隊列有什么作用？前面提到，調整實例可以做手動伸縮，沒有說自動伸縮。而這個隊列可以做自動伸縮。

自動伸縮設置

自動伸縮需要用戶做一些配置，一個是默認的實例數，也就是第一次用戶上傳一個自定義數據處理的版本，上傳完成后調整實例數，調整成10個，還要設置一個平均單實例待處理任務數的配置，假如，這個設置是10，當隊列里面有小于100個待處理任務數時是不需要伸縮的，但是當隊列里面的任務數大于100，比如到110就要伸縮了，因為單個實例平均待處理的任務數已經超過，這個時候再增加一個實例是最適合的選擇。通過對隊列的監控，可以達到自動伸縮。

自動伸縮的后端

圖 18

圖18是自動伸縮的后端。最上面中間有一個Scaler組件，會實時監控隊列長度，拿到每個隊列的配置，即平均單任務待處理任務數。它根據這兩個信息，可以實時地發出調整實例的請求，比如平均單任務處理數超過預想時，它可以自動增加一個實例，并告訴調度器，調度器會找相應的節點啟動實例，啟動后告訴Keeper，Keeper會把這些信息記錄下來。回到前面的數據流，及時從里面獲取信息，達到自動伸縮的目的。

如何應對自定義數據處理的挑戰

解決方案：

第一，安全性。這一部分做法比較簡單。自定義數據處理單個物理機上的容器數約幾十個，這與CPU的核數有關。可以設置某個范圍的端口不互訪，以達到容器不能互訪的目的，從而獲得安全性；

第二，隔離性。可以限定某一個容器只用指定配額的CPU和內存，這取決于用戶的配置；

第三，可伸縮性。首先實現了一個簡單高效的容器調度系統，它是支持秒級伸縮的；其次是暴露伸縮API，用戶可以手動伸縮達到伸縮目的；最后是利用隊列長度，達到自動伸縮的目的。

總結

以上是生活随笔為你收集整理的日均请求量百亿级数据处理平台的容器云实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。