摘要:[開發心得]雲端前的風雨
取名為「雲端前的風雨」，其實，因為我們的系統、服務還不是架在PAAS上，
雲端的三層，IaaS、Paas、SaaS。
以我的認知（當然有可能不能認同），我只用自己懂的方式講，並一定正確，請在網路上google閱覽
IaaS偏向硬體，基礎環境架構，
PaaS，中間平台服務，
SaaS只要專注在程式系統本身就夠。
而我們找了虛擬主機供應商Linode，
可以為我們提供Linux系統的各種版本安裝，及硬體空間、CPU、Memory的機器
大部分Linode偏向以Memory做分級
512M大概600元台幣，
1G大約1200台幣，
2G大約2400台幣，
所以我們得在小小的512MB的電腦上做我們的服務
開不同的Server，做不同功能的東西，
因為我們做的是網路上，與行動手機裝置有關的服務，
因此，免不了大量的同時連線數。
可能就會去在意他的Connection/sec(cusomter/sec)
這時我們為了應付這種狀況，我們租用了Linode的LoadBalance (負載平衡)
但我們還是被打掛了，
原因我們只有512MB的Server
512MB，經專家的解說，1個使用者上線後，run一個apache就需要4MB
用這個角度去看，所以，約一臺只能服務128人
用這個角度，就知道需要多少臺機器來提供服務，
這方面，當需要大量的連線處理的情況，覺得這時用雲端會比較好，
因為要管機器，管設定，會讓你耗廢太多的功夫去處理，還要找一個專員來維護（若沒有這個專員，那程式設計師，就該死了）。
而要如何使4MB降低為1MB，就要去調Apache或調你的程式碼。
在這之間，使用者連上來時，透過RestfulAPI，
我們可以看是需要傳回資料的，與不傳回資料的，
不傳回資料的，我們可以使用一個Job Queue ( JMS或類似的東西處理)
讓他非同步，收到馬上放掉連線，以增加速度
對於不傳回資料的處理，後面如果有後續的分析處理，可以看是要即時，或近似即時，做不同的處理。
這部分我們使用了Nginx+Node.js處理
另連線上來的log記錄，使用Fluentd+MongoDB處理
http://blog.nosqlfan.com/html/3521.html
而需要回傳資料的，看是靜態或動態頁面，
靜態，我們可以做Cache，這部份我們用Redis做Cache Server。
這就是搞雲端（其實我們還不算真正雲端呢～但雲端就是幫你處理掉這麼多的東西～）
經專家說，每一條連線，要壓到他在100ms結束，
而我們使用Apache Bench來做壓測。
這之中，真的搞這種東西，遇到大量的問題存在，
不再是單純的寫code處理的XSS或SQL injection
現在可能是Dos攻擊居多（也不是Dos攻擊，只是大量連線所造成的Server掛掉問題)
還要去調Apache Keep alive
然後，資料庫，又怕他隨著時間資料越來越多，
又需要做MySQL Cluster
而在一些寫大量資料的地方，所遇到的問題，是寫入的I/O存取不夠快，
資料庫也無法應付
此時就改為NoSQL ，使用MongoDB應付大量短時間寫入的問題，及階層式的資料格式處理(json)。
另為了怕處理的Job造成連線存取過多，而使用的Connection Pool
及為了同時並行發送，而使用的MultiThread
及為了內部Server傳輸速度快速，而自己寫Socket
在應付MongoDB的部分，做水平擴充，
則需要Sharding、驗證，要用OpenSSL產生appkey，要做備援，要做讀/寫分離。
從單純的Java寫最小基本單位Server的Job到，Server與Server之間的傳輸，到外部連進來時的處理
要去調效能，增加所謂的rps。
這一年，真是豐富
-----------------------
後記，我們所遇到的問題，所做的架構分散，
有人寫了一篇佛心的文章分享
「一至千萬的藝術 — 如何養成支撐網路巨量交易的伺服器艦隊」
詳細的圖文解說，現在看了相當熟悉～～(只是，因為MySQL Cluster我們用了相當失敗，還造成DB不見，因此都不敢用了，我想可能還沒寫入什麼備援機制吧～～要備援機制，原本的系統架構還要在組一份出來就可能是兩倍，光基礎需求，就需要9台，而且MySQL Cluster應該還需要一台config server才對。若做超好的基礎需求的話，可能就要20台）
我們光應付十萬等級就很累了～～（冏）
這篇文章起因大概是光棍節，淘寶網撐下了巨量的架構探討
有一篇文章整理了不少連結
http://blog.longwin.com.tw/2013/11/taobao-origin-story-history-2013/
可以方便研究以後遇到相關問題，該怎麼尋求解決之道（但是否有資源可以應付這樣的東西）