摘要：在系統(tǒng)出現(xiàn)前企業(yè)應(yīng)用架構(gòu)基本被等模式壟斷，直到的出現(xiàn)為我們打開了另一個(gè)扇大門，廢話不說了，我們直奔主題我們先了解下一個(gè)簡(jiǎn)單的系統(tǒng)是如何為用戶提供服務(wù)的企業(yè)用戶上傳它的應(yīng)用代碼或其他代碼托管方式，我們生成用戶應(yīng)用的鏡像，或者用戶直接上傳鏡像或

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

我們先了解下一個(gè)簡(jiǎn)單的CAAS系統(tǒng)是如何為用戶提供服務(wù)的

企業(yè)用戶上傳它的應(yīng)用代碼或其他代碼托管方式，我們生成用戶應(yīng)用的鏡像，或者用戶直接上傳鏡像,或者用戶直接使用我們提供的基礎(chǔ)服務(wù)鏡像

用戶部署他的鏡像應(yīng)用，啟動(dòng)它的鏡像容器

用戶訪問他的應(yīng)用服務(wù)

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

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

有了用戶制作的鏡像，該是啟動(dòng)它的時(shí)候了

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

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

跟宿主機(jī)共用一個(gè)網(wǎng)絡(luò)空間

發(fā)布一個(gè)容器端口，讓docker隨機(jī)選擇一個(gè)未使用的高位端口

發(fā)布一個(gè)容器端口，并映射到宿主機(jī)上指定端口為外部路由服務(wù)

采用docker的"links"來允許容器間通信。 如果一個(gè)新容器鏈接到一個(gè)已有容器，新容器將會(huì)通過環(huán)境變量獲得已有容器的鏈接信息，一個(gè)關(guān)聯(lián)的容器將會(huì)獲得它的對(duì)應(yīng)連接信息，在它處理了那些變量后允許它自動(dòng)連接。這樣就使得同一個(gè)宿主機(jī)上的容器不需要知道對(duì)應(yīng)服務(wù)的端口和地址，就可以直接進(jìn)行通信

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

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

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

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

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

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

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

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

當(dāng)每一個(gè)服務(wù)啟動(dòng)上線之后，他們通過發(fā)現(xiàn)工具來注冊(cè)自身信息

服務(wù)的消費(fèi)者能夠在預(yù)設(shè)的終端查詢?cè)摲?wù)的相關(guān)信息，然后它就可以基于查到的信息與其需要的組件進(jìn)行交互

為了簡(jiǎn)便，我們使用zookeeper來作為我們的服務(wù)發(fā)現(xiàn)工具

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

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

/caas/service/address/appId01/app01Version/containerId01 -> {宿主機(jī)IP}:25701
/caas/service/address/appId02/app02Version/containerId02 -> {宿主機(jī)IP}:25702

如果一個(gè)用戶部署了多個(gè)容器實(shí)例，對(duì)應(yīng)的zk注冊(cè)表信息類似下面:

/caas/service/address/{appId}/{version}/containerId01 -> {宿主機(jī)IP}:25701
/caas/service/address/{appId}/{version}/containerId02 -> {宿主機(jī)IP}:25702
/caas/service/address/{appId}/{version}/containerId03 -> {宿主機(jī)IP}:25703
/caas/service/address/{appId}/{version}/containerId04 -> {宿主機(jī)IP}:25704

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

組件主動(dòng)請(qǐng)求服務(wù)發(fā)現(xiàn)心跳方式：組件可以設(shè)置一個(gè)超時(shí)時(shí)間，并能定期去請(qǐng)求服務(wù)發(fā)現(xiàn)來重置超時(shí)時(shí)間，超時(shí)時(shí)間達(dá)到閥值更新注冊(cè)表

服務(wù)發(fā)現(xiàn)主動(dòng)請(qǐng)求組件心跳方式：服務(wù)發(fā)現(xiàn)定期的健康檢查組件以及當(dāng)組件出現(xiàn)故障時(shí)更新注冊(cè)表

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

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

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

服務(wù)發(fā)現(xiàn)工具可以采用SSL/TLS加密鏈接

對(duì)寫入數(shù)據(jù)進(jìn)行加密，使用者使用的信息必須用相應(yīng)的密鑰解碼從服務(wù)發(fā)現(xiàn)中獲取

服務(wù)發(fā)現(xiàn)實(shí)現(xiàn)訪問控制，將不同的鍵值切分到不同的分組中，根據(jù)訪問的需要來制定不同的秘鑰從而訪問相應(yīng)的分組

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

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

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

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

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

需要一個(gè)默認(rèn)的調(diào)度策略，比如選擇可用內(nèi)存最多的宿主機(jī)部署服務(wù)或選擇cpu最空閑的宿主機(jī)部署服務(wù)

調(diào)度器需要提供覆蓋機(jī)制，比如2個(gè)容器必須部署在同一個(gè)宿主機(jī)上作為一個(gè)單元來運(yùn)行，比如同一個(gè)服務(wù)的2個(gè)實(shí)例容器必須部署在不同機(jī)器上來達(dá)到高可用

調(diào)度器需要滿足限制條件，比如給特定的宿主機(jī)打標(biāo)簽，比如一些服務(wù)需要部署在集群中的每一臺(tái)宿主機(jī)上

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

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

我們?cè)谶@里舉個(gè)實(shí)現(xiàn)調(diào)度器的相對(duì)簡(jiǎn)陋的方案:

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

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

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

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

作者信息

作者來自力譜宿云LeapCloud旗下MaxLeap團(tuán)隊(duì)_云服務(wù)研發(fā)成員：David Young
首發(fā)地址：https://blog.maxleap.cn/archi...

相關(guān)文章

基于PaaS和SaaS研發(fā)的商業(yè)云平臺(tái)實(shí)戰(zhàn) 
移動(dòng)云平臺(tái)的基礎(chǔ)架構(gòu)之旅（二）- 云代碼篇 
微服務(wù)系統(tǒng)中的服務(wù)發(fā)現(xiàn)機(jī)制

歡迎關(guān)注微信訂閱號(hào)：MaxLeap_yidongyanfa