【51CTO專稿】2011年京東商城碰到了嚴重的流量相關的性能瓶頸，51CTO也做了專門的報道，我有幸在6年前主持開發過日流量千萬級別的系統，所以也在微博發表了一下自己的觀點（具體詳見 http://os.51cto.com/art/201111/300247.htm）

不是每個人都有幸親自參與并主持設計大型網絡應用的，我應該說就是其中的幸運兒之一吧。我在2003年畢業后投身IT界，先是在國內某知名的棋牌游戲公司擔任了3年的程序員；06年有幸參得到一個機會主持開發了一個日流量2000萬級別的互聯網應用。09年轉做市場運營，時間過去3年多了，現在技術日新月異，或許當年的設計已被替代。作為一個技術圈的退役老兵，仍堅持將自己的設計模型寫出來，跟大家分享學習，并歡迎大家批評指正。

本文只做拋磚引玉的作用，具體實施歡迎與我互動。

項目概況        某大型網絡應用，含普通的用戶功能（如登錄、信息修改等）；含信息發布功能；含統計功能（如信息查看、點擊等）；以及其他周邊功能。

硬件配置        數據庫服務器1臺；中央應用服務器1臺； web服務器20臺（可靈活擴充）。

設計思路

1. 通過購買專業的DNS服務，將域名流量按照區域（如北京，浙江等）和服務商（如電信，網通等）分發到不同的web服務器N,在每一臺web服務器安裝并部署web項目；每臺web根據用戶的不同命令讀寫本機緩存XML；
2. 中央應用服務器定時的獲取多臺web服務器的緩存xml文件，進行應用級的數據分析匯總，并將結果寫入數據庫服務器；
3. 中央應用服務器定時的獲取數據庫服務器信息，并同步到多臺web應用服務器。

設計難點及解決辦法 

WEB服務器版本控制

解決辦法：為每臺web服務器配置并標注好版本號；在中央應用服務器做好版本兼容性工作。如：web程序的統計功能，新版本V1.1去掉了老版本V1.0中的IP統計。Web服務器1的當前web版本為V1.0，Web服務器2的當前版本為V1.1。在中央應用服務器需提供兩個方法，TongJi-v10()和TongJi-v11()。在v10的方法中先做數據校正，再調用新方法v11。

中央應用服務器海量數據傳輸

解決辦法：假設一臺服務器承載200萬的流量，將產生大量的應用數據。可以先將這些數據在web端進行壓縮后再傳輸，能節省80%以上的帶寬成本。



數據的及時性

數據及時性是使用文件緩存比較棘手的問題之一。

解決辦法：對數據及時性進行歸類。在設計期間，我們將數據的及時性簡單的劃分為三個級別，按需，高及時和非及時。按需數據立即同步；高及時信息每10分鐘同步到中央應用服務器，低及時信息每小時同步。這其中，比較有意思的是一些看似按需的操作也并非真正的按需操作。如用戶密碼修改，修改后的密碼密文就存在web服務器N的xml配置文件中，就能確保用戶使用新密碼登錄。用戶在沒有切換線路或者更改區域的情況下，仍然是使用的web服務器N，也無需按需同步密碼數據，只需要高及時同步。

數據的安全性

大量Web服務器存在著大量的數據，甚至包含賬戶或者資金信息，某種意上講這些數據是不安全的。

解決辦法：文件存放路徑、加密、模糊。不要將xml緩存文件存放在web路徑可以供用戶下載的地方，配置絕對的硬盤路徑來設置配置文件的讀寫。如賬戶的密碼只存取MD5加密字串，如資金采取多套對稱加密算法加密，用不要用password來標識字段為密碼而采用I1，不僅能模糊字段還能節省磁盤及后續傳輸消耗.

作者簡介： @365姜志林 ，3年程序員，4年cto，2年的市場運營，專注于數據分析和SEO策略，拒絕YY，用數據和結果說話。