【編者按】針對(duì)采用OpenStack部署云平臺(tái)的復(fù)雜性，CSDN此前介紹過(guò)的ZStack是另外一種解決方案。本文是ZStack的深度試用報(bào)告，分別從部署、架構(gòu)和網(wǎng)絡(luò)三個(gè)層面介紹作者的試用體驗(yàn)，并與OpenStack進(jìn)行簡(jiǎn)單對(duì)比，文章最后也對(duì)ZStack的改進(jìn)方向提出了思考。以下為全文內(nèi)容：

“這是最好的時(shí)代，也是最壞的時(shí)代”。這句名言也是當(dāng)前云計(jì)算大環(huán)境的真實(shí)寫(xiě)照。云計(jì)算給企業(yè)帶來(lái)極大的便利，不但能夠充分利用現(xiàn)有的資源，而且能夠把資源（計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)）實(shí)現(xiàn)池化，像自來(lái)水一樣便捷、精確地使用，形成了新的資源計(jì)費(fèi)（商業(yè)）模式。但是，如何有效地、快速地把資源池化管理，這是擺在管理者和技術(shù)人員面前的一道難題。當(dāng)前整個(gè)云生態(tài)，最成功的案例莫過(guò)于Amazon AWS 和開(kāi)源的OpenStack。AWS可以說(shuō)是云計(jì)算的鼻祖，它的成功毋庸置疑，不夸張地說(shuō)，是它引領(lǐng)了云計(jì)算的時(shí)代；但它是閉源的，我們無(wú)法窺探它內(nèi)部的實(shí)現(xiàn)邏輯。直到開(kāi)源的OpenStack的出現(xiàn)，云計(jì)算才可以說(shuō)“飛入尋常百姓家”了。OpenStack讓整個(gè)云市場(chǎng)開(kāi)始紅火起來(lái)，各種云如雨后春筍般冒了出來(lái)。

隨著對(duì)OpenStack的深度普及，它在某些方面的弊端也不斷被管理層和技術(shù)人員所提及。整個(gè)OpenStack服務(wù)組件不斷增加，新的功能陸續(xù)被擴(kuò)展，各種廠商之間不斷角逐，都想主導(dǎo)OpenStack的走向（使之符合自己的利益），而中小企業(yè)由于缺乏技術(shù)力量，越來(lái)越玩不轉(zhuǎn)龐大的OpenStack，原來(lái)期待的易用性、穩(wěn)定性似乎逐漸地變成了奢望（或者說(shuō)過(guò)往）。作為OpenStack使用者的我，也蒙生了疑問(wèn)：OpenStack是不是還依然適合我們的使用場(chǎng)景，是否有別的替代品？在一次不經(jīng)意的瞬間，發(fā)現(xiàn)了一個(gè)叫ZStack的云平臺(tái)，在其官網(wǎng)赫然寫(xiě)著 “We name our project as ZStack because we hope it's the last effort to make a simple, reliable, and flexible IaaS software.”抱著試一試的心態(tài)，開(kāi)始了我的ZStack之旅。

部署篇

說(shuō)到部署，吐嘈下OpenStack。對(duì)于一個(gè)初次體驗(yàn)者，看到OpenStack浩瀚的部署手冊(cè)，估計(jì)會(huì)使部分體驗(yàn)者望而生畏。被強(qiáng)烈求知欲驅(qū)使著繼續(xù)部署的人們，一步一步“復(fù)制”、“粘貼”手冊(cè)里的命令（有些可能還不理解），硬著頭皮繼續(xù)前進(jìn)。最后滿心期待正常的DASH界面，被一個(gè)個(gè)“error"傷得體無(wú)完膚。最終能正常進(jìn)入WEB界面的寥寥無(wú)幾。雖然現(xiàn)在也出現(xiàn)了不少第三方的自動(dòng)化部署工具（如RDO、fuel等），但也涉及到復(fù)雜的配置（主要是OpenStack融合很多知識(shí)），對(duì)初次體驗(yàn)者也不是很友好。

ZStack的部署引導(dǎo)就顯得那么簡(jiǎn)潔明了。在”Installation"篇，總共只有三個(gè)頁(yè)面，分別是”Quick Installation"、“Maunual Installation”、“Multi-node Installation"。 對(duì)初次體驗(yàn)者，使用“Quick Installation"即可。ZStack作者提供了一鍵安裝的腳本，更為貼心地是，為國(guó)內(nèi)“特殊”的網(wǎng)絡(luò)環(huán)境，定制了相應(yīng)的套餐方案。

　　接下來(lái)開(kāi)始我們一鍵安裝部署之旅。

wget -O install-zstack.sh http://download.zstack.org/install.sh

sudo bash install-zstack.sh -a -R http://pypi.douban.com/simple/ -f http://7xi3lj.com1.z0.glb.clouddn.com/zstack-all-in-one-0.6.2.tgz

“人品”差點(diǎn)的話，可能會(huì)出現(xiàn)如下情景（還是拜我們“特殊”的網(wǎng)絡(luò)環(huán)境所賜，(╯﹏╰)）

　　解決的辦法：把www.w3.org 解析到本機(jī)“騙”過(guò)腳本檢測(cè)就行。

echo "127.0.0.1 www.w3.org" >>/etc/hosts

再來(lái)一次繼續(xù)我們的路程。（提示目錄已存在，刪除即可）

大約10-20分鐘左右（網(wǎng)絡(luò)質(zhì)量良好），部署就完成，根據(jù)提示打開(kāi)瀏覽器（通過(guò)驗(yàn)證）即可看到管理界面。

總體來(lái)說(shuō)，ZStack整個(gè)部署過(guò)程還是很友好的，沒(méi)有冗雜的配置（部分定制可以查看腳本的幫助，如IP指定等）。

架構(gòu)篇

部署的簡(jiǎn)便性，只是ZStack的一個(gè)外在特性。ZStack真正核心價(jià)值還在于它的架構(gòu)。（以下內(nèi)容僅是本人個(gè)人觀點(diǎn)，如有贊同，不勝榮幸。^_^)

全異步架構(gòu)

傳統(tǒng)的云管理平臺(tái)在擴(kuò)展方面有其特有的軟肋--slow task。在并發(fā)不高的情況下，體現(xiàn)不是很明顯，但批量的任務(wù)創(chuàng)建時(shí)（如創(chuàng)建虛擬機(jī)），就會(huì)出現(xiàn)任務(wù)失敗或超時(shí)。想必許多OpenStack使用者都會(huì)有這樣的經(jīng)歷，滿心期待能夠順利創(chuàng)建虛擬機(jī)，卻被一行行顯眼的紅色字體澆滅了熱忱的心。其中的原因如下：

OpenStack里任務(wù)（或者說(shuō)消息）傳遞的路徑很長(zhǎng)，比如以創(chuàng)建VM為例 ，一個(gè)任務(wù)要經(jīng)歷 " service --> scheduler --> image service --> storage service --> network service --> hypervisor " 這條傳遞路徑，每一環(huán)節(jié)都要一定的耗時(shí)，大批量任務(wù)執(zhí)行時(shí)，延遲效應(yīng)就更明顯，最后就出現(xiàn)任務(wù)失敗。

任務(wù)傳遞并非全異步。某些環(huán)節(jié)同步傳遞就會(huì)出現(xiàn)等待，進(jìn)一步增加了任務(wù)時(shí)間。（關(guān)于同步與異步的區(qū)別，詳見(jiàn) http://avaj.iteye.com/blog/151724）。下圖展示一個(gè)實(shí)例：

ZStack在這方面做了改進(jìn)，把服務(wù)之間的消息調(diào)用（或者API請(qǐng)求），以及服務(wù)內(nèi)部代碼方法之間的調(diào)用全部實(shí)現(xiàn)異步架構(gòu)，如下圖所示：

全異步架構(gòu)帶來(lái)了效率上的提升，本人沒(méi)有系統(tǒng)地測(cè)試（與OpenStack對(duì)比），但僅從感官上講，在ZStack上創(chuàng)建一臺(tái)虛擬機(jī)，秒秒鐘dash就顯示創(chuàng)建成功了，那種享受，不言而喻。

無(wú)狀態(tài)服務(wù)

在講無(wú)狀態(tài)服務(wù)之前，我先講下有狀態(tài)服務(wù)下的請(qǐng)求機(jī)制。 這里的狀態(tài)是指在有多個(gè)管理節(jié)點(diǎn)時(shí)，每個(gè)管理節(jié)點(diǎn)都會(huì)有多個(gè)相同的微服務(wù)。那么微服務(wù)之間就要對(duì)自己管理資源的數(shù)量進(jìn)行分配協(xié)商，向微服務(wù)發(fā)送請(qǐng)求的請(qǐng)求者也必須知道是哪個(gè)微服務(wù)在管理哪個(gè)資源。話多必失，還是上圖看看（我大學(xué)老師說(shuō)過(guò)，一圖勝千言）：

而在無(wú)狀態(tài)服務(wù)下，這些事情交給hash ring處理，微服務(wù)之間無(wú)需知道自己或別人管了哪些資源。在請(qǐng)求里只需含一個(gè)唯一的UUID，不再需要指出把請(qǐng)求提交給哪個(gè)微服務(wù)，集群內(nèi)部會(huì)把請(qǐng)求“路由”到指定的微服務(wù) 。如下圖所示：

ZStack里，管理節(jié)點(diǎn)之間形成一個(gè)強(qiáng)一致的hash ring，每個(gè)節(jié)點(diǎn)都有一份包含所有節(jié)點(diǎn)信息（如節(jié)點(diǎn)UUID）的副本。當(dāng)新節(jié)點(diǎn)加入或者節(jié)點(diǎn)退出時(shí)，都會(huì)產(chǎn)生廣播消息通知到其他節(jié)點(diǎn)，整個(gè)集群會(huì)重新動(dòng)態(tài)平衡，形成新的強(qiáng)一致的hash ring 。

ZStack自身強(qiáng)一致性的特性是其他IaaS軟件（包括OpenStack）不可比擬的。OpenStack要實(shí)現(xiàn)服務(wù)的HA特性，必須借助第三方高可用方案，比如keepalived+Haproxy或者pacemaker方案。誠(chéng)然這些都承受了生產(chǎn)環(huán)境的考驗(yàn)，但無(wú)疑給整個(gè)平臺(tái)增加了復(fù)雜度。

微服務(wù)體系

云平臺(tái)是個(gè)復(fù)雜的系統(tǒng)，管理著各種子系統(tǒng)（如計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、認(rèn)證等）。每一次的請(qǐng)求任務(wù)都需要在各個(gè)子系統(tǒng)之間來(lái)回協(xié)調(diào)。比如說(shuō)創(chuàng)建虛擬機(jī)，需要在計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)、認(rèn)證各環(huán)節(jié)都走通，任何一換出問(wèn)題，都將導(dǎo)致創(chuàng)建失敗。如下圖為OpenStack各個(gè)子系統(tǒng)的調(diào)度關(guān)系圖：

OpenStack服務(wù)之間不但有Http交互，也有RPC交互。整個(gè)系統(tǒng)錯(cuò)綜復(fù)雜。另一方面，隨著OpenStack的發(fā)展，修改代碼有時(shí)候會(huì)變得不那么容易，甚至不得不重構(gòu)整個(gè)子系統(tǒng)的代碼，就像Neutron已經(jīng)重構(gòu)了。

反觀ZStack，服務(wù)之間的交互就簡(jiǎn)單明了多了，所有交互統(tǒng)一走消息隊(duì)列，整個(gè)拓?fù)浣Y(jié)構(gòu)不再緊密，實(shí)現(xiàn)星狀的架構(gòu)。如下圖所示：

星狀架構(gòu)中，各服務(wù)之間只有消息的交互，服務(wù)之間基本完成獨(dú)立，添加或者刪除某個(gè)服務(wù)不會(huì)影響怎么個(gè)架構(gòu)（只會(huì)失去某些功能）。

OpenStack與ZStack兩者雖然都是微服務(wù)架構(gòu)，但在實(shí)現(xiàn)上有本質(zhì)的區(qū)別。

OpenStack的微服務(wù)是以獨(dú)立進(jìn)程分散到各個(gè)節(jié)點(diǎn)，這在一定程度實(shí)現(xiàn)了負(fù)載均衡的效果，但存在以下問(wèn)題：

服務(wù)邊界擴(kuò)大

給部署、升級(jí)、維護(hù)帶來(lái)困難

紛雜凌亂的配置

增加額外的監(jiān)控負(fù)擔(dān)

當(dāng)擴(kuò)展時(shí)，會(huì)生成更多的微服務(wù)

鑒于以上原因，ZStack采取all in one process的實(shí)現(xiàn)方式，這就帶來(lái)下列特點(diǎn)：

更簡(jiǎn)潔的依賴關(guān)系；所有微服務(wù)都集中在一個(gè)進(jìn)程中，相關(guān)代碼都在一個(gè)包里，給部署、升級(jí)、維護(hù)、擴(kuò)展帶來(lái)了極大的便利。

集中式的配置管理；OpenStack每個(gè)服務(wù)都有自己的配置，而且還分散在不同的主機(jī)上，維護(hù)成本較大；ZStack就容易多了。

微服務(wù)只需要關(guān)注自己的業(yè)務(wù)邏輯，高可用、負(fù)載均衡、監(jiān)控都可以交管理節(jié)點(diǎn)來(lái)完成。

進(jìn)程級(jí)的應(yīng)用擴(kuò)展。從代碼層講，ZStack的微服務(wù)都是一個(gè)個(gè)獨(dú)立的JAR包，且有自己獨(dú)立的API，錯(cuò)誤代碼，全局配置，全局屬性和系統(tǒng)標(biāo)簽。開(kāi)發(fā)人員可以直接導(dǎo)入包，來(lái)實(shí)現(xiàn)自己的需要的功能。

綜上所述，ZStack擁有一個(gè)清晰的、解耦的架構(gòu)，這是實(shí)現(xiàn)健壯IaaS平臺(tái)的基石。

插件機(jī)制

一個(gè)軟件的擴(kuò)展性是評(píng)價(jià)軟件的重要指標(biāo)之一。當(dāng)前OpenStack主要支持兩種插件擴(kuò)展機(jī)制。

strategy pattern （策略模式）

這是一種通用的擴(kuò)展模式，通過(guò)API接口，實(shí)現(xiàn)功能擴(kuò)展。比如OpenStack里Nova Hypervisor Driver 、Cinder Storage Driver等驅(qū)動(dòng)都是通過(guò)這種形式實(shí)現(xiàn)的。這是一種通過(guò)已經(jīng)定義好的協(xié)議來(lái)實(shí)現(xiàn)插制跟核心交互的。如下圖所示：

　　The out-of-process service （進(jìn)程外服務(wù)）

這種模式的典型就是外部服務(wù)（監(jiān)控）通過(guò)消息監(jiān)聽(tīng)，獲取平臺(tái)的消息。在OpenStack里，Ceilometer 服務(wù)里有很多監(jiān)控的實(shí)現(xiàn)機(jī)制就是如此，示意圖如下：

以上兩種插件機(jī)制是OpenStack和ZStack所共有的，下面要提的機(jī)制是ZStack獨(dú)有的。

Observer pattern (觀察者模式)

在這種模式下，插件會(huì)深入到監(jiān)控應(yīng)用內(nèi)部的業(yè)務(wù)邏輯的事件。當(dāng)應(yīng)用內(nèi)部發(fā)現(xiàn)事件時(shí)，插件會(huì)對(duì)此事件做出自己的響應(yīng)，在插件自身的代碼里執(zhí)行相應(yīng)的業(yè)務(wù)流。這種實(shí)現(xiàn)，對(duì)終端用戶是完全透明的，是純粹的內(nèi)部實(shí)現(xiàn)。舉個(gè) Observer pattern 案例，在OpenStack里Security Group（安全組）功能是集成在Neutron里，不能單獨(dú)剝離出來(lái)。而在ZStack里，Security Group是一種 Observer pattern plugin，你可以單獨(dú)提取，而不影響整個(gè)網(wǎng)絡(luò)功能的實(shí)現(xiàn)。這種插制的實(shí)現(xiàn)如下圖所示：

獨(dú)特的插件機(jī)制，給ZStack帶來(lái)了更靈活的實(shí)現(xiàn)。開(kāi)發(fā)者可以根據(jù)自己業(yè)務(wù)需求擴(kuò)展功能，而ZStack 開(kāi)發(fā)者只需維護(hù)核心代碼。如此帶來(lái)的好處就是，整個(gè)云平臺(tái)可以快速更迭，功能逐步完善，而整個(gè)架構(gòu)還是健壯的。

以上這些架構(gòu)特點(diǎn)并非ZStack的全部，比如說(shuō)ZStack還有回滾機(jī)制，一但超時(shí)或出錯(cuò)，整個(gè)任務(wù)流就會(huì)回滾（包括數(shù)據(jù)庫(kù)的修改，比如VM創(chuàng)建失敗，IP會(huì)被回收，VM不會(huì)停留在errror狀態(tài)而是直接被刪除；而OpenStack會(huì)出現(xiàn)僵尸VM）。更多ZStack的架構(gòu)方面的信息，詳見(jiàn)ZStack官網(wǎng)。

網(wǎng)絡(luò)篇

在云時(shí)代，用戶對(duì)網(wǎng)絡(luò)提出了更高的要求。云中的網(wǎng)絡(luò)不再是固定不變的，而應(yīng)該可以隨時(shí)根據(jù)業(yè)務(wù)進(jìn)行調(diào)整，對(duì)網(wǎng)絡(luò)的隔離性也有更進(jìn)一步的要求。另外，傳統(tǒng)網(wǎng)絡(luò)的功能（如LB、VPN、FW等）也被引入到了云中，更高級(jí)的SDN網(wǎng)絡(luò)、NFV功能現(xiàn)在也開(kāi)始集成了到了云中。OpenStack是網(wǎng)絡(luò)集大成者，各種傳統(tǒng)設(shè)備廠商、新型SDN公司以及各大運(yùn)營(yíng)商都在極力向Neutron靠攏，OpenStack的網(wǎng)絡(luò)功能可謂包羅萬(wàn)象。

ZStack從一開(kāi)始就把自己定位是私有云解決方案，它沒(méi)有像OpenStack那么強(qiáng)大的網(wǎng)絡(luò)功能，但基本已經(jīng)能夠滿足私有云對(duì)網(wǎng)絡(luò)的需求。ZStack 借鑒了CloudStack的網(wǎng)絡(luò)解決方案，把網(wǎng)絡(luò)功能都集成到Virtual Router來(lái)實(shí)現(xiàn)，實(shí)現(xiàn)計(jì)算、網(wǎng)絡(luò)實(shí)現(xiàn)良好的隔離。比如說(shuō)，端口轉(zhuǎn)發(fā)和SNAT功能，OpenStack利用iptables在宿主機(jī)上來(lái)實(shí)現(xiàn)的，這導(dǎo)致宿主機(jī)的iptables更加紛雜（即有宿主機(jī)自身的規(guī)則，也有VM的規(guī)則）。而ZStack把這些實(shí)現(xiàn)（也是iptables）轉(zhuǎn)移到了VR，排錯(cuò)相對(duì)比較容易。ZStack把CloudStack的基礎(chǔ)網(wǎng)各和高級(jí)網(wǎng)絡(luò)融合在了一起，可謂 “打破這種無(wú)理的分割”——來(lái)自某CS資深用戶（@Star華星_FreeBSD）的肺腑感慨。ZStack在網(wǎng)絡(luò)方面更讓人傾心的是，它提供了豐富網(wǎng)絡(luò)應(yīng)用場(chǎng)景向?qū)В旧夏依怂接性瞥Ｒ?jiàn)的應(yīng)用聲場(chǎng)景。下面列舉幾個(gè)場(chǎng)景應(yīng)用：

1. Amazon EC2 classic EIP

EIP（彈性IP）是當(dāng)前云環(huán)境中最常見(jiàn)的應(yīng)用。創(chuàng)建虛擬機(jī)的時(shí)候會(huì)分配一個(gè)private IP，當(dāng)虛擬機(jī)綁定EIP的時(shí)候，虛擬機(jī)就可以實(shí)現(xiàn)公網(wǎng)路由了——這是在公有云場(chǎng)景。對(duì)應(yīng)于私有云時(shí)，單純private IP無(wú)法訪問(wèn)公網(wǎng)，只有綁定EIP，才能實(shí)現(xiàn)公網(wǎng)訪問(wèn)。EIP是動(dòng)態(tài)的，用戶可以實(shí)現(xiàn)更變綁定到不同的虛擬機(jī)上。這是云特性之一，彈性?。ú僮髟斠?jiàn) http://zstack.org/tutorials/ec2-cli.html）

2.Flat network

Flat network是一般企業(yè)內(nèi)部很流行的應(yīng)用場(chǎng)景。所有虛擬機(jī)共處一個(gè)廣播域，虛擬機(jī)訪問(wèn)外網(wǎng)通過(guò)本地網(wǎng)關(guān)出去。如果L3子網(wǎng)在公網(wǎng)是可路由的，那虛擬機(jī)就可以直接分配公網(wǎng)IP。（操作詳見(jiàn) http://zstack.org/tutorials/flat-network-cli.html ）

更多場(chǎng)景詳見(jiàn) http://zstack.org/tutorials/ ，在此不再一一舉例。

ZStack以上的各種網(wǎng)絡(luò)場(chǎng)景是可以共存的，通過(guò)Zone設(shè)置，可以形成獨(dú)立的網(wǎng)絡(luò)環(huán)境，這大大增強(qiáng)了網(wǎng)絡(luò)的靈活性。更多的功能，有待使用者挖掘。

疑惑篇

說(shuō)了這么多ZStack優(yōu)勢(shì)，也得扒一扒ZStack相關(guān)薄弱或者說(shuō)隱患的地方 。(個(gè)人鄙見(jiàn)，^_^)

融合的單進(jìn)程架構(gòu)，誠(chéng)然存在很多優(yōu)勢(shì)，但也有隱患。本人看來(lái)，最大的隱患就是核心代碼的處理邏輯，如果核心代碼出現(xiàn)嚴(yán)重bug，直接導(dǎo)致進(jìn)程掛掉，那整個(gè)集群就失控了（所有管理節(jié)點(diǎn)都是一致的）。ZStack是JAVA編寫(xiě)的，bug修復(fù)與部署都得重來(lái)，整個(gè)耗時(shí)就長(zhǎng)了。OpenStack是Python腳本語(yǔ)言，直接線上修改即可，而且OpenStack是分散式微服務(wù)架構(gòu)， bug只會(huì)影響具體某項(xiàng)功能，不會(huì)對(duì)整個(gè)集群產(chǎn)生毀滅性打擊。

ZStack當(dāng)前的認(rèn)證體系是融合在核心代碼里的（至少我還沒(méi)發(fā)現(xiàn)是否可以認(rèn)證接口可以引入第三方認(rèn)證），這對(duì)認(rèn)證擴(kuò)展帶來(lái)了許多不便。比如說(shuō)，不能集成現(xiàn)有的認(rèn)證方式（比如AD、LDAP等），一般企業(yè)都有自己的認(rèn)證體系。而OpenStack的Keystone在這方面做得不錯(cuò)，它可以無(wú)縫銜接第三方的認(rèn)證（主要是AD、LDAP、Kerberos等）。統(tǒng)一的認(rèn)證體系給企業(yè)在管理上帶來(lái)不少的便利。

當(dāng)前ZStack的版本（0.62）對(duì)存儲(chǔ)支持有限，只支持NFS存儲(chǔ)（最新的0.7 預(yù)覽版支持iSCSI）。企業(yè)對(duì)存儲(chǔ)的需求很大，從我目前觀察來(lái)看，大部分企業(yè)還是挺看重本地存儲(chǔ)。另外，當(dāng)前的大數(shù)據(jù)時(shí)代，數(shù)據(jù)不再是線性增長(zhǎng)，幾乎可以說(shuō)是指數(shù)增長(zhǎng)曲線，所以企業(yè)對(duì)存儲(chǔ)的擴(kuò)展性要越來(lái)載高，ZStack應(yīng)該支持更多的存儲(chǔ)插件，比如GlusterFS、Ceph等分布式存儲(chǔ)。

ZStack的VR網(wǎng)絡(luò)機(jī)制，滿足中小型私有云那是沒(méi)有問(wèn)題，但是否能承受規(guī)?；皆频木W(wǎng)絡(luò)需求，有待考證。最好的方式就是引入SDN解決方案，徹底解決網(wǎng)絡(luò)瓶頸。

ZStack的L2網(wǎng)絡(luò)當(dāng)前還只支持VLAN，下一步可以考慮引下VXLAN、GRE等overlay的隔離，如此一來(lái)，網(wǎng)絡(luò)功能就更加完善了。

外篇

在我看來(lái)，ZStack未來(lái)的商業(yè)模式就是提供私有云咨詢服務(wù)，深耕私有云市場(chǎng)，與廠商進(jìn)行接恰合作，提供專業(yè)的存儲(chǔ)、網(wǎng)絡(luò)服務(wù)。當(dāng)然前提是做好ZStack的生態(tài)圈，讓更多的企業(yè)和開(kāi)發(fā)者來(lái)參與ZStack的發(fā)展。

此文是本人近期對(duì)ZStack的體驗(yàn)一些感受與想法，期間特別感謝ZStack的作者 張?chǎng)?、尤永康的幫助，也感謝ZStack社區(qū) （QQ群：410185063 ）的各位朋友的幫助。特別是群管理員 @Star華星_FreeBSD (網(wǎng)名 群小助）的鼎力協(xié)助。希望ZStack越來(lái)越好，受到市場(chǎng)的關(guān)注。