系統架構圖：
系統及需求簡介如下，
（姑且把Internet上面部分稱做雲端，但實際上Terminal Node也是屬於系統的一部分，沒有Terminal Node則整個系統就沒有意義了）
1，如上系統架構圖所示，雲端服務器數量相對較少，不做贅述；
2，Terminal Node數量大，我期望的是發展到上萬級別，目前還只數千計，離上萬級別還遙遠，並且沒希望了（我已撤退）；
3，每個Terminal Node都具備計算與存儲能力（有限）；
4，Terminal Node通過Open API與雲端通信交互，當然，與雲端的網絡通信也是沒問題的；
5，需求：目前需要計算Terminal Node端的用戶交互數據（記錄存儲在Terminal Node本地）；
6，雲端可以簡單快速的控制Terminal Node端更新程序等。
最初的設計（我做的計劃）：
1，更新Terminal Node端程序，讓每個Terminal Node計算出需要計算的用戶交互數據集（是否有點類似於Hadoop的Map呢？）；
2，Terminal Node將計算的用戶交互數據集通過Open API傳遞到雲端；
3，雲端的計算程序Ap根據Terminal Node計算的用戶交互數據集再做計算（是否有點類似於Hadoop的Reduce），得出需求的數據結果。
如果按以上設計實現，Terminal Node端與雲端的程序都會非常簡單，效率沒問題，開發容易，實施容易。
（Terminal Node端的計算方法已經實現，雲端的計算只剩下簡單的彙總分組而也，很輕鬆）
但實際實施過程沒能按如上設計執行。。。
實際是這樣實施執行的：
1，Terminal Node端通過Open API與Ftp將用戶交互數據傳遞到雲端；
2，雲端（目前還沒有分佈式文件系統，分佈式計算基礎構件等）把這一大堆數據按大數據對待，專門開發計算程序Ap處理這一大堆數據；
牢騷：
這個設計不是我做的，當然也不是我認可的，但沒有辦法（公司調整，技術開發目前由技術還完全未入行的人負責，還把自己當專家了），以上Ap程序是難點（只做空頭設計的人也把這個列爲難點），這個是硬交給我負責實現的（甚至還讓我把這個程序移交給之前完全不瞭解這玩意的開發C來實現，並且限制3天時間/根本就不可能的事，要分析計算好幾十項數據呢，遇到這樣的同事真的很惱火啊），最後我沒辦法只能咬牙自己花了3天時間趕，基本實現了對幾十項數據的分析計算，再花了一週多時間測試修改BUG，兩週後上線，上線後我再將程序交給了開發C負責，交給開發C後，開發C問我，爲什麼不在Terminal Node端做計算，真是哭笑不得啊！
後記：
0，本來很好的一次分佈式計算，最後被做爛（項目完成上線成功，但事實上已經與分佈式計算無關了）。在完全不懂的人看來這就是大數據與分佈式了，雖然我也還沒搞懂大數據與分佈式，但我知道，這不是！無語。
1，以上開發，爲了效率，我大量使用了內存緩存，只在程序初始化讀入配置與相關數據時訪問一下數據庫，分析計算過程全部是拋開數據庫處理，這部分效率沒有問題；
2，將一個Terminal Node分析計算後存入數據庫，也沒有問題，因爲數據量不大；
3，但是，將多個Terminal Node分析計算後一起存入數據庫，數據庫就有點吃不消了。。。
程序上線運行後發現，瓶頸在數據庫，只能放在後半夜，系統空閒的時候計算，需要兩個小時。。。如果沒有數據庫瓶頸，也就是十幾二十分鐘的事。。。如果玩真的分佈式，就是分分鐘的事了。
總結：豬一樣的隊友不可怕，但是遇到技術問題時，應該堅決制止，一定不能讓豬隊搗亂，拖累團隊，拖累公司。