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

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

這樣整個看下來，我們的大架構已經很完整了，不但可以分流，而且當其中的服務器有任何問題的話，可以做到Failover（容錯移轉）；並且如果伺服器不足的話，我們可以在短時間內，透過加入新的伺服器來擴大服務，聽起來似乎都很棒了，不過還是有一些可以改善的空間，狀況是這樣的：

當公司活動結束後，雖然因為活動很成功，所以每天連線的人數有慢慢成長，但是因為還不到當初活動的人數，所以有二～三台機器是閒置的。

其實當我們的完成上一篇的架構之後，整個大架構已經慢慢的趨向完整，不過我們發現，當我們Server機器越加越多的時候，資料庫卻是仍只有一台，此時我們的服務上限變成是由資料庫來決定，端看資料庫能多快回應我們的要求，來決定我們服務的上限。

很明顯的，這是一個問題，但是這個問題要如何改善呢？即然伺服器可以分流，那資料庫能不能也做分流呢？如果可以的話，對程式面來說，又需要做什麼變更呢？

我們先以分流的方式來檢討一下，我們預計資料庫的分流應該達到什麼樣的目的：

上一篇的架構圖看起來似乎很完美了，所以我們來重新回頭檢視一下，使用者會與Web間可能會有的互動；假設我們開設的是一個購物網站，所以我們可能會有二種不同的角色來使用我們的網站，一種是買家，一種是賣家；我們重新以二種角色來考慮使用者可能的功能表。

    買家：

• 登入

如何共有Session

我們在上方有談到Session層級，如果使用者忘了的話，再回去看一下。Session儲放的位置，是由伺服器來決定的，所以如果想要共有各台機器上的Session，可以想到有二種方式：

1. 變更伺服器存取Session的設定。

上一篇談了一些基本觀念，現在我們要來進入主題了。

什麼是大架構，簡單的說，例如我今天一台機器，可以服務200人同時連線，但因為公司要辦活動，所以預計這一段時間會有1000人同時連線進來，為了可以同時服務這100人，所以我們啟動了五台機器同時運作，來解決這個問題。

聽起來似乎很簡單、也很合理，不過我們仔細來研究，就會發現，問題不是想像中的那麼簡單，讓我們一個一個來討論問題與解決方法。

HTTP的三種儲存資料的層級（Request、Session、Application）

資料儲存的意思並不是指資料儲存在資料庫，而是指儲存在記憶體中的資料；因為資料儲存在記憶體中，所以資料不會永久保存，而是經過一段特定的時間後不見，所以下方我們要來討論Request、Session、Application這三種層級的不同。除這這個部份外，大架構因為有一個運作方式中，是：

處理第一次發送的Request，與處理第二次發送的Request，二台是不同的Server，這個機制在下方會談到。

在近年的工作中，最常遇到的問題，就是辛苦開發出來的程式，當真的放到網路上去時，可以承受多少人同時連進來？超過這個人數的話，要怎麼處理？這一類的問題，是在最近幾年中，最常被老闆問到的問題。

關於上述的問題，要找到答案之前，必須先定義好一些前提，畢竟軟體是建立在硬體上的，所以硬體配備的好壞，直接影響了軟體的運作速度。我們必須先定義好我們的程式運行環璄的硬體，關於這一點，如果公司沒有明確的定義的話，建議大家可以直接上網搜尋關鍵字「AWS EC2 Price」來參考一下，在AWS上的各種硬體配備，有其對應的價格，可以當作參考。

當硬體決定下來後，才能開始使用像JMeter之類的軟體來進行壓力測試；不過做完JMeter後，只是開頭問題的第一步「可以承受多少人同時連進來？」的答案而己，至於第二個問題：「超過這個人數的話，要怎麼處理？」的答案，以筆者個人的經驗，只有二個解法：