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

在CAAS系統出現前企業應用架構基本被IAAS/SAAS/PAAS等模式壟斷，直到docker的出現為我們打開了另一個扇大門，廢話不說了，我們直奔主題

我們先了解下一個簡單的CAAS系統是如何為用戶提供服務的

企業用戶上傳它的應用代碼或其他代碼托管方式，我們生成用戶應用的鏡像，或者用戶直接上傳鏡像,或者用戶直接使用我們提供的基礎服務鏡像

用戶部署他的鏡像應用，啟動它的鏡像容器

用戶訪問他的應用服務

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

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

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

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

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

跟宿主機共用一個網絡空間

發布一個容器端口，讓docker隨機選擇一個未使用的高位端口

發布一個容器端口，并映射到宿主機上指定端口為外部路由服務

采用docker的"links"來允許容器間通信。 如果一個新容器鏈接到一個已有容器，新容器將會通過環境變量獲得已有容器的鏈接信息，一個關聯的容器將會獲得它的對應連接信息，在它處理了那些變量后允許它自動連接。這樣就使得同一個宿主機上的容器不需要知道對應服務的端口和地址，就可以直接進行通信

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

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

為了不讓某個用戶的應用占用過多資源導致影響到整個宿主機上其他的應用，我們稍微對用戶的資源進行下限制，比如限制用戶應用容器的使用內存和CPU權重

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

為了能做到水平擴展，容器服務最好是無狀態的的，這樣能更好的實現負載均衡和水平擴容。

應用啟動成功，我們可以通過在宿主機上訪問25701即可訪問容器的8080端口服務

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

容器啟動成功后，用戶該如何訪問到他的容器服務呢，總不能提供宿主機IP給用戶直接訪問吧，這就需要我們構建一個服務發現組件了

當每一個服務啟動上線之后，他們通過發現工具來注冊自身信息

服務的消費者能夠在預設的終端查詢該服務的相關信息，然后它就可以基于查到的信息與其需要的組件進行交互

為了簡便，我們使用zookeeper來作為我們的服務發現工具

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

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

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

如果一個用戶部署了多個容器實例，對應的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

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

組件主動請求服務發現心跳方式：組件可以設置一個超時時間，并能定期去請求服務發現來重置超時時間，超時時間達到閥值更新注冊表

服務發現主動請求組件心跳方式：服務發現定期的健康檢查組件以及當組件出現故障時更新注冊表

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

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

基于安全方面考慮，通常情況下我們需要對服務發現做相應的訪問控制，以便對注冊表中的存儲信息實現安全訪問，可能有以下幾種方案可供參考:

服務發現工具可以采用SSL/TLS加密鏈接

對寫入數據進行加密，使用者使用的信息必須用相應的密鑰解碼從服務發現中獲取

服務發現實現訪問控制，將不同的鍵值切分到不同的分組中，根據訪問的需要來制定不同的秘鑰從而訪問相應的分組

這里我們就不說具體的安全方面的實現了，誰讓我們是簡易版CAAS系統呢。

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

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

通過上面幾步你的CAAS系統基本小有所成了，但這還不夠。我們在生產環境里隨著用戶應用容器的數量增加需要增加宿主機來支撐避免資源不足，或者將某些用戶的實例多帶帶部署在指定的宿主機上，這就需要我們實現一個調度器組件。

CAAS系統是一個分布式系統，在多個宿主機的環境里，我們需要知道用戶的應用該部署在哪臺宿主機上，如果單機的話那就不需要選擇了，直接指定就好了。具體該如何調度需要考慮以下幾點:

需要一個默認的調度策略，比如選擇可用內存最多的宿主機部署服務或選擇cpu最空閑的宿主機部署服務

調度器需要提供覆蓋機制，比如2個容器必須部署在同一個宿主機上作為一個單元來運行，比如同一個服務的2個實例容器必須部署在不同機器上來達到高可用

調度器需要滿足限制條件，比如給特定的宿主機打標簽，比如一些服務需要部署在集群中的每一臺宿主機上

隨著業務的擴展，我們可能需要提供分組容器管理，將一個集合的容器（通常是有相互依賴關系緊密關聯的組件）作為一個多帶帶應用來處理，比如一個web服務容器再加上后端的數據庫服務容器組合成一個project來發布。這里就不多做討論了，我們的簡易版系統還沒考慮到這步。

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

我們在這里舉個實現調度器的相對簡陋的方案:

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

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

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

至此我們簡單的CAAS系統就架構設計好了，在整個系統中有服務發現/調度器/網關等多個組件協調配合。

作者信息

作者來自力譜宿云LeapCloud旗下MaxLeap團隊_云服務研發成員：David Young
首發地址：https://blog.maxleap.cn/archi...

相關文章

基于PaaS和SaaS研發的商業云平臺實戰 
移動云平臺的基礎架構之旅（二）- 云代碼篇 
微服務系統中的服務發現機制

歡迎關注微信訂閱號：MaxLeap_yidongyanfa