在CaaS系統(tǒng)出現(xiàn)前企業(yè)應(yīng)用架構(gòu)基本被IaaS/SaaS/PaaS等模式壟斷，直到Docker的出現(xiàn)為我們打開了另一個扇大門，廢話不說了，我們直奔主題。

我們先了解下一個簡單的CaaS系統(tǒng)是如何為用戶提供服務(wù)的：

1. 企業(yè)用戶上傳它的應(yīng)用代碼或其他代碼托管方式，我們生成用戶應(yīng)用的鏡像，或者用戶直接上傳鏡像,或者用戶直接使用我們提供的基礎(chǔ)服務(wù)鏡像
2. 用戶部署他的鏡像應(yīng)用，啟動它的鏡像容器
3. 用戶訪問他的應(yīng)用服務(wù)
   

OK，需求確定了，該搬磚了。

用戶鏡像制作

既然是一個簡單的CaaS系統(tǒng)，我們就不讓用戶上傳代碼或者使用第三方代碼托管了，直接讓他們制作鏡像后提交給我們，為此我們需要搭建一個Docker私服來讓用戶上傳鏡像，假設(shè)用戶上傳的鏡像遵循這種格式 :docker 私服地址 /{appId}:{version} ，這對用戶有一定要求，畢竟一些用戶可能連Docker是啥都不知道就更別奢望讓他們編寫Dockerfile制作鏡像交付給我們了。當(dāng)然如果我們提供一些基礎(chǔ)服務(wù)鏡像（比如MySQL服務(wù)，Redis服務(wù)等）給用戶那最好了。

啟動用戶鏡像

有了用戶制作的鏡像，該是啟動它的時候了。

docker pull docker私服地址/{appId}:{version}

docker run -d docker私服地址/{appId}:{version} 

啟動方式很簡單，但這并不是我們想要的，畢竟我們是要讓用戶能夠訪問到他部署的服務(wù)的，假如用戶的服務(wù)是一個Web服務(wù)，那你得暴露出用戶的Web服務(wù)端口，這需要我們確定容器的通信方案：

1. 跟宿主機共用一個網(wǎng)絡(luò)空間
2. 發(fā)布一個容器端口，讓Docker隨機選擇一個未使用的高位端口
3. 發(fā)布一個容器端口，并映射到宿主機上指定端口為外部路由服務(wù)
4. 采用Docker的'links'來允許容器間通信。 如果一個新容器鏈接到一個已有容器，新容器將會通過環(huán)境變量獲得已有容器的鏈接信息，一個關(guān)聯(lián)的容器將會獲得它的對應(yīng)連接信息，在它處理了那些變量后允許它自動連接。這樣就使得同一個宿主機上的容器不需要知道對應(yīng)服務(wù)的端口和地址，就可以直接進行通信
   

我們簡單的CaaS系統(tǒng)暫時還用不到容器間通信，如果跟宿主機共用一個網(wǎng)絡(luò)空間即 --net="host" 模式啟動的話，那么如果有多個用戶上傳了鏡像，他們的WEB服務(wù)端口都是8080，顯然宿主機上只能啟動一個8080端口，只能有一個用戶的容器啟動成功，其他的因為端口已經(jīng)被占用導(dǎo)致啟動失敗，在這里我們選擇第三種模式，選擇指定的端口映射來發(fā)布容器，這也方便我們后面管理宿主機上的端口資源。OK，啟動方式改成下面：

docker run -d -p 25701:8080 docker私服地址/{appId}:{version} 

為了不讓某個用戶的應(yīng)用占用過多資源導(dǎo)致影響到整個宿主機上其他的應(yīng)用，我們稍微對用戶的資源進行下限制，比如限制用戶應(yīng)用容器的使用內(nèi)存和CPU權(quán)重：

docker run -d -p 25701:8080 -m 512M -c 1024 docker私服地址/{appId}:{version} 

為了能做到水平擴展，容器服務(wù)最好是無狀態(tài)的的，這樣能更好的實現(xiàn)負載均衡和水平擴容。

應(yīng)用啟動成功，我們可以通過在宿主機上訪問25701即可訪問容器的8080端口服務(wù)。

在寫代碼的時候我們通過 Docker Remote API client libraries 來啟動卸載容器，具體代碼實現(xiàn)就不多說了。

服務(wù)發(fā)現(xiàn)

容器啟動成功后，用戶該如何訪問到他的容器服務(wù)呢，總不能提供宿主機IP給用戶直接訪問吧，這就需要我們構(gòu)建一個服務(wù)發(fā)現(xiàn)組件了。

服務(wù)發(fā)現(xiàn)的工作方式

當(dāng)每一個服務(wù)啟動上線之后，他們通過發(fā)現(xiàn)工具來注冊自身信息
服務(wù)的消費者能夠在預(yù)設(shè)的終端查詢該服務(wù)的相關(guān)信息，然后它就可以基于查到的信息與其需要的組件進行交互
為了簡便，我們使用ZooKeeper來作為我們的服務(wù)發(fā)現(xiàn)工具。

首先在容器啟動成功后我們將服務(wù)注冊到zookeeper中，存儲的path路徑如下:/caas/service/address/{appId}/{version}，存儲的服務(wù)子節(jié)點為{containerId}->{宿主機IP}:{服務(wù)端口}。

例如用戶appId01和appId02分別部署了各自的應(yīng)用版本容器containerId01和containerId02，對應(yīng)的服務(wù)端口分別為25701和25702，那么zk里存儲的注冊表信息為下：

/caas/service/address/appId01/app01Version/containerId01 -> {宿主機IP}:25701

/caas/service/address/appId02/app02Version/containerId02 -> {宿主機IP}:25702 

如果一個用戶部署了多個容器實例，對應(yīng)的zk注冊表信息類似下面：

/caas/service/address/{appId}/{version}/containerId01 -> {宿主機IP}:25701

/caas/service/address/{appId}/{version}/containerId02 -> {宿主機IP}:25702

/caas/service/address/{appId}/{version}/containerId03 -> {宿主機IP}:25703

/caas/service/address/{appId}/{version}/containerId04 -> {宿主機IP}:25704 

故障檢測

以上我們完成了服務(wù)的注冊，注冊完服務(wù)后為了實現(xiàn)應(yīng)用的高可用，我們應(yīng)該還需要對容器進行故障檢測，故障檢測的方案通常有下面2種：

• 組件主動請求服務(wù)發(fā)現(xiàn)心跳方式：組件可以設(shè)置一個超時時間，并能定期去請求服務(wù)發(fā)現(xiàn)來重置超時時間，超時時間達到閥值更新注冊表
• 服務(wù)發(fā)現(xiàn)主動請求組件心跳方式：服務(wù)發(fā)現(xiàn)定期的健康檢查組件以及當(dāng)組件出現(xiàn)故障時更新注冊表
  

通常內(nèi)部自己的服務(wù)可以使用第一種方式讓組件主動請求服務(wù)發(fā)現(xiàn)，用戶自己寫的服務(wù)一般不可能費勁的去實現(xiàn)心跳來訪問服務(wù)發(fā)現(xiàn)組件，所以通常會要求用戶實現(xiàn)一個服務(wù)發(fā)現(xiàn)組件能訪問的心跳接口，讓服務(wù)發(fā)現(xiàn)組件去主動請求用戶的應(yīng)用，一旦訪問失敗在重試一定次數(shù)后會認為該應(yīng)用已經(jīng)出現(xiàn)故障無法繼續(xù)提供服務(wù)，這時可以根據(jù)策略來選擇直接停止刪除該用戶容器或者重新啟動。

比如服務(wù)發(fā)現(xiàn)的健康檢查組件可以每隔一定時間來訪問用戶的心跳接口，類似{宿主機IP}:25701/_ping。

注冊表安全訪問

基于安全方面考慮，通常情況下我們需要對服務(wù)發(fā)現(xiàn)做相應(yīng)的訪問控制，以便對注冊表中的存儲信息實現(xiàn)安全訪問，可能有以下幾種方案可供參考：

1. 服務(wù)發(fā)現(xiàn)工具可以采用SSL/TLS加密鏈接
2. 對寫入數(shù)據(jù)進行加密，使用者使用的信息必須用相應(yīng)的密鑰解碼從服務(wù)發(fā)現(xiàn)中獲取
3. 服務(wù)發(fā)現(xiàn)實現(xiàn)訪問控制，將不同的鍵值切分到不同的分組中，根據(jù)訪問的需要來制定不同的秘鑰從而訪問相應(yīng)的分組
   

這里我們就不說具體的安全方面的實現(xiàn)了，誰讓我們是簡易版CaaS系統(tǒng)呢。

分布式配置存儲和負載均衡

其實服務(wù)發(fā)現(xiàn)的注冊表存儲訪問地址只是其中的一個方面，你可以用它來存其他的信息，比如存應(yīng)用的配置，你可以通過配置動態(tài)的調(diào)整應(yīng)用，也可以存容器的相關(guān)指標，負載均衡就是一個很好的例子，它可以通過查詢服務(wù)發(fā)現(xiàn)得到各個后端節(jié)點承受的流量數(shù)，然后根據(jù)這個信息來調(diào)整配置。具體的負載均衡算法可以根據(jù)需求來選擇，我們就使用最簡單的round bobin算法，即輪詢方式訪問。這方面的實現(xiàn)涉及到CaaS系統(tǒng)的另一個組件:路由網(wǎng)關(guān)，具體后面介紹。

上面我們一直都是使用了ZooKeeper來作為服務(wù)發(fā)現(xiàn)工具的，除了ZooKeeper，我們還可以使用其他的服務(wù)發(fā)現(xiàn)工具：etcd、Consul、crypt、Confd，大家有興趣可以了解下，最重要的是能保證注冊表信息的數(shù)據(jù)一致性。

調(diào)度編排

通過上面幾步你的CaaS系統(tǒng)基本小有所成了，但這還不夠。我們在生產(chǎn)環(huán)境里隨著用戶應(yīng)用容器的數(shù)量增加需要增加宿主機來支撐避免資源不足，或者將某些用戶的實例單獨部署在指定的宿主機上，這就需要我們實現(xiàn)一個調(diào)度器組件。

宿主選擇

CaaS系統(tǒng)是一個分布式系統(tǒng)，在多個宿主機的環(huán)境里，我們需要知道用戶的應(yīng)用該部署在哪臺宿主機上，如果單機的話那就不需要選擇了，直接指定就好了。具體該如何調(diào)度需要考慮以下幾點：

1. 需要一個默認的調(diào)度策略，比如選擇可用內(nèi)存最多的宿主機部署服務(wù)或選擇CPU最空閑的宿主機部署服務(wù)
2. 調(diào)度器需要提供覆蓋機制，比如2個容器必須部署在同一個宿主機上作為一個單元來運行，比如同一個服務(wù)的2個實例容器必須部署在不同機器上來達到高可用
3. 調(diào)度器需要滿足限制條件，比如給特定的宿主機打標簽，比如一些服務(wù)需要部署在集群中的每一臺宿主機上
4. 多容器部署調(diào)度

隨著業(yè)務(wù)的擴展，我們可能需要提供分組容器管理，將一個集合的容器（通常是有相互依賴關(guān)系緊密關(guān)聯(lián)的組件）作為一個單獨應(yīng)用來處理，比如一個Web服務(wù)容器再加上后端的數(shù)據(jù)庫服務(wù)容器組合成一個project來發(fā)布。這里就不多做討論了，我們的簡易版系統(tǒng)還沒考慮到這步。

供應(yīng)

供應(yīng)是指將一個新主機上線并完成基本配置使得它們能夠工作的一個過程，通常在集群管理里用來自動擴展宿主機，管理工具來定義需求額外主機的過程以及自動觸發(fā)的條件，例如，如果你的應(yīng)用的負載很高，你可能希望讓你的系統(tǒng)增加額外的機器并水平擴展容器以緩解負載，這里我們同樣不做實現(xiàn)，簡易版就直接手動增加宿主機就好了嘛。

我們在這里舉個實現(xiàn)調(diào)度器的相對簡陋的方案：

主要使用關(guān)系型數(shù)據(jù)庫如MySQL來存儲宿主機信息，調(diào)度器查詢宿主機的相關(guān)指標信息根據(jù)調(diào)度算法選擇相應(yīng)的宿主機來部署，利用樂觀鎖來保證并發(fā)操作時的數(shù)據(jù)一致性，利用事務(wù)來保證部署和卸載等操作的原子性。這里面可能坑比較多，大家也可以使用現(xiàn)在比較流行的調(diào)度器，常用的調(diào)度器有：Fleet、Marathon、Swarm、Mesos、Kubernetes、Compose，大家有興趣可以了解下。

網(wǎng)關(guān)

上面我們在服務(wù)發(fā)現(xiàn)的負載均衡方面介紹到了網(wǎng)關(guān)，我們把它作為CaaS系統(tǒng)中重要的一個組件，他主要是負責(zé)用戶請求的轉(zhuǎn)發(fā)，舉個例子用戶部署了容器想要訪問它的容器服務(wù)，這個請求到達網(wǎng)關(guān)后網(wǎng)關(guān)根據(jù)策略選擇相應(yīng)的后端容器服務(wù)然后轉(zhuǎn)發(fā)請求。根據(jù)用戶的設(shè)定，動態(tài)路由請求到對應(yīng)容器實例，這相當(dāng)于一個代理服務(wù)器。具體如何選擇容器實例服務(wù)轉(zhuǎn)發(fā)就需要實現(xiàn)負載均衡器，我們可以通過查詢服務(wù)發(fā)現(xiàn)組件來獲取相應(yīng)容器信息來完成。既然是代理服務(wù)，我們在中間可以對用戶的請求做其他處理，比如做黑名單過濾，做流量統(tǒng)計，做CNames路由等等

假設(shè)我們的CaaS網(wǎng)關(guān)訪問域名是 mycaas.gateway.cn ，用戶在我們后臺部署了一個WEB應(yīng)用容器實例，調(diào)度器將他部署在了10.10.10.101宿主機上，容器服務(wù)端口映射為25701，用戶請求mycaas.gateway.cn到達網(wǎng)關(guān)后，網(wǎng)關(guān)根據(jù)請求信息識別用戶查詢該用戶所有的應(yīng)用容器信息，得到所有的容器服務(wù)地址，根據(jù)負載均衡規(guī)則代理轉(zhuǎn)發(fā)到目標容器服務(wù)上。這個查詢服務(wù)發(fā)現(xiàn)的過程中最好實現(xiàn)本地緩存，比如使用zookeeper的緩存減少和避免每次請求都訪問服務(wù)發(fā)現(xiàn)組件，同時代理轉(zhuǎn)發(fā)中盡量使用連接池減少開銷。

總結(jié)

至此我們簡單的CaaS系統(tǒng)就架構(gòu)設(shè)計好了，在整個系統(tǒng)中有服務(wù)發(fā)現(xiàn)/調(diào)度器/網(wǎng)關(guān)等多個組件協(xié)調(diào)配合。

最新評論