CloudSpace是一個平臺即服務(PaaS)，它提供給開發者自由的去選擇雲平臺、開發框架和應用服務，使得開發者能夠更快更容易的開發、測試、部署和擴展應用，讓開發人員專注於編寫應用程序，而無需爲中間件和基礎設施分心。團隊在使用自助式高生產力的框架和應用服務的同時，開發人員可以快速在自己的環境上開發和測試自己的下一代應用，並能部署到雲上而無需做任何更改，大大提升持續快速，高質量地交付價值的能力。
一、 PaaS解決了什麼問題？
PaaS爲開發者提供應用全生命週期的服務能力，主要有兩方面：
-
是提供了資源資源和服務集成的平臺，如 存儲、數據庫、緩存和搜索等；
-
是服務端應用程序的運行環境，如 Web應用和Work應用等；
PaaS架構設計要提供多租戶的應用平臺，多租戶間的隔離機制（Nodes、Network、IO、Runtime、Services等）非常重要，對於隔離要關注以下方面：
-
資源隔離和約束
指應用間的容器配額cpu、io、內存等資源要相互不受影響。
-
訪問控制
包括應用間的網絡訪問控制和本地IO訪問控制。
-
數據和數據服務
Container只掛在歸屬應用自身的UnionFS
OVS針對服務實例實施白名單策略
類似S3等塊存儲天然隔離
PaaS平臺主要支持了通用應用架構和應用運維兩方面能力：
-
支持應用架構能力
隨着應用架構迭代，平臺最終將應用抽象爲兩種類型web和work。區分兩種類型, 就是看應用提供的是http能力，還是socket能力。對於通用應用架構，與框架無關，具有無狀態、分佈式、通用性三個特性。
-
對於無狀態
一個應用通常有多個實例集，單實例失去服務能力不影響應用的服務。應用開發時，不要將狀態與實例耦合，通常採用實例之外通用存儲來保證狀態一致性。
-
對於分佈式
一個應用通常要進行集羣部署，而不是單個應用部署。具體這樣的特性，必須在應用開發時，注意擴展性，不要將配置與實例耦合，通常採用實例之外通用配置中心來保證應用獨立性。
-
對於通用性
更多是從應用和服務角度來做定義，對於應用來講，從調用關係來看，可分爲對外或對內調用，應用間通信抽象爲同步（常用Http）或異步（常用Message）；對於服務來講，從中間件角度來看，都應該具有分佈式能力（分佈式cache、分佈式db等），並且提供數據的安全訪問機制，屏蔽應用交互差異，做到通用模型。
2. 支持應用運維的能力
運維通常劃分爲基礎運維和應用運維。對於基礎運維，主要負責物理設備及網絡等基礎建設，更偏底層。對於應用維護，主要圍繞應用構建全方位服務，如 虛擬資源，網絡規劃，軟件預裝、應用，安全、日誌等管理服務，一直以來都在推動運維工作的自動化、規範化和簡約化，但仍然面對不同應用團隊個性化的挑戰，這些都應該有PaaS平臺統一解決。
二、PaaS架構設計
CloudSpace圍繞AppEngine核心採用了容器級的PaaS模型來設計，其設計目標爲：
#可用性，利用組件冗餘的設計，滿足應用7*24的服務。
#伸縮性，利用規則引擎的設計，滿足應用所屬實例的動態調度。
#安全性，利用軟控制策略，實現了應用與服務的網絡隔離和流量控制。
#省成本，利用虛擬化和自動化運維，節省資源，節省運維，按需計費。
#靈活性，利用容器技術，隔離環境，支持多語言，自定義軟件棧, 個性化配置等。
CloudSpace對於App的訪問，有Lvs集羣接入，通過Router來路由到具體App分配到宿主機(N)->容器(C)->實例(I)。對於三者關係, 對於PAAS平臺，會維護一個機器池，每個機器稱爲宿主機，每個宿主機上有多個容器，每個容器會部署一個App的實例。對於App在平臺上，實例的分佈有Master基於數據決策，調度到不同宿主不同容器，達到動態縮擴容要求，滿足應用的性能變化。
1.Node分層視圖
對於PaaS平臺部署應用最小物理單元爲Node，從結構上分爲三層：
第一層爲機器（簡稱Machine），提供給容器虛擬化的物理集羣，對應用透明。
第二層爲容器（簡稱Container），提供給App部署最小虛擬化單元，對應用透明。
第三層爲實例（簡稱 Instance），提供給App運行的實例，依賴軟件棧配置。
2.Container技術
主流PaaS模型包括 進程級、容器級、VM級，三種最重要區別隔離機制實現策略不同。
對於CloudSpace的容器技術迭代經歷了兩個重要版本：
第一種：LXC 基於容器的虛擬化技術
-
共享OS和內核
-
User Space + Kernel Space
-
Cgroup + Namespace
-
容器的創建，銷燬，啓動，停止
命令： lxc-create, destroy,start,stop,attach, execute
第二種：Docker 輕量級的操作系統虛擬化解決方案
Docker是一個構建在LXC之上的,基於進程容器的輕量級VM解決方案。
-
與VM不同
Docker則直接在宿主平臺上加載運行應用程序. 本質上他在底層使用LXC啓動一個Linux Container,通過Cgroup等機制對不同容器內運行的應用程序進行隔離,權限管理和quota分等，每個container擁有自己獨立的各種命名空間(亦即資源)包括: PID 進程, MNT 文件系統, NET 網絡, IPC , UTS 主機名等。
-
與LXC不同
Docker是Lxc的一個高級封裝,提供了各種輔助工具和標準接口方便使用,可以依靠Lxc和各種腳本實現與docker類似的功能。除此之外，Docker核心思想就體現在它的運行容器構建方案上， 爲了最大化重用Image運行時所構造的運行環境，實際上是由具有依賴關係的多個Layer組成的。有了層級化的Image做基礎，不同的APP共用底層文件系統及相關軟件棧，同一個APP的不同實例也可以實現共用絕大多數數據。
CloudSpace系統（如上圖）有六大組件構成：
1.Agent組件（應用代理）
-
容器生命週期
容器創建/配置/啓動/停止等指令，有Master通過Agent下發執行，應用於容器的生命週期。
-
語言運行環境初始化
容器本身語言無關，但在啓動時會指定語言類型（如java），並初始化語言相關的軟件棧（如 Jetty），爲應用配置好環境。
-
與Master交互命令
Agent與Master通過消息方式進行通信，接受Master對容器與應用的控制。
-
運行數據採集
Agent負責對應用依賴的機器和容器，進行性能數據採集（如 cpu，load，io等）。
-
APP狀態管理
Agent負責對應用的可用性進行健康檢查。
2.Router組件（路由）
CloudSpace部署多個Router共同處理所有HTTP流量。Controller獲得信息並實時更新路由表，持續維護分佈式路由狀態，並將用戶請求URL的訪問路由至具體的應用，保持在應用實例之間分發流量實現負載均衡。
-
Dynamic Upstream
APP在Master調度過程中，會動態更新Router中的映射地址，即爲用戶訪問APP的域名與容器地址，便於支持APP的動態所擴容策略。
-
Management Interface
Router開放接口，來支持Master圍繞APP動態load配置信息，實時控制應用鏈路映射，支持相關特性實現。
-
Http/Https
Route支持針對有https需求的應用配置https證書能力。
-
Sticky Session
Route反向代理應用請求，可以根據配置支持IPHash能力，便於應用支持粘性會話功能，但在實例調度時，仍然失效，只能一定程度保持狀態。更好建議是採用分佈式集中緩存的token或cookie方案來實現。
3. Master組件（控制）
Master是PAAS平臺最核心的控制中心，主要圍繞APP針對網絡和實例進行管理。對網絡利用SDN來進行多APP及服務間訪問限制；對於實例集中在資源分配和實例調度兩方面，最重要利用規則引擎實現了動態縮擴容，支持應用的彈性部署，能夠從容地應對業務的流量高峯。
-
對於APP資源分配，就是容器數量與類型配置選擇。對於已選定的APP資源也可以進行擴展，即分爲橫向擴展（實例數量）和縱向擴展（實例配置）。
-
Master主要依據APP的指標設置規則和採集機器及容器的性能數據做動態分析，對於APP實例調度，支持四種策略來實現自動縮擴容。
-
策略一：負載調度
若APP部署了三個實例（A/B/C），圍繞APP的三個實例的負載數據（cpu/mem/load等）進行採集，然後計算APP平均負載指標，來對比指標設置數據，若達到閥值，就觸發APP負載調度。Master會計算需要擴容3個實例能達到閥值以下，接着在剩餘資源中找到不同宿主機（負載最低）啓動APP的新實例DEF，最終APP啓動了六個實例來服務線上業務。
-
策略二：性能調度
若APP部署了三個實例（A/B/C），圍繞APP的三個實例的性能數據（qps/tps/rt/等）進行採集，然後計算APP平均性能指標，來對比指標設置數據，若達到閥值，就觸發APP性能調度。Master會計算需要擴容3個實例能達到閥值以下，接着在剩餘資源中找到不同宿主機（負載最低）啓動APP的新實例DEF，最終APP啓動了六個實例來服務線上業務。
-
策略三：故障調度
若APP部署了三個實例（A/B/C），圍繞APP設置健康檢查配置（端口、協議和頻次），Agent週期進行健康探測，然後根據結果狀態判斷來觸發故障調度。故障分爲三種Node、Container，不管那種故障類型，只是調度範圍不同。對於Node，是針對Node上所有app，對於Container，是針對Container內app，首先Master要發指令給Router，剔除掉原有映射關係，避免請求到故障實例上。對於負載和性能調度策略，在縮擴容時也要考慮映射關係動態變更。
-
策略四：最大最小調度
對於APP的業務有高峯有低谷，常常流量不平均，期望在高峯時擴容，低谷時縮容，提升對資源利用率。正式這種考慮，需要依據APP最小最大調度數設置（如： 3<x<6），Master利用規則引擎，實現自動縮擴容。圍繞APP動態計算性能和負載的綜合數據指標，並進行同比和環比計算，來預測指標趨勢，最終決定是要擴還是縮。
總結：自動縮擴容機制，本質上是利用Router的動態Upstream機制，實現APP期望的實例數動態映射。現在有很多網關方案均支持這種特性，感興趣也可以研究下k8s，比原有方案會簡單不少。
4.Monitor組件（監控）
對於監控來講，基於日誌自研的APM系統，對於APP的應用請求和業務日誌通過Flume採集，經過實時計算分鐘級的性能指標（機器/容器/APP），存儲在數據庫中，提供Console進行可視化展示，同時讓開發者可以基於ES查詢實現日誌搜索查詢。
5.Service組件（服務）
Sevice是一個獨立的、插件式的模塊，便於第三方方便地把自己的服務整合成CloudSpace服務。在此PAAS平臺中已經包含了服務的框架及核心類庫，如MongoDB、Mysql、 PostgreSql、RabbitMQ、Redis和ElasticSearch等，並且第三方可以繼承Node和Gateway基礎類來開發自己的服務。
6.Net模塊（網絡）
PAAS平臺主要採用了floodlight實現SDN功能，來控制容器的OVS的配置，實現APP間的網絡限制功能。對於floodlight的高可用利用ZK特性實現了M/S架構二次開發，並對ovs可視化視圖進行了指標優化，進而提升了平臺安全性。
三、CloudSpace架構設計未來規劃
1.支持多平臺多區域
-
支持多平臺：
考慮多平臺的資源集成架構設計，增加Azure，Aws等資源平臺。
-
支持多區域：
考慮多Region架構設計，支持後續會逐步增加節點
2.支持開放平臺原則
-
持續完善OpenApi
便於第三方管理平臺集成服務
-
接入更多的服務
便於滿足用戶更多的業務需求
3. 支持AIops功能
在不斷完善devops外，引入更加智能aiops，爲用戶提供一致的開發/測試/生產環境，更好的提升交付價值的效率。
4. 支持新應用架構
跟進新一代微服務技術Service Mesh的發展。