現在我們假設香港服務器承載100萬的需求確實來了。
現在有大規模并發需求的IT系統可以分為兩類，一類是淘寶這樣的網站，雖然并發大，但是模式簡單，交互拓撲是無數客戶端圍繞服務器云組成的星形模式，交互總是由客戶端發起，因為http，本質上沒有會話的概念；一類是QQ，微信這樣的及時通信系統，交互拓撲是無數客戶端互相聯系形成的網狀模式（香港服務器云基礎運行是中間人），有強烈會話的概念，會話的生存期有可能會很長，中間有反復的交互。不知道你的系統更像哪一類？滴滴打車應該是屬于第二類的。
如果是第一類，有許多現成的模子可以套
首先，處理簡單的靜態內容，引入反向代理，動靜分離，把靜態內容放到專門的服務器上，進一步可以把靜態內容部署到CDN；
其次，真正困難的是動態部分。
步驟一，讀寫分離，利用mysql的主從復制功能，把數據分發到如果服務器，主服務器只管寫請求，讀請求offload到從服務器；
步驟二，單臺主香港服務器扛不住了，水平分表，垂直分庫，把寫操作按照不同的table，offload到不同的主服務器，現在復雜度蔓延到程序內部了。
步驟三，生意實在太好了，分庫分表也搞不定，上服務器集群。
這個過程中，你還有別的不需要增加軟件復雜度的輔助手段，比如用SSD來放數據庫，加大緩存，但是不知道阿里云是否支持；還有其他軟件手段，比如用NoSQL來處理日志之類特殊的數據。
如果是第二類，也有現成的模子可套。如果不想自己架構，可以先找個openfire之類的XMPP套件用起來，等不行了再擴展。
這類系統的挑戰是有大量在內存中存活的會話，舉個例子把，如果你用TCP來做傳輸，每一個會話在操作系統的協議棧里面都需要有相應的TCB，如果用UDP，那么為了處理NAT，你需要在應用層自己維護映射表。除了了傳輸，你在應用層還會維護大量的狀態機，這也是一個耗內存和耗CPU的活計。
好在你不是第一個，網上搜索一下MSN,QQ,微信，他們的需求和你類似，一般這么解決scalability問題。
通常是垂直分解，把系統分解為若干認證服務器，會話服務器，和補充服務服務器。比如你上QQ，要先認證，那就有只負責認證的服務器招呼你，認證完了，根據當前負載，在會話服務器farm里挑一臺不太忙，離你近的服務器負責你的文字聊天，如果你還想語音或者視頻，那么你在發起語音視頻的時候又按照前述原則給你分配相應的補充服務服務器。你可以想象，認證服務器是醫院的掛號處，會話和特殊服務器就是各個科室。當然認證服務器自己也是可以通過DNS進行擴展的。
這種系統如果遇到數據庫瓶頸，也可以參照前面第一類系統解決。
另外，有些系統的數據具有天生的可分區性，比如UBer，香港的司機不會去搶深圳的單，如果按照這種地理特性去分區，一個虛機管一個區域，既解決了可擴展性還解決了可靠性。
互聯數據HKT4提供香港服務器租用真實硬件獨享，限時首月半價租用，全Tier4認證硬件設備，歡迎用戶聯系24小時在線工程師咨詢。
上一篇：
實現一個行情服務器該使用什么架構
下一篇：
區分香港獨享服務器和vps服務器的幾種方法
