文章內(nèi)容

開發(fā)者手記：跨云編程煩惱重重

發(fā)布時(shí)間: 2012/7/30 10:31:10

大多數(shù)云應(yīng)用程序都有開發(fā)功能(或至少可以編寫腳本)，允許深度定制，加上一定程度的數(shù)據(jù)庫訪問和計(jì)算能力，但即使是最好的云計(jì)算應(yīng)用程序，也會受到平臺/開發(fā)環(huán)境的限制，應(yīng)用程序不是通用的運(yùn)行時(shí)或通用的對象容器。例如，開發(fā)語言必須為多租戶部署提供安全，不能讓用戶的代碼將虛擬機(jī)，數(shù)據(jù)庫或整個(gè)應(yīng)用程序搞癱掉，此外，某些類型的語言結(jié)構(gòu)必須限制，以防資源被過度使用和死鎖(的確，試想Salesforce.com上運(yùn)行了上億行用戶代碼，要讓它們保持快速響應(yīng)和良好的正常運(yùn)行時(shí)間是一項(xiàng)非常艱巨任務(wù))。

　　拿Salesforce的APEX為例，不需要太多的技巧，語言本身可以處理大多數(shù)業(yè)務(wù)邏輯，但在云開發(fā)環(huán)境中，要受平臺的限制，例如，在J2EE中有一個(gè)很好的庫可以完成你想要的任務(wù)，但J2EE在你的云平臺上是不可用的，即使你只需要這個(gè)庫的一組方法也不行，許多底層功能必須靠你自己實(shí)現(xiàn)。

　　我們舉一個(gè)現(xiàn)實(shí)世界中的例子：許可密鑰生成。軟件廠商可能會使用許可密鑰強(qiáng)制他們的最終用戶簽訂協(xié)議，CRM系統(tǒng)管理這些許可密鑰(作為客戶資產(chǎn)的一部分)，在CRM應(yīng)用程序內(nèi)也可以生成完整的密鑰，因此軟件組織要求將密鑰系統(tǒng)移植到CRM中，其實(shí)密鑰生成也使用的是CRM平臺的加密方法。

　　但是，即使你可以移植所有邏輯到CRM系統(tǒng)，但密鑰生成的計(jì)算負(fù)載仍然要受CPU，堆棧大小和查詢量的限制。

　　解決辦法是調(diào)用一個(gè)毗鄰云中的服務(wù)執(zhí)行數(shù)據(jù)處理，遺憾的是，目前還沒有適合這種情形的設(shè)計(jì)模式，因?yàn)椋?/p>

　　你需要訪問的部分?jǐn)?shù)據(jù)可能因?yàn)檎�，組織策略，安全或其它原因不能移動，還有一種情況是，其它系統(tǒng)也在使用這些需要移動的數(shù)據(jù)。
　　如果你的其它云需要處理駐留在CRM數(shù)據(jù)庫中的大量數(shù)據(jù)，你可能想要的是數(shù)據(jù)的摘要，匯總，歸納或圖形展示，而不是原始記錄。
　　其它云可能對RESTful協(xié)議，如JSON支持得更好，但它們可能對WSDL和SOAP支持得不好。
　　根據(jù)計(jì)算的性質(zhì)，在CRM系統(tǒng)中完成所有工作，只從遠(yuǎn)程云調(diào)用很小的方法可能會很有意義，相反，在遠(yuǎn)程完成所有的工作，作為一個(gè)完整的服務(wù)進(jìn)行調(diào)用可能也有意義。
　　如果計(jì)算需要評估系統(tǒng)狀態(tài)(如工作量，鎖或數(shù)據(jù)變化)，網(wǎng)絡(luò)流量(和結(jié)果延遲)可能會成為一個(gè)嚴(yán)重的問題。
　　安全，測試和部署注意事項(xiàng)不能被忽略，必須隨時(shí)關(guān)注，即使開發(fā)人員，管理員和組織的所有權(quán)發(fā)生了變化，也要將影響降到最低(思考一下將來企業(yè)重組對開發(fā)人員的影響，他們屆時(shí)是否還有足夠的訪問權(quán)訪問其它云)。

　　因此第一步是為你特定的應(yīng)用程序確定最佳架構(gòu)，找出哪些數(shù)據(jù)元素需要傳輸，并跨云重構(gòu)你的類。

本文出自：億恩科技【www.23lll.com】

服務(wù)器租用/服務(wù)器托管中國五強(qiáng)！虛擬主機(jī)域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]