許式偉、張宴——系統架構運維思路對話

許式偉：做爲系統架構師，您通常會從哪些方面來保證網站的高可用性（下降故障時間）？

張宴：不少因素都會致使網站發生故障，從而影響網站的高可用性，好比服務器硬件故障、軟件系統故障、IDC機房故障、程序上線前測試未發現的Bug、遭受分佈式攻擊、突發訪問人數劇增等。

一套良好的網站系統架構，應該儘量地避免只有一臺服務器、一個數據庫、一套軟件節點等單點故障的存在。單點故障一旦發生，將直接致使網站服務不可用，恢復正常服務所需的時間也比較長，甚至還可能沒法恢復。負載均衡集羣、雙節點熱備、分佈式處理等均可以用來解決單點故障，好比提供相同業務的Web服務器、MySQL數據庫從庫，均可以構建負載均衡集羣。一旦集羣中的一臺服務器、一個服務出現故障，自動實時摘除，對用戶來講是不可感知的，不會影響到整個網站的訪問，能夠爲運維工程師留下足夠的時間去排查和解決故障。

對於重要的MySQL數據庫主庫，咱們習慣於從硬件層和軟件層來實現熱備，避免單點。越是複雜的設備，發生故障的機率越大。在磁盤沒有損壞的狀況下，應用程序致使服務器宕機的機率，遠高於簡單的磁盤陣列宕機的機率。因此，從硬件層解決的話，能夠在兩臺服務器上安裝相同的數據庫版本、進行相同的配置，用SAS或SCSI線鏈接一臺磁盤陣列，將數據庫數據文件存放到盤陣上。正常狀況下用服務器A掛載盤陣分區，啓動MySQL，綁定虛擬IP；若是服務器A宕機，則用服務器B掛載盤陣分區，啓動MySQL，接管虛擬IP。從軟件層解決的話，則能夠藉助DRBD等軟件作鏡像。（主從同步，負載均衡、高可用、緩存）

IDC機房發生故障的機率較小，但若是發生的話，影響面也是最大的。若是全部服務器都託管在一個IDC機房，一旦該機房遭遇長時間流量攻擊、斷電、斷網、地方政策性封網等，一般只能聯繫IDC去處理，除此以外一籌莫展，解決時間也比較長。若是成本容許，將網站服務器分佈在兩個以上的IDC機房，當某個IDC發生故障時，能夠臨時切換DNS域名解析來優先恢復服務。

雖然程序代碼上線前，通過了測試人員的嚴格測試，但測試環境和生產環境畢竟有差別，因此一些會急劇影響性能、正常服務的Bug每每在程序上線以後，纔會被發現，這就要求咱們在發現Bug後，可以迅速回滾到上一正常版本。咱們在SVN的基礎上，開發了Web代碼發佈系統，會將每一個發佈版本之間的文件變動記錄下來，一鍵實現程序代碼在多臺Web服務器上的發佈和回滾。

遭遇DDOS分佈式拒絕服務攻擊，使用防火牆來對付半鏈接、假IP，還算比較容易。而那種專挑複雜動態應用程序URL進行的分佈式CC攻擊，來源爲真實IP、真實HTTP請求，具備模擬正規瀏覽器User-Agent、單個IP的每秒請求數不高、有成千上萬個攻擊源等特徵，很難與正常訪問區分開，比較難對付。可是，正常經過瀏覽器訪問一個URL，會加載該URL中引入的JavaScript腳本、CSS樣式、圖片等文件。遇到CC攻擊，須要及時分析日誌，找出訪問量異常上漲的URL，而後用事先寫好的shell腳本找出哪些IP的請求只訪問了該URL，而不加載該URL引入的文件，對這些IP進行自動封鎖。

系統架構設計時，須要事先考慮到高於目前訪問量多少倍的突發訪問。對於網遊站點來講，訪問量受廣告集中時間段投放、線上活動的影響較大，帶寬峯值時間不固定，對於靜態內容，可使用商業CDN，按實際使用量計費。對於動態內容，若是遇到突發訪問人數劇增，超過現有服務器處理能力，最簡單的臨時處理辦法就是增長服務器。上架新服務器須要時間，可是，同一個IDC機房內，能夠藉助其餘業務的服務器，在不一樣端口開啓一組新進程，加入到原有負載均衡池中。另外，能夠臨時關閉一些Web中的次要功能，來減小服務器消耗。

許式偉：您在任務切分上，有什麼經驗分享？您經過哪些手段保證任務的獨立性？

張宴：相信不少人都遇到過這種狀況：在一個老項目上修改、增長一些新功能所花費的時間，不比從新來作一個包含全部功能的新項目時間用得少。一個須要長期維護的項目，不可避免地會面臨老員工的離職、新員工的接手，不少時候，項目代碼的可維護性將決定一個項目的生存週期。讓一個新員工在規定開發時間的壓力下，去面對一個文檔不夠詳細、陌生的、功能複雜的龐大項目，短期弄明白全部功能邏輯不是一件容易的事。因此，任務須要切分，將一個大的任務切分紅一個個小模塊以後，各模塊之間能夠作到代碼獨立，互不影響，可維護性也大大加強。

關於任務切分，我以本人今年負責的兩個重要項目架構設計爲例來介紹一下。在第一個項目：金山遊戲官網的《用戶行爲分析系統》中，因爲數據挖掘計算須要消耗較高的內存、CPU資源，一臺服務器的處理能力不夠，而商業的分佈式數據倉庫價格又太貴，因此，只有從程序應用中下手，進行任務切分。咱們先按須要挖掘的數據指標，將整個數據挖掘任務切分紅多個數據挖掘插件，每一個插件能夠在不一樣的服務器上運行，多個插件能夠同時在多臺服務器上。多個數據挖掘插件之間，若是用到相同的某項數據，那麼，就將該項數據以冗餘方式，複製幾份提供給須要的插件，從而實現插件之間無交互、無關聯，保證了超大數據量下插件的運算速度。

在第二個項目：金山遊戲新版運營管理系統中，則將整個任務切分紅了PHP Web管理界面、PHP Web API功能接口、C/C++中間件引擎三部分。這是一種分層結構切分，最上層的「PHP Web管理界面」調用「PHP Web API功能接口」，「PHP Web API功能接口」調用運行在遊戲服務器端的「C/C++中間件引擎」，「C/C++中間件引擎」與「遊戲服務器端進程」經過TCP、UDP二進制協議、信號、命令行等多種方式通訊。四者之間相對獨立，代碼無關聯，經過一層層API接口實現交互。「PHP Web管理界面」負責通用界面實現。「PHP Web API功能接口」內部，又按接入的遊戲模塊、子功能模塊進行了更細的切分，各功能模塊之間經過內部API交互。「C/C++中間件引擎」大而全，不處理具體指令，但兼容TCP、UDP、HTTP、HTTPS/SSL、信號、命令行等大多數通訊方式，負責和各類類型的遊戲服務端交互。這是一套徹底由API接口驅動的系統架構，一款新遊戲接入運營管理系統時，只需在「PHP Web API功能接口」中增長一個模塊；一個遊戲新管理功能的增長，只須要在「PHP Web API功能接口」中增長一個子模塊。經過任務切分，將複雜功能簡單化，也將原來接入一款新遊戲所須要的幾個月時間，縮短爲1~2周。

許式偉：您經過哪些手段，來保障產品的質量？您傾向於多久更新一次您的網站？

張宴：Web產品質量主要體如今架構、功能、性能、安全、代碼惟一性、兼容性等方面。

架構方面，我會先設計一套架構方案，而後讓和項目相關的人員、專家組成員參與進來，一塊兒探討和論證架構的利弊，提出改進意見，保證架構的可行性。全部重要項目的技術方案須要通過專家組的評估。

功能、性能方面，則會由專門的測試人員進行功能測試、壓力測試、安全掃描，測試環境分爲線下測試環境、線上準測試環境。

在代碼惟一性方面，咱們開發了一個Web配置信息管理平臺及相關PHP擴展，提供給系統工程師，用於配置信息的統一管理。在新項目中，PHP程序配置文件中將再也不出現MySQL、Memcached等各種IP和端口信息，統一用Web配置信息管理平臺給出的變量代替。從「開發環境→線下測試環境→線上測試環境→線上正式環境」，鏈接的數據庫各不相同，致使PHP開發工程師常常搞混淆或忘了修改，經過Web配置信息管理平臺，使得PHP代碼中的配置文件，在四個環境中無須做任何修改，保證了代碼的一致性，下降了出錯率，從而確保了產品質量。

在兼容性方面，咱們從操做系統到PHP、MySQL版本，都保持開發環境、測試環境、線上環境的統一，全部的Web服務運行在CentOS Linux系統上。因爲大多數PHP程序員習慣於在Windows上編寫代碼，而咱們的程序中調用的一些接口、PHP擴展，只能在Linux下運行。爲此，咱們開發了一個小工具，能夠將多名程序員在各自本機Windows上搭建的nginx虛擬主機、編寫的程序文件，映射到一臺Linux服務器，用Linux上的php-cgi執行Windows上的PHP代碼。這樣，PHP程序員修改完本機代碼，保存一下，便可調試，多人之間互不影響。本身調試經過後，能夠在Windows直接點擊鼠標右鍵，將修改的代碼提交到SVN版本庫。

Web 2.0時代，講究網站更新的實時性，動態網站不用說，靜態網站的內容發佈也要保證明時。咱們開發了一款名爲Sersync的開源軟件（http://code.google.com/p/sersync/），使用Linux 2.6內核的inotify監控Linux文件系統事件，被監聽目錄下若是有文件發生修改，Sersync將經過內核自動捕獲到事件，並將該文件利用rsync同步到CDN源站服務器。Sersync僅僅同步發生增、刪、改事件的單個文件或目錄，不像rsync鏡像同步那樣須要比對雙方服務器整個目錄下數千萬的文件，而且支持多線程同步，所以效率很是高。金山遊戲官網的CMS內容發佈系統，不管網站編輯經過Web仍是FTP上傳圖片、視頻、附件，仍是系統工程師直接去CMS發佈服務器上增長、修改、刪除文件，幹完這些事情後不用作任何處理，Sersync 會自動將發生增、刪、改事件的文件同步到CDN源站服務器，並能夠在文件同步完成後，自動調用CDN緩存刷新接口，主動刷新發生修改、刪除的文件的訪問URL。

許式偉：您在面試時，一般關注應聘者的哪些方面？哪些問題常常會問呢？

張宴：第一，須要具有崗位要求的基礎技能知識，這方面我再也不詳述。

第二，注重項目經驗與積累，不看重學歷與工做年限。作一個項目，猶如打一場戰役，身經百戰，積累下來的成功經驗可讓工做更駕輕就熟，失敗經驗能夠避免走不少彎路。

第三，可以在1~2個以上技術領域精通。所謂術業有專攻，可以在某幾項技術領域作到精通的人，相信對於新的技術領域或者從未有過相關經驗的新項目，也可以輕鬆勝任，作到盡善盡美。

第四，關注應聘者的知識廣度。現在的項目，已經告別我的英雄時代，講究團隊的協做。知識面越廣，儘管在非專攻領域的深度可能不夠，可是，知己知彼，能夠站在一個更高的角度上看問題，這對於團隊協做開發、項目融合的益處是顯而易見的。

第五，具有良好的領悟能力、思考能力、設計能力、創新能力。基礎技能知識不夠能夠學習，經驗不足能夠積累，技術不精通能夠鑽研，知識面不廣能夠開拓，但要培養這四項能力，是一件很是困難的事。要打造一支優秀的團隊，這四項能力不可缺乏，它們的重要度甚至超過以上的四方面要求。

我不會常常去問固定的問題，但所問的問題，幾乎都跟以上的這些方面相關。

許式偉：您曾嘗試開放本身的程序代碼嗎？您對中國國內開源社區的現狀有何見解？

張宴：是否開源本身的程序代碼，跟所在公司或部門的性質有着密切的關係。若是是在研發驅動型企業或部門，程序代碼是公司生存的命脈，須要與競爭對手拼技術和保持技術領先的優點，所以，很難支持開源事業。反之，若是是在運營驅動型企業或部門，技術是用來提升運營質量、運營水平的工具之一。將純粹的技術代碼或產品，從公司的業務產品中提取出來，進行開
源，能夠按照開源產品的要求，提升公司內部技術產品的規範化、標準化，還能夠引用更廣大用戶的使用、反饋和意見，解決未發現的潛在Bug，改進代碼質量，提高技術水平。對於提升運營質量、運營水平來講，益處多多。我也嘗試開源本身的一些代碼，例如簡單消息隊列服務HTTPSQS（http://code.google.com/p/httpsqs/）、MySQL HTTP/REST客戶端MySQL-UDF-HTTP（http://code.google.com/p/mysql-udf-http/），同時，也鼓勵團隊成員嘗試開源，例如剛纔提到的自動同步軟件Sersync。

國內的開源社區在不斷壯大，不少知名互聯網公司都開源了本身的一些產品，但大多數還只停留在開源產品的使用、技術交流、漢化層面，真正參與到開源產品編碼中的人仍是較少，不少開源產品最終仍是由原做者或原公司團隊維護。國內開源社區的道路仍然漫長。