【原創】設計中立公有云云管平台

第一 本文目標

我本來沒興趣寫雲管平台的設計思路的，我想你也沒興趣讀，覺得這個問題沒什麼難度、沒什麼意義，網上一搜也有很多成型產品。但架不住客戶的要求真動筆去寫之後，我發現設計雲管平台像素描畫蘋果、小飯館的雞蛋炒餅一樣，看似簡單的需求，卻考察很深的基本功。

此文的第一目標不是要上雲管平台的客戶，而是要被管理的雲平台的售前、產品和研發，本文是站在客戶角度去看雲端資源到底有何用途的一個梳理列表，各雲廠商要堅持自己的產品戰略，但引導客戶需求不等於忽略客戶需求。

此文的直接目標就是採購大量公有雲資源的廠商。本文是為說清楚雲平台哪些功能是最重要的，哪些功能是可有可無的。無論是自己研發雲管平台還是買雲管軟體，這個雲管平台必須符合哪些特性、支持哪些功能。

第二 雲管平台概述

說完了本文的目標讀者，我們再看核心問題，為什麼要做一個雲管平台。

當客戶的非CDN雲資源採購金額過500萬以後，如果其子項目之間沒有內網互通的需求，甚至刻意要做成廣域網容災互備時，這時候我們該做一個跨廠商的雲端資源管理方案了。現在虛擬機不能像CDN一樣隨意遷移，但未來容器、Servless和PaaS服務崛起，徹底改變了現有程序發布模式後，計算能力也會在多廠商之間漂移的。我們提前把雲管平台從計費和許可權層面做好，至少現在就和廠商砍價有底氣，還能模糊計費相關業務數據。

整個雲管平台涉及三個參與角色：

• 供應商或廠商，實際提供雲資源的廠商，如3A、百度、七牛。

• 雲管平台，即本文中設計或者採購評估的雲資源管理平台。

• 用戶，登陸雲管平台進行諸如創建主機、修改存儲空間等操作的最終用戶

#注意，雲管平台才是最終用戶要操作的雲平台。

任何一個在雲管平台可以獨立計費或獨立管理的功能組件都叫做資源。

每個資源都有唯一的ID做代碼邏輯層面的描述標識，雲資源供應商、雲管平台、用戶管理控制台、計費系統、API對接等等系統，都需要用到這個資源ID做管理系統的描述識別。該資源ID一般是供應商平台自動隨機生成的，用戶無法指定甚至不關心ID內容，而雲管平台可以簡單封裝標識該ID。比如用戶申請來自a01供應商的雲主機，供應商內部給該主機定義的資源id為「abcdef」，則雲管平台的資源id應為「a01-abcdef」。

每個資源都有一個用戶自定義，便於用戶人工操作可讀性的名稱；在供應商自己提供的雲平台上，這個名稱僅僅是個標識，客戶可以隨便修改，也不影響實際雲端業務。如果你要做大而全的雲管平台，可以讓客戶隨意操作資源名稱。但如果只是做簡易雲管平台，我的建議是用資源名稱做不同用戶的隔離標識，且讓用戶不可輕易修改該名稱。比如說用戶user1創建的雲主機名字叫「web01」，那實際創建的雲主機名應該是「web01.user1」，且「.user1」部分不可修改。這樣通過資源後綴名就可以笨拙但有效的區分開不同用戶的資源。

本文接下來的內容就是雲管平台拿到的不同供應商資源，哪些是必要資源，哪些是可選資源；這些資源至少要進行哪種程度的管理才能滿足用戶的基礎需求，哪些功能用戶嚷的響亮，但不是燃眉之急，可以放到二期三期來做。

第三 必要雲資源

雲計算平台最早是對物理伺服器的模擬，所以必須的雲資源就是模擬物理伺服器的資源。但云平台用SDN管理網路，雲主機無法像物理機一樣自由發ARP廣播，所以和主機網路相關的配置也要單獨管理。現在雲平台都把雲硬碟獨立於主機之外單獨管理，本地虛擬盤幾乎絕跡。

當我們要設計雲管平台時，最小必須的雲計算資源為這幾項：

1.雲主機， 2.雲硬碟， 3.公網IP+帶寬 4. VPC+安全組 5.負載均衡

一個雲平台缺少這五項中任何一項，用戶都不可能達到等同於自購物理機的效果，甚至最基本的功能都無法執行。當前各大供應商（含OpenStack和Zstack方案）都將這些雲資源都已經實現API化創建、查詢、管理、刪除。

對這些必要雲資源的規劃思路是，在能保證基礎功能和用戶便利的前提下，盡量砍掉一些炫酷但只有少數廠商支持的功能，為了簡化開發難度，對一些通用但低頻功能也可以拖到二期三期再做。

比如雲主機創建主機API時必備功能是 「選擇硬體配置」「順手創建公網IP」「自定義鏡像克隆主機」「設置主機名」的，管理API必須有「查看主機狀態和配置」「硬重啟」「綁定/解綁IP、硬碟」。其他的功能根據項目組的人力和工期可選展示給客戶，有人有時間就多做，沒人沒時間就少做。比如說「選擇可用區」功能可以展示到界面上，也可以保持默認；「設置修改密碼」功能可以直接帶上簡訊驗證通道開發完成，也可以用戶發一次郵件就代為操作一次；至於「配置升級」等功能，做功能介面並不難，難得是供應商的計費策略並不統一，並且雲管平台的計費系統變得複雜了。

雲硬碟和IP/帶寬的設置很簡單，VPC和安全組就要多考慮了。如果雲平檯面對的客戶需求很簡單，那可以每個用戶默認只有一個VPC一個子網就可以實現基本功能；NAT埠映射、VPC互聯、VPN路由等高級功能都是可選功能。當前安全組功能繁瑣而混亂，大部分客戶需要的只是管控對外開放埠。

負載均衡是雲平台唯一必備的PaaS服務，因為VPC環境下很難做keepalived和heartbeat。客戶在VPC里只能搭建沒有HA的LB，還不如把LB整體外拋給雲平台解決。從技術上說負載均衡必備的服務是按源IP分配的TCP負載均衡，讓這個負載均衡主要做HA用，後端可以再接用戶自定義的LB；但是各大雲平台都已經支持HTTP/HTTPS/UDP負載均衡，雲管平台可以一開始就把四七層負載均衡功能都開放給用戶。

第四 附加雲資源

前文的必要雲資源是狹義但經典的雲資源，其主要目的是將物理資源抽象化輸出資源池化調用。而另一些服務上雲更多是技術上強調自己接入了VPC，或者強調自己開箱即用、無限擴容。雲管平台集成這些資源是為了節省用戶人力和統一出賬單，在人力和工期緊張時，下列服務我們一個也不做，讓用戶自己在虛擬機上搭建；在人力和時間富裕狀態，我們要認真評估如何接入服務。

• 依賴虛擬IP和共享硬碟的傳統群集服務，比如雙主多從MYSQL，Keepalived+Redis，Heardbeat+DRBD+NFS，Oracle RAC。前文在LB階段已經講過VIP無法在VPC網路里自由漂移，大部分雲廠商又不太支持共享硬碟、心跳線等功能。雲管平台可以集成這些資源應對中小型客戶需求，也可以直接建議客戶單機部署；重型用戶需求產生了就不輕易變動，可以通過雲管平台自主測試、雲廠商定製開發、接入混合雲物理機等方式來個案單獨處理。

• 客戶端旁觀選舉的自協商群集服務。最近十年出的新服務，以及一些老服務的Cluster版都在走向智能化群集的方向。以Mongodb為例，客戶端會連接多個mongos和mongod，客戶端旁觀服務端選舉和切換主節點，不依賴虛擬IP就實現應用層高可用和負載均衡。雲管平台可選接入廠商服務滿足中小型客戶需求，畢竟不用自己做服務維護；但遇到重型客戶需求建議直接在高配虛擬機上自己搭，或者走混合雲物理機接入VPC的模式。

• 不考慮高可用性的服務。這其實挺尷尬的，理論上來說即使是內存緩存型服務也有雙活機制，但是廠商PaaS服務的後台架構完全是黑盒，沒出故障時都是專業架構，出故障了都是百年一遇，大都是「只考慮人品」的服務。以RDS為例，不同廠商的RDS可靠性千差萬別，我親眼看過很低可靠性的服務，也聽朋友說過本廠的RDS可靠性遠超普通DBA；但RDS對客戶只暴露一個服務介面，我們不知道廠商給主庫磁碟做沒做RAID，也不知道主從庫會不會在同一個物理機。所以前文中我對中小客戶用PaaS當做節省自己搭建的人力，對大型重型PaaS需求建議個案處理，因為各廠商通用的百倍賠償根本就是個免責條款。

• 對象存儲（OSS）和CDN。我一直不理解Nova和Swift如何從業務上聯動，做虛擬機時跟客戶解釋買虛擬機不關心OSS，做對象存儲時解釋OSS和其他雲平台沒什麼好混合的。雲廠商提供OSS+CDN的好處就是內網互通節省帶寬費用，但大客戶很可能越過雲管平台直接採購，小客戶一年可能只節省幾十塊錢。雲管平台要集成OSS和CDN服務時，一定要注意這兩個服務是沒有區域概念的，比如客戶用了百度北京的虛擬機加上七牛浙江的雲存儲和阿里全國的CDN，此時客戶業務絕對跑的通，三方互通有額外網路開銷。雲管平台的資源創建和計費系統都要考慮清楚，盡量資源走一個供應商，或要求不同供應商之間相互免費。

上述PaaS資源都有一個特點，可以按照使用量付費，或者提供貼合到業務邏輯操作層面的支持功能，那也就代表著客戶的計費訪問數據鐵定會被供應商拿到，而業務數據是否被偷窺要看供應商自律。

我們再看看下文一些更專業（偏門）的服務。

• 容器雲入門門檻太高，在中小客戶場景下缺乏成功案例，如果沒有具體項目要求上容器雲，就等到接完上面的PaaS服務再考慮接入容器雲。

• 反DDOS攻擊服務只能由雲廠商提供，因為開銷偏大計費不靈活，但又沒有日常管理需求，客戶到雲管平台到廠商溝通時直接用郵件、工單和合同即可，如果沒有頻繁攻擊和檢測需求，可以不留展示界面只用郵件通知。至於滲透測試和漏洞掃描，其實和雲服務沒直接關係，沒必要納入雲管平台。WAF可以參照負載均衡服務進行設計處理。

• 物理機和自控超賣比虛擬機，這是部分雲廠商才提供的功能，這類資源開銷偏大和計費不靈活，客戶要給雲管平台發郵件才能申請到資源，客戶日常有類似於虛擬機的管理和監控需求。

• 雲監控是一個基本免費的服務，對該服務的設計包含安全評估、數據展示和通知機制。安全評估就是要不要裝各廠商以Root許可權運行的Agent，數據展示就是各種監控統計表和折線圖展示給客戶，各廠商是直接通知到最終用戶還是通知到雲管平台後中轉傳遞信息。

• 其他，諸如域名、ICP備案、虛擬空間等服務。

第五 核心業務系統

已知雲管平台要管理上述資源，且不同資源的優先順序不同、同一個資源也不需要部署所有功能，那雲管平台自身該如何設計和展示？經過對多個雲管平台的調研統計，其核心必須的業務系統有四個，分別是「管理平台」「用戶系統」「計費系統」「廠商API封裝工作」。這幾個業務子系統都有幾個人月就可以做出的簡易版核心功能，也可以按照大型軟體工程去做全功能規劃設計。

1. 管理平台

這是運營人員使用的的資源統計、展示操作平台。

平台首頁是一個全部資源匯總頁，即平台已經開通多少用戶、多少主機、多少帶寬等等，無論是日常運營還是工作彙報都需要匯總統計。如有餘力可以和計費系統配合，做出各個廠商資源匯總對比頁面。

平台還要有各項資源分類匯總及單資源詳情頁，即虛擬機、硬碟等資源。這裡要求即可以做整體list，也可以查看單獨一個資源的狀態。前文提到要統一的資源ID可以調用廠商API快速查詢和操作資源。前文提到的統一資源名稱前後綴，可用於快速過濾出單個用戶的雲資源。如果快速施工可以只做資源的統計展示，雲管平台操作員去各廠商的管理控制台上執行資源操作；如果時間來得及那就把廠商提供的功能在本平台全部實現出來。

2. 用戶系統

雲管平台都是做對內業務或者固定項目，所以用戶系統不開放註冊，不需要找回密碼、身份認證等功能，但酌情開放修改密碼、高危操作簡訊驗證、特種資源申請等功能，技術諮詢類工單可以透傳給廠商。

公有雲的配額系統是為了保護廠商稀缺資源不被客戶濫用，用戶誤操作不會花光資金的。雲管平台的客戶很少會濫用資源，平台是廠商的大客戶也不會輕易欠費停機，雲管平台可以只做簡單粗糙的配額系統，以減少用戶誤操作為準，如果工期過緊甚至可以先不做配額系統。

用戶系統要有一個客戶可用的Web管理控制台，讓用戶可以完成各種資源操作。該管理控制台借鑒各大公有雲控制台即可，所要展示的資源和功能已經在前文討論過了，該產品可完美模擬功能強大，也可以極速從簡只做必要功能。

3. 計費系統

標準計費系統的功能複雜又強大，每個賬戶是預付費還是後付費、當前有多少餘額/透支額度、單個資源是打包整體付費還是按需按量付費，免費配贈資源的佔用策略，資源欠費後的保留周期，網銀和財務付費介面，甚至連發票管理都是計費系統要涉及的。

本部分說明如何用一兩個人月就能做出來的對賬式計費系統。

• 用戶相對可控，對反賴賬邏輯就可以弱化甚至不做。

• 按量付費就要幾分鐘一次頻繁對賬，那就把虛擬機、公網IP的按量付費砍掉，通通做成包月付費；對不能做成包月付費邏輯的資源，小金額需求直接打包或減免（比如說OSS的get post費用是一百塊錢上億次），大金額項目只能做成延遲出賬單的後付費（比如CDN賬單）。

• 產品品類不用太多，比如說虛擬機配置保留常用的5-10類就行了，沒必要做出四五十個配置類型。

• 各個廠商產品單價都是微微不同，但云管平台的資源可以做成統一價格。雲管平台可以簡單的按最高價格向客戶收費，也可以要求高價雲平台做充值贈送把價格實際降低。

• 每個資源的到期時間都可以通過查詢API方便獲取，即可在資源過期前及時通知到責任人；大部分雲平台資源欠費也只是資源暫停使用，不會立刻釋放，短時間內繳費後就恢復；但建議將ICP備案的IP地址做自動續費另案處理。

4. 廠商API封裝工作

不同廠商的資源操控API語法是不同的，同樣是創建虛擬機的方法，可能叫「create-instance」也可能叫「create-vm」，而雲管平台的統一命令可能是「xinzeng-xuniji」，要接入多家廠商就要完成多家廠商的API封裝工作。這個封裝工作的結果可能是一個寫死的類庫文件，也可以做成高大上的動態配置代理。如果當前只接入一個雲平台可以省掉這份工作，後續無論是自己開發還是甩鍋給新供應商都是可行的。

上文談了這麼多平台設計，大家一定覺得很不爽，問題怎麼會這麼繁瑣，實現結果為什麼會如此簡陋，是應該有資源隔離但統一計費的父子賬戶系統，是應該有功能強大百調不厭的計費API介面。筆者以前就規划過和用過這些系統，寫本文的目的也是為了催促各個雲平台開放此類功能。

第六 進階補充系統

除了上述核心業務系統外，雲管平台還可以有一些補充子系統，讓用戶像在用像一個標準雲平台。

• 面向客戶的API系統。高級用戶會有調用API管理資源的需求，雲管平台需要逐步開放面向客戶的API或SDK。

• 客戶智能化操作系統。雲管平台可以更貼近用戶業務，主動替客戶完成一些運維操作。簡單的如滾動快照雲主機，複雜的如根據LB負載動態擴容縮編Web伺服器。雲管平台離客戶的業務足夠近，又對雲端資源有深入了解，完全可以以此為切入點，從資源販售發展為技術輸出。

• 日誌系統。無論是計費日誌還是操作日誌都可以逐步記錄和開放出來。

• 通知和工單系統。此系統不用過多描述。

附錄：我們親眼看到CDN服務從各自為戰變成了智能融合，隨著計算業務的成熟發展，希望計算服務也能如行雲流水般想遷就遷。

配圖是早期火車和馬車賽跑但輸給馬車的照片，但是後來火車贏了。

推薦閱讀：