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

我們先了解下一個簡單的CaaS系統(tǒ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ù)端口，這需要我們確定容器的通信方案：

我們簡單的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)用，我們稍微對用戶的資源進(jìn)行下限制，比如限制用戶應(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)負(fù)載均衡和水平擴容。

應(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)工具來注冊自身信息