云開發平臺真的是不簡單
近兩年，云計算的熱潮此起彼伏，很多聲音來自存儲、服務器、簡單的NoSQL訪問，并且誤導大眾云計算就像自來水、民用電的取用一樣，但這只是云計算的準備階段或初級階段，就好比給您一臺沒有瀏覽器、沒有Office和其他文檔閱讀、編輯的半裸機一樣，而真正為您定制的應用或您用于獲利的應用還“飄”在地上。相對而言，Azure平臺更貼近應用，它提供的不是大眾無法直接使用的“基礎設施”，而是各類實實在在的應用軟件，只不過“飄”在云上而已。
如果用軟件運行機制劃分，云應用則是站在一個新的起點，而Visual Studio 2010無疑為開發此類應用提供了快捷方式：本質上，云計算需要屏蔽掉物理區域、承載節點、網絡拓撲等因素向用戶透明地提供服務，而Azure恰恰提供了這些內容：
（1）、具備其他云服務商的基礎環境能力。
（2）、整合了Windows Live、Dynamics和WindowsServer產品，其中很多功能非常適合商業環境，類似功能對于ISV或個體開發者而言如果從頭開始做，技術上難度過大，而且即便技術上能完成也錯失了商業機會。
（3）、充分保護現有開發技能投資，使用Azure的開發者可以繼續把絕大部分本地WinForm應用、ASP.NET應用的經驗運用到Azure中。
不過，盡管Azure上述特點提供了一個較為可靠的運行環境和API體系，但用戶自己開發的云應用能否穩定可靠運行幾乎是另一碼事，就好像同樣一個基于 SQL Server 2008類似功能的系統，有的開發者可以支持200個并發用戶，有的只能支持10個并發。據筆者經驗，開發云應用在實現階段的步驟上有些特別之處：
（1）、前期，通過原型系統驗證API。考慮云應用開發在業界還比較有限，出于知識積累的考慮，建議采用非拋棄型原型較好，便于團隊學習、理解、沉淀相關技術。不過，現階段也有些不利因素，由于云應用開發尚不甚成熟，API的非兼容更新經常發生，為此即便是原型也建議運用設計模型技巧，在部分關鍵API處預留后手。
（2）、然后，基于威脅建模分析安全性，對原型進行必要的重構和簡單的滲透測試，無論采用CIA（保密性、完整性、可用性：C=Confidentiality,I=Integrity, A=Availability）的防御模型還是SDL的 STRIDE（Spoofing user identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege）攻擊模型，開發云應用必須先過安全關。另外，必須慎重權衡HTTPS的使用范圍，這里范圍包括三個維度“功能”、“時間”、“數據量”，做到“剛剛夠用”（No more no less），否則代價就是真金白銀。
（3）、接著，開發功能并通過必要的單元測試、集成測試確認功能有效。
（4）、下面是配置云運行環境，根據不同資源情況下的運行表現在應用中留出“活扣”，便于實際部署后可以根據吞吐率有先手布局。這步非常關鍵，因為不同于我們以往的企業應用或互聯網應用，Azure平臺允許我們進行類似的模擬，做類似的裝載回歸其成本很低。
（5）、最后，根據預估的資源使用情況，選擇合理的租費套餐。相對以往的開發，在云平臺部署也有不少優勢，畢竟裝載回歸階段很多租費已基本量化。
（注：另外，云應用還需必要的“非云”運維監控機制保證，還要考慮相應的本地信息備份能力，否則“亡羊”都沒處“補牢”。）
上述5個步驟結合Visual Studio 2010均可以較為便捷的完成。不過對于熟悉WinForm應用和ASP.NET應用的開發人員，如何使用Azure存儲機制需要一個適應過程：
（1）、Blob Service：雖然提供二進制信息的存儲，但最好慎用，對于二進制的多媒體信息而言，采用該服務成本偏高，盡管官方有類似的標桿系統，但考慮到資費以及國內調用效率，建議租用或自建獨立的流媒體服務器和文件服務器，調試階段也須慎重安排調用次序和資源訪問路徑。
（2）、Table Service：非常有用，但使用中建議考慮自己開發一些“土法”編碼的JavaScript、XLS函數，在信息提交前將稀疏的用戶數據進行處理，在展現時進行反向處理，例如：一條微博內容為“大勝印尼9個球！！！！！！！！！！！！”，不妨在提交前處理為“大勝印尼9個球/[!12/]”，雖然有些煩瑣但考慮到 Azure的收費方式，能省還是給自己省點。之所以沒有直接提壓縮算法，同樣因為Azure的收費方式，您可以根據應用的內容特點，權宜計算時間和存儲空間。
（3）、Queue Service：是個容易被忽略但其實更容易出彩的服務，不僅僅限于向Work Role發送消息。一方面通過他的異步處理能力，常常可以在相同Host Service 使用的情況下支持多并發用戶；另外，在處理結果（包括：查詢結果）交付方面也有一定靈活性，減少因為多個處理流程爭用資源產生的無謂支出，畢竟本地數據庫死鎖等待一段時間后Kill一方這個處理，資源消耗相對較小、成本低，類似問題出現在云庫（畢竟現階段SQL Azure的鎖處理不如本地 SQL Server的完善）消耗可是實實在在的費用。采用Queue Service可以通過分隔、分工處理流程的方法，將爭用面縮小，讓您的云應用可以“悠著勁兒”的完成處理。
上面關于三個存儲服務的開發、調試均可在Visual Studio中完成，而且區別于調試本地應用習慣看Task Manager，開發云應用不妨直接盯著計費“斤斤計較”。同時，云應用的調試能力是Visual Studio 2010的一大亮點，您之前的ASP.NET Web Service 及WCF調試經驗可以直接搬到Azure平臺，而且調試信息可以直接顯示在您Visual Studio 2010的Console窗口中。此外，啟動調試的過程和本地應用相差無幾。Visual Studio 2010預置了C#和VB.NET的Azure項目模板，借助模板和向導您可以省去很多“八股”內容的編寫，將注意力集中在業務功能上。
另外，對于致力于基于Azure平臺從事大型或長期云應用項目的團隊而言，Visual Studio 2010 IDE的擴展能力（VSX：Visual Studio Extension）很值得研究。
（1）、對于那些準備通過包裝Azure相關服務，進而對外提供Open API（或者是商用API）的團隊，為了便于用戶使用您的API系統，不妨基于VSX提供額外的項目模板或者插件，尤其是提供定位較為準確的錯誤反饋和組織比較系統的調試信息。另外，為了便于編碼方便，可以擴展QuickInfo Tooltips，便于用戶及時、直觀地了解API的內容。相信在第三方云應用Open API新秀還不算豐富的今天，如果您能先走一步提供一套開發人員友好的Open API,也能幫助您在新的平臺占據領先。
（2）、如果您想結合Azure發布商用服務，不妨在說明文檔之余準備一些Code Snippet Library，一方面便于用戶使用您的商用服務，也便于向下游開發者提供“不出格”的示例。不僅如此，考慮到云應用部署方面相對本地應用過程上煩瑣些，建議擴展MSBuild，便于您的下游集成商打包調試、部署他們的系統。
如果您直接向用戶提供基于Azure的前端應用（WinForm或ASP.NET、甚至是類似JSF、PHP的其他平臺），那么不妨用Visual Studio方便的調試功能先開發“胖服務端”，為前端提供更為豐富Façade Interface的同時，借助緩存、壓縮、并行處理等技術盡可能的節省資源使用，進而降低運營費用。
整體而言，盡管微軟通過Azure的開發包盡最大可能降低云應用開發門檻，但畢竟這個平臺還很年輕，雖然理論上您可以借助其他IDE環境完成類似開發工作，但相對Visual Studio 2010還有一定差距。不過，Visual Studio 2010的云計算功能也存在對其他云服務供應商支持不足的問題，云應用開發環境整體還處在諸侯割據的戰國時代。RESTful雖然通用但畢竟成本較高，使用上相對IDE環境有較大改善的 Visual Studio 2010就好像蜀道。
云計算是不會總停留在基礎環境服務這個層面，在主力廠商和大批中小規模用戶的推動下，云應用（或稱為基于云的軟件）預期會更具附加值，從靈感到產品的周期也更短。使用得當，Visual Studio 2010則是實現該目標的利器。
【編輯推薦】
