從2005年-2013年，Ashwanth Fernando曾供職於Best Buy、Pearson VUE、Walgreens、Walmart eCommerce等多家知名公司，現在Apple從事高級工程師、平臺工程師一職，擁有豐富的高流量Web應用程序打造及架構經驗，近日Ashwanth撰文分享了他的高流量Web軟件打造經驗。
下爲譯文
受Joshua Bloch寫的《Effective Java》啓發，我想分享自己關於建立高流量Web軟件的整體建議。這些術語中的一些可能不僅僅關於軟件設計也關於工程組織、文化等相關領域。
免責聲明
- 只代表個人觀點
- 如發現與現實情況相違背的原則，請謹慎對待，或使用一般認識
1. 考慮使用不止一個數據中心
在商務領域，一直存在許多恐怖的道聽途說，而這些恐慌都因爲他們只使用了單一的數據中心。如果你想在自然災害或者電力供應故障中倖免，那麼請使用多於1個的數據中心，使用active-active模式來配置你所有的數據中心。雖然在開銷上可能會有所增加，但是比只使用單active的配置要值得多——因爲在passive和active副本上，總會發現有些數據片不一致。
2. 考慮使用稀疏數據中心部署
不管是通過PaaS，還是運營團隊進行，當軟件集羣被部署到同一個數據中心的機架上時，確保這些機架使用不同的電力供應。你不可能保證機架供電的萬無一失，一旦失敗將會導致整個機架上服務器的丟失，這個時候你絕對不會希望整個數據中心都只連在一個電路上。
3. 考慮使用私有云來組織資源
IaaS開源解決方案Openstack等其他的軟件至今尚未成熟，需要龐大的團隊來運營，在運行期間會產生各種各樣的問題，除非你有足夠的預算，否則別考慮建立一個私有的雲服務。然而，私有云可以提供衆多優勢。首先在部署方面就可以進行衆多的定製化，這遠比AWS或者是Rackspace貨架上的選擇要多。其次它允許你做許多的硬件定製化，就好比在硬件層次的Oracle就比準虛擬化環境快得多。
4. 考慮使用PaaS做解決方案
爲軟件釋放投入巨量人力進行部署的日子已接近盡頭，各個機構在敏捷及快速市場投放上絞盡腦汁，而PaaS無疑會加速這個部署過程。它允許特性儘可能快的發佈，同時也能讓開發者得到極大的滿足。這是個非常好的開始，給予開發者部署集維護自己軟件的工具，這將給工作積極性帶來很大的提高。同時，越來越多的開發者甚至不願意加入沒有自動化軟件部署系統的公司。更少的領導，更簡化的環節，將給你帶來無與倫比的效率。
5. 如果使用Oracle或者MySQL，只做基於主鍵的查詢
只有在RAC中存在很少的Artifacts時，Oracle才能在流量高峯時獲得最佳性能。儘可能避免使用Referential Integrity、Triggers、Materialized Views、Views、Stored Procedures和其他的Oracle Artifacts。Triggers可以在從數據訪問層實現。Stored Procedures可以完全轉移到應用層。數據庫只用來存儲數據，基於字段進行存儲而不是主鍵，使用類似Lucene的索引器做表的索引，使用一個允許在結果集上做基於其他字段的查詢，這將會返回這個記錄的主鍵，而這個主關鍵字可以進一步被用來拿取記錄。<="" p=""></ARTIFACTS時，ORACLE才能在流量高峯時獲得最佳性能。儘可能避免使用REFERENTIAL>
6. 考慮使用Oracle或者MySQL分片
當schema達到臨界點，Oracle的可伸縮性將被限制，這裏建議你對schema做基於功能（比如訂單，產品目錄，促銷活動，客戶等）上的分片，同時也爲高密度表做key shards。爲key shards使用一致性哈希，這樣當一個新的RAC被添加RAC集時，你不再需要遍歷所有RAC中的鍵，以獲悉哪些鍵需要被移動到鍵的分片中。
7. 如果你使用Oracle做RDBMS，考慮使用Data Guard及Golden Gate
使用這兩種技術將大大簡化甲骨文的運營週期，Data Guard允許一個近實時passive讀副本（沒有客戶端會與之連接），而Golden Gate則允許一個近實時的active讀寫副本。
推薦的部署拓撲之一就是爲同個數據中心的每個分片配置1個Data Guard；使用Golden Gate來備份其他數據中心的每一個分片。
注意：Golden Gate只是近實時
8. 爲Oracle或者MySQL添加數據訪問層
假設你有一個可以接受500個連接的Oracle RAC，而你有25個jBoss實例和這個甲骨文RAC對話，每個Jboss實例配置範圍10到50的數據庫連接池。
當jBoss集羣開啓時，連接到Oracle的數目爲250（25乘10），一切運行良好。隨着流量快到jBoss集羣的峯值，想象一下將會發生什麼。在某個點後，Oracle將開始拒絕連接。
因此建議通過一個Multiplexer層建立一個Multiplexe應用程序服務器連接。可以是一個簡單的 netty應用，這個應用運行在一個每個netty節點僅能夠與Oracle建立25個連接的集羣上，但是對入站連接來者不拒。它會將所有的連接循環傳遞給Oracle，但是絕對不會超過25個，同時還使用Oracle JDBC驅動與Oracle通信。
9. 避免跨數據中心事務
當下，這已經是非常簡單的事情，但是在任何地方都非常適用，包括Oracle。在兩個數據不同數據中心，不要適用1個XA適配器去做跨數據中心事務，這將導致相當長時間的應用線程阻塞，直到兩個階段的提交完成，因此將帶來你的應用程序服務、服務和所有同步上傳流崩潰，最終會因爲線程數量增加而導致整個應用程序崩潰，比如在類似Black Friday流量情況下。
10. 考慮分佈式緩存框架
Memcached、Counbase是最常用的選擇。但實際上，卸載非易失性數據到一箇中心緩存集羣上，確實沒必要在每個JVM上做相同的拷貝。但是確實需要設置小數量的JVM堆作爲分佈式緩存的一個MRU緩存，這樣的話，緩存集羣本身將會受到非常少的網絡調用。
- 在JVM上大多數分佈式緩存支持本地緩存的概念，它將儲存最常用的對象。
- JVM上，GC的pause time同樣被最小化了，因爲對象圖中需要遍歷的對象比以前更少了。
- Warmup過程是必不可少的，這可以幫助將數據導入分佈式緩存，這個過程應該在晚上或者是用戶訪問量低的時候。