**自：
突然發現自己很久沒有更新部落格了。主要的原因還是這陣子特別懶，沒有努力學習新的東西，光忙著每天的日常任務。佛曰：這樣不好，不好...
這些體會是基於乙個這樣的系統：它包含有十幾個大小不一的模組，這些模組分布在不同的機器上，每個請求都需要這些模組的協作才能夠完成。我不是太好
意思稱它為大系統或者分布式系統，因為它確實還差了那麼點東西。但我也相信，任何乙個真正的大系統/分布式系統也是從這麼乙個系統開始的。
對於這樣乙個系統，訊息通訊模組，日誌模組和監控模組是非常基礎卻至關重要的幾個模組：
訊息通訊模組是一切的基礎。為了使得所有的模組盡可能的獨立和解耦合，並且能夠部署到不同的機器上，你應該讓他
們只使用某種基於網路協議的通訊機制進行互動，而拋棄諸如管道，共享記憶體等方式。這種情況下，
乙個統一的訊息通訊模組非常必要：它提供統一的協議去定義服務的介面；它應該支援多語言，因為你的模組實現的語言可能各不相同；它至少要提供同步的訊息通
信機制，比如rpc，最好能夠有非同步的方式；它的效能會對整個系統有很大的影響。
所以，google有protocol buffer，facebook有thrift（嚴格的說，profocol buffer只開放了多語言之間訊息互動的格式和編譯碼）。當乙個公司的系統越做越大以後，一定會出現這樣的東西。
日誌模組的重要是因為這樣乙個系統的除錯非常的困難。每個模組介面的正確並不代表整個流程的正確，而且一旦出現
問題，定位到問題的發生地點也並不容易，很多時候，唯一的辦法就是分析日誌。這樣乙個日誌模組應該提供：統一的日誌格式，所有的語言輸出的日誌是一致的；
我所了解的大部分這樣的系統都是這麼實現的：每台機器有乙個日誌模組的agent，它收集這台機器的所有模組的日誌，同時有乙個日誌中心，將所有機器的日誌彙總（或推或拉）。模組與agent之間，agent與中心之間的互動也應該都基於訊息通訊模組。
監控模組除了能夠了解到整個系統的執行狀況以外，它也應該能夠用於系統的除錯。因為監控模組對於運維人員和開發人員都很重要。最近一篇很火的文章《stevey對amazon和google平台的長篇大論》中提到「...直到你的監控系統能夠全面性地系統地檢查所有的services和資料，此時，監控系統就跟自動化測試qa沒什麼兩樣了，所以兩者完美的統一了...」，我深以為然。
而且，監控系統應該早規劃早做，不要等到整個系統完成之後才開始上馬，而應該在系統第一次迭代的雛形完成後就開始開發（甚至可以更早），並且隨著系
統的開發而不斷完善。在實現每個模組的時候，都應該要考慮這個模組應該提供怎樣的監控介面，輸出什麼樣的監控資訊。同樣，監控系統和模組之間的互動也應該
基於訊息通訊模組。還有乙個方案就是將監控模組完全構建於日誌模組之上，所有的監控資訊都寫入到日誌，對日誌的統計分析就能夠得到所有的監控資訊。
最後，除了這三個元件，如果系統存在著大資料量的互動，那麼乙個提供統一介面的分布式儲存模組也很有用。gfs，bigtable已經證明了這一點。
關於C ，GDI的一些小體會
1.一般不要在基類中做型別判斷，要在派生類中過載相應函式 總是聽說，就是總忘，今天後面乙個哥們被組長訓，我記錄下來防止我被訓。2.不要反覆做new delete操作，特別不要在迴圈中做這樣的操作，即使自己的記憶體 多nb。反覆做new delete操作，會造成記憶體碎片，在要求記憶體特別高的地方會不...
一些小小體會。。。
接觸sap 與 abap 已經有8個多月了 從當初什麼都不懂的小菜鳥，到如今，可以算是努力擺脫初級，在公升級前的掙扎，最後一段的衝刺。可笑的是，即使擺脫了初級，不再被稱為是菜鳥，離老鳥的尊稱還有很長一段距離。目前為止，浪費了不少時間，在abap 的學習上雖然刻苦認真許多，但是在sap 的相關模組業務...
關於編譯的一些小知識
gnu編譯器 g 編譯 c 程式 在windows下，進入源 所在的路徑下，在命令列中輸入 g o test.exe test.cpp將test.cpp 編譯生成 test.exe 可執行檔案，如果沒有 o test.exe 選項，預設生成 a.exe 在linux下，進入源 所在的路徑下，在命令列...