台灣的Web工程師

在介紹完整個大架構後，我們不要忘了當初要討論的最重要問題『我們寫的程式需不需要修改』，我們來總結一下，當我們大架構做成像上一張圖時，我們的程式需要注意或更動那些地方：

• 注意Application層級的資料，每一台機器是獨立的，所以如果需要用到Application層級來儲存資料時，需要確保每一台機器的資料是相同的。

• 注意Session已達成所有伺服器共享。

• 使用者上傳的資料需要另外保管，確保當使用者上傳到某一台機器時，其他使用者連到其他機器也可以看得到上傳資料。

• 資料庫的連線需要切分讀與寫，讀可以用分流的方式處理，但是寫必須是用同一台。

上述的狀況，不應該是程式完成後考慮的事情，而是程式在撰寫的過程中就要想到並處理或預防的狀況；不過，如果沒有大架構的概念的話，一般是想像不到要注意什麼事情的，所以希望讀者要先在自己心裡把大架構的概念先儲放起來，到時候在寫程式時，就會自動注意到了。

最後，上述的大架構，雖然說是把一般情況都想到，並且實行對策，不過，真是只限於一般情況，有一種特殊情況是：

一個網站莫名奇妙就紅了，可能昨天的瀏灠人數不超過100人，結果今天的瀏灠人數超過一萬人，整整成長了100倍。

在這種特殊情況下，以目前的任何架構來說，都是沒有用的，因為流量跟預想的差太多，造成伺服器過度繁忙，甚至排擠到Load Balance來確認機器是否正常運行，造成明明機器是正常運行的，但是Load Balance判斷機器已掛點，所以Auto Scaling自動幫機器重啟，或是閉關此台機器，重新開啟一台新的機器來進行服務；不管如何，在使用者觀感中，都會認定你的網站是掛點的，所以你就有可能被叫去罰站。

這個真的是一種特殊情況，因為它的流量是突然發生的，而不是緩緩上昇的，才會造成機器的誤判；所以，一般如果公司要舉辦活動，會預先評估或假設，預計有多少人連線進入、需要有多少台機器先開機等待之類的，一般會先行完成這些事情，來減低使用者在連線上造成的不愉快。

• 除了這樣的特殊情況外，一般的大架構已足以應付了。