有段時間沒寫文章了，很快就大學畢業了，放松了一段時間，大四的生活過得有些愜意，放松的太久了，重新緊起

來有些難，但是內心一直在不斷的鞭策自己，今天忍不住了，決定重新開始寫文章。告訴大家這個博客還要繼續更新，

沒有荒廢掉。

這篇文章簡單記錄一下我的云計算平臺實踐，云計算這個概念，總是被不斷的提起，在大三的時候就關注過一段時

間，但是當時一直停留在理論階段，沒有做什么實際的東西，所以就一直沒有寫任何關于云計算的東西，因為我一向是

先實踐，然后總結，再寫文章。大四前半段，帶著我的團隊把一個項目的二期開發做完，然后下半段先是考了一個煩人

的考試，然后才著手將我的云計算平臺實踐出來，平臺的功能很少，因為只是自己做著玩，初衷是希望能夠為學校實現

一個云存儲平臺的，統一學校的數據源，方便學校今后的網絡建設和科研，為學校多做些貢獻。但是學校手頭也緊，公

費買個服務器都困難，只想安于現狀。所以后來只能自己做著玩了，不能因為沒有實際需求就不做了。

這個云存儲平臺是服務即平臺模式的實踐，提供WebService和API供其他應用系統調用，實現了20個接口，因為只

是模擬用的，數據模型做了簡化，只保留核心字段。架構基于Hadoop+Hbase+EJB，大二的時候學了EJB但一直沒有實

踐過，一是因為沒有遇到必須用這個技術的項目；二是考慮到技術門檻，不方便后面的維護。實現平臺過程中遇到一個數

據節點不能為0的錯誤，因為報錯實在是不太明確，讓我一直以為是配置文件的問題，困擾了一段時間，后來發現是關于

用戶權限的linux間無密碼互訪有問題造成的，這個問題本身簡單，但是因為報錯不明確，誤導了我的判斷。

云計算技術還在發展中，隨著很多公司的采用，已經趨于成熟。任何技術都需要通過實踐來發現問題解決問題。目前

來看，云存儲一定程度上可以取代關系型數據庫，關于數據庫事務和高級查詢可以借由第三方組件實現。松散的數據結構

更加利于敏捷實踐，數據模型的字段可以更靈活的變更，我的云存儲平臺數據就是把教務系統的一些關系型數據模型過渡

到基于鍵值對的松散結構中的。對于一些本身就具有映射關系的字段，甚至可以簡化到一個鍵值對關系中來。把所有關系

型數據都打散成為松散數據，確實是很顛覆傳統思維的。但是有的時候逆向思維正是解決瓶頸問題的辦法，比如關系型數

據庫很難低成本的做到在限定時間內從幾TB的數據中，排序并拿出TOP50W的數據。

Hbase本身的一些機制，可以從分布式文件存儲層面就為所有數據提供緩存，對于一次寫入多次讀取的數據效果尤其

顯著。我雖然沒有看過twitter的數據層實現，但是如果讓我設計，我會把最占用存儲空間的數據部分，也就是一次寫入多

次讀取的微博和評論內容部分寫入NoSQL中，穩妥起見把其他對安全性要求高的隱私數據部分寫入MySQL，但是我仍然

可以把常用字段也同步到NoSQL中去以便提高系統性能。這可以看做是云存儲最常見的一種實踐方式。云存儲的另一種常

見實踐則是基于文檔化的分布式存儲，把視頻，圖片，音樂，文件以鍵值對的形式存儲，這些媒介的共同特點都是占用空

間大，一次上傳，多次讀取。這兩者其實可以歸為一類。即使是多次寫入，少量讀取的數據也可以實現一個數據緩沖層，

應對頻繁變更，然后定時定量持久化數據。所以存取比重不會影響對云存儲的使用，因此才有了我之前把關系型數據模型

完全轉化到松散型的做法。

利用Hbase本身的一些設計特點可以讓我們從松散表結構設計上提高系統的性能，比如family列相同的部分會在物理上

存儲在更近的節點上，所以在從關系型到松散型過渡的時候，可以把family列設置為表名，把label子列設置為屬性字段，

這樣同一個表的數據可以在物理上更加緊湊，便于系統更快的取出同一數據模型的相關屬性。family列的定義和修改需要對

Hbase作類似于傳統數據庫的數據定義，而label列則不需要定義直接可以使用，通過這個特性可以使表結構字段動態化，從

而在數據持久層面實現動態化。對于功能獨立的本身具有鍵值映射關系的屬性則可以不使用上述的做法，而采用family列存

儲鍵屬性名稱，label列存儲鍵屬性值，value列存儲值屬性的值的方法。這是松散模型設計可以采用的一種實踐策略。

在業務服務層面分離成兩個層，一個層作為數據操作層，負責對數據操作和事務處理，另一個層作為業務服務層，負責

業務邏輯的拼裝、數據驗證、身份驗證等工作。接口設計方面要保證接口的合理性，清晰性，重用性。目前能想到的就是這

些了。

架構如圖：

總結

以上是生活随笔為你收集整理的云计算实训总结_云计算平台实践心得的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。