嗯，今天早上來，出了點問題，緊急處理了一下，現在才有點空，咱們接著來。
可能細心的網友注意到了，我這段時間關於傳輸講得很多，這還是有一點原因的。
雲計算，我的理解，至少是乙個伺服器集群，即多個伺服器組合構成的對外的乙個綜合資料計算服務體，現在很多雲的討論，虛擬化啊，大規模啊，其實都在論述這個話題。
為什麼要大？我的感覺啊，不一定準確，在人類社會的歷史中，人和自然界搏鬥的過程中呢，個人的力量總是很渺小的，所以人們組成社會，試圖以全社會所有人的力量，來辦成一件什麼事兒。
古時候的長城、金字塔，嗯，現在的三峽大壩，前兩天看的矮寨大橋，這在個人的力量看來，是不可想象的，但我們辦成了。
所以我理解，人類的發展，始終存在乙個量變引起質變的規律。即一門技術，乙個辦法，剛開始個體的時候很渺小，但是我們不管，埋著頭努力去做，做到一定程度，做到一定規模，經過某個關鍵的節點，它能起的作用就會發生質的變化。
我理解之所以大家從一開始的伺服器，伺服器集群，最後進化到雲這個概念，一定是順理成章的，其實就是希望用量變引起質變這個自然規律，通過一定計算資源的積累，最終實現改變人們生活的這麼乙個大目標。
嗯，由感而發，不一定準確啊，歡迎**。
ok啦，既然是走社會化合作路線，那我認為我們是不是可以參考當前社會上的一些模型來推導雲的構架和技術呢？我覺得是可以的。
我沒學多少社會學知識，知道得很淺，不過我認為起碼有如下一些規律可能可以套用。
首先就是溝通渠道的統一，我們國家建國後，推廣簡體字，普通話，嗯，這個見仁見智啊，罵的好像也不少，但我認為有用，為啥，乙個國家如果連說的話，寫的字都不統一，怎麼看都不像個國家。
只有首先大家都用同一種語言說話了，寫同一種文字了，大家才可能溝通嘛，不然，雞同鴨講，誰也不理解誰，那社會合作根本不可能，也就不符合集中力量辦大事的原則。
秦始皇那會兒，我認為他至少做了一件好事，車同轍、書同文，即統一度量衡和文字，在他之前，北方各國，都在抵抗匈奴，結果呢，時不時被人偷油。秦始皇一來，嗯，先解決溝通問題，再解決標準問題，然後，開幹，長城出來了。就這麼簡單。
所以我認為，長城哪，三峽哪，原子彈哪，這些個大工程，大事情，沒有個統一的社會溝通環境，人文環境，甚至文化環境，其實要做起來基本不靠譜。
雲也一樣，這世界上不止一家廠商生產計算機的，pc也不是這個世界上唯一的計算機，windows也不是唯一的作業系統，unix也不是嘛。
任何乙個企業的伺服器集群，肯定不是一天，在同乙個廠商，下同乙個單子採購的，都有個循序漸進的過程，ok，所以我認為，「要想構建雲，傳輸要先行」，只有在雲裡面的計算機，都用同一種語言說話了，都能理解彼此對方了，這個雲才能叫做雲，才能形成合力，對外實現整體性服務。
tcp/udp都是很好的協議，我認為沒有這種已經成為事實標準的協議支撐，雲其實是空談，為啥？缺乏溝通標準，咱先別批評協議的好壞，好歹它是標準，世界上大多數計算機支援，這就好比英語一樣，我也討厭，但是它是世界上的溝通標準，咱要想和國際接軌，有時候就得學點，你說是不是？
但是tcp有侷限，ipv4下網段小，ipv6都不行，別看ip位址多，但是出於資訊保安的目的，我推測，即使是ipv6下，nat裝置、路由器、防火牆不會減少，可能還更多，因為大家至少需要圍出乙個小圈子，保護自己這個小團體內部的資訊保安。
但是，911事件之後呢，各個企業都慌了，異地容災這個大話題第一次被大家重視，試想，如果乙個企業所有的資料伺服器都在當時的世貿大廈上，嗯，估計只有倒閉了。
所以後來提出全球部署，異地容災計畫。
這個呢，我覺得有好有壞，好處是資料安全了，壞處是資料訪問不便利了，畢竟災難只是少數，大多數人們還是以使用資料為主。
所以我認為，以後的雲如果不能實現高安全級別的跨網段自由訪問，其實是空談。也就是說，雲應該是個邏輯概念，它可能被定為、部署為覆蓋多個網段，遠距離的n個伺服器乃至伺服器集群的乙個統稱。
所以我在前面一直討論傳輸，討論p2p+***傳輸模式，我潛意識裡面，都在為這個至少是我理解的未來運維模型做準備，我想會有一天用上的。嗯，大家覺得呢？
好，第乙個話題說完，我來說第二個。
第二個我認為很重要的社會規律就是社會分工。
乙個雲的建設成本是很高的，我想沒有哪個建設者會希望這個雲只做一件事兒，哪怕他再有錢。
肯定是在力所能及的情況下盡量多賺啦。
所以我的理解，雲裡面也不應該只定義一類計算機，一種業務，乙個優化方向，它應該是根據使用者應用，可以彈性擴充套件的，包容多種型別計算特長的計算機的組合。有資料儲存方向，有計算密集方向，嗯，可能還有網路密集方向，等等。
所以，我定義這個私有雲從一開始就沒打算只買一台計算機，只做一筆業務，所以我不選nas，所以我選擇amd的e350這類atom級別的cpu做我的第一台伺服器。
滿足我給它定義的應用需求就好了，不指望它面面俱到，這個伺服器集群裡面以後會有新成員，每人負責一攤子事兒，自己在自己的一畝三分地兒上做到最好，就夠了，因為雲是作為乙個整體對外服務的，看起來還是一家子。
所以我強調私有雲的伺服器裡面根據業務細分，分別量身定製化採購。
第三，對於這個私有雲的規模呢，我也有考慮，作為實驗性系統，能滿足我一些小規模家庭應用的基礎就夠啦，也不準備多投，但是，這個試驗計畫至少要做到一點，就是實現平行擴容的可能性，即有一天我需要的時候，也有足夠投資的時候，我可以輕易把它擴得很大，無非是買計算機而已，技術上不要有什麼難點，這樣它的計算能力就是彈性的，有擴容性的，是有實際使用意義的。這就是我的目標。
資料發布和使用其實帶來另外乙個話題，即能夠從雲中獲取資料，以普通使用者習慣的方式展示資料的平台算不算雲的乙份子？
我在10年的演講中表示，雲計算，離不開乙個端，我想，也算也不算，可能保持一種彈性更好。
比如以後的平板電腦，手機，它在和雲互動的時候，就是雲的乙份子，是雲的觸角，而打**的時候，就是單機裝置。
嗯，其實可能也不是單機裝置，事實上，我認為它是另外一朵雲，電信語音雲的觸角，乙份子，所以，以後可能是這樣一種模型，計算空間中存在大大小小，各種各樣的多種雲，終端與雲分離，但保持每個雲的訪問能力，一切按需出發，使用者需要哪種服務了，就和哪朵雲建立聯絡，開始服務，服務完畢退出，我想以後的終端更多是這樣一種身份。即「雲訪問器」。
網路速度其實並不是我考慮的重點，為啥，只要是錢能解決的問題，我認為都不是問題。現在我是個人，財力小，咱就小著玩，以後有機會了，咱多投點錢，買就是了嘛，所以我沒太擔心，這不是我關心的重點。
嗯，第四，還有個很重要的思考，雲合作。
大家有沒有想過，雲與雲之上，還有什麼模型？這個我思考了一點點。
我想，無論是定義「雲組」也好，定義「大雲」也罷，無非是概念問題，雖然雲的建設目標是很大的，但是，沒有人可以做這個世界上所有的事情，以後的雲，也會有其創始人特徵，有它的擅長方向，那麼，雲和雲之間的合作勢在必行。
所以我設計這個私有雲的時候，一開始就把朋友的家庭納入考量的。我希望尋找一種可複製的模型，讓有興趣的朋友們自己在家裡也建設，然後我來解決雲間資料合作問題，這樣積少成多，集腋成裘，也許，有一天雲真的在家裡就能建設，形成一種鬆散型的「大雲」。
就這樣人人為我，我為人人，也許我們以後真的不需要花太多的錢，也不需要按月給某個運營商交昂貴的使用費，就可以享受到海量資料，高效能計算服務等雲優勢。
我期待這麼一天。
我的家庭私有雲計畫 12
嗯，今天早上來，出了點問題，緊急處理了一下，現在才有點空，咱們接著來。可能細心的注意到了，我這段時間關於傳輸講得很多，這還是有一點原因的。雲計算，我的理解，至少是乙個伺服器集群，即多個伺服器組合構成的對外的乙個綜合資料計算服務體，現在很多雲的討論，虛擬化啊，大規模啊，其實都在論述這個話題。為什麼要大...
我的家庭私有雲計畫 3
我還第一次寫這種 性長文，主要是最近天涯上的多，看了不少，想仿照這個文體試試啊，咱寫到哪兒算哪兒，盡量不太監哈。呵呵。事實上很可能太監，因為我這個計畫準備進行很長時間，這個話題可能也會延續很長時間，中間可能很長時間不更新，但每個階段性結果完了我都盡量會寫出來，給大家匯報一下工作。直到我做不動，或者不...
我的家庭私有雲計畫 21
嗯，好久沒有寫博文了，有點對不住大家。根據我的測算，如果使用普通序列庫，大概3500秒才能把10000個公式解析一遍，前提還得是公式中不能有太多讀點動作。嗯，這個效能，大家覺得能不能賣錢？所以有很多說，不要做重複造輪子的事 這個用造好的輪子我也不反對，但總得有的用才行啊，沒得用咋辦？還不得自己造。我...