轉載：
p.p1 {margin: 5.0px 0.0px 5.0px 0.0px; font: 18.0px SimSun; color: #1e39f6} p.p2 {margin: 5.0px 0.0px 5.0px 0.0px; font: 12.0px SimSun} li.li2 {margin: 5.0px 0.0px 5.0px 0.0px; font: 12.0px SimSun} span.s1 {text-decoration: underline} span.s2 {font: 10.0px Symbol} span.s3 {text-decoration: underline ; color: #1e39f6} span.Apple-tab-span {white-space:pre} ul.ul1 {list-style-type: disc}
主持人：馮大輝
孫立：你是如何在架構層面，提高開發人員開發效率的？比如通過合理的分層，不同層安排不同能力的開發人員。
孫朝暉：首先孫立老師已經談到了這個問題的兩個核心，第一是合理的分層，第二是讓不同能力層次的隊伍有機組合。
- • 對於分層，具體到我們的技術體系，可以清晰地分成四個層次，對應四個技術層次，分別是：前端（JavaScript開發）、Web應用（PHP開 發）、中間件（Java開發）和通信與管理基礎（C開發）。各層有獨立的團隊，開發人員專注於本層次的技術發展，各層次的開發團隊Leader每日進行晨 會交流開發進度，每週例會進行技術整合研討。對於較完整的功能模塊，設置有“技術方案評審會”，各團隊專家參加，通過對各層技術特點的分析，綜合考慮方案 的可行性。
- • 對於組織結構保證，每個團隊都會有1~2名技術專家，1名團隊Leader，若干開發人員。每個團隊的技術專家負責開發基礎框架，比如我們PHP 應用的MVC框架、Java的Service Framework、前端JavaScript的基礎類庫，對於不同層次的開發人員根據能力安排角色，決定擔任部件級別開發還是組合功能級別開發，保證每 個團隊都有不同層次的人員合理組合，每個開發人員都保持技術上升通道。這樣會有效地提高開發效率，同時每個技術人員都有清晰的當前定位和未來定位，有利於技術團隊的成長。
孫立：要變更數據庫結構，有什麼經驗可以分享？
孫朝暉：這個問題是互聯網行業的通用難題，數據量大，數據結構變更的代價太大，對於這個問題，我想從四個方面進行介紹。
- • 在技術方案評審階段，充分考慮數據存儲方式的合理性。不是每種數據都適合採用數據庫存儲，有些數據適合採用JSON，或者採用緩存中的List對象存儲，而不適合分解到數據單元，這樣的數據就沒有必要設計成爲關係型結構。
- • 在數據結構設計過程中，保留適當的冗餘字段，尤其是預估有動態變更的數據結構，而且狀態標誌儘量組合成爲數據位結構，即典型的Mask應用。需要擴充狀態位時，採用位擴充的方式替代字段擴充。
- • 對於數據量很大的數據結構，比如我們業務當中的Feed數據，保持數據按照代齡進行分層，並且有合理的歸檔結構，保持活躍數據所在庫的規模不過度，對於活躍數據庫需要緊急調整的時候，變更代價也是可控制的。
- • 對於數據量非常大的數據需要調整數據結構，那麼只能靠數據庫架構解決。我們採用的數據庫架構都是M-M-S-S架構，需要進行大規模數據遷移，所以會利用備份庫進行輪換下線（或半下線）維護變更，通過輪次的數據結構調整，最終達到數據結構完全變更。
孫立：如何搭建更加有效的測試環境？測試環境和線上環境畢竟不可能完全一樣。
孫朝暉：我想分成兩個方面來回應。
- • 功能測試環境的建設：功能測試環境主要面對的挑戰不是線上、線下系統結構不一致，而是測試數據的不一致，由於數據不一致導致某些邊界條件沒有測試 出來。對於這個問題，需要保持線上、線下關鍵數據的增量同步，採用小時間粒度的定期日誌備份方法解決，同時要保證活躍數據的規模，以便能夠控制線下數據庫 同步的規模。
功能測試環境組建的另外一個要點是關注網絡結構的等價性，通過虛擬機系統增加與現網等價的網絡拓撲結構。尤其是在交換設備和域名系統上儘可能保持一 致，因爲有很多問題是由於物理部署結構引起的，從開發的角度很難發現，只有通過一個相對完整的功能測試環境方可發現這一類問題。
- • 性能測試環境的建設：性能測試環境的建設主要用於發現性能問題和容量規劃。對於發現性能問題的目標，只要保持數據庫服務器儘可能使用物理主機，在物理主機上採用多實例隔離的模式部署，其他服務器可採用虛機化技術，這樣可以保持測試數據的可用性。
需要解決的主要問題是容量規劃這項工作，由於線上與線下服務器的硬件類型和規格不一致，網絡拓撲結構也不同，也無法完全模擬線上環境。所以我們一般 採用的方法是，對服務器進行角色類型劃分，同一種角色的服務器在性能測試環境下必須有統一類型的服務器對應，有對應的確定性物理配置，在性能環境測試後， 首先安排預上線測試環境，通過七層交換或者應用程序本身的流量複製，把線上的服務壓力導流到預上線環境，進行小規模再測試，得出單機的性能數據與性能測試 環境的對比，並根據單機的性能測算對比，做出線上的容量規劃。按照容量規劃進行系統實施後，根據實際的測試數據再調整，有可能因容量估計過高，服務器能力 有冗餘，需將服務器標記爲空閒，留待後續部署使用。
孫立：你如何看待NoSQL的？
孫朝暉：我們在建設Feed中心時經過了對NoSQL的充分測試，比較了多種NoSQL技術方案，包括 Cassendra、MongoDB、Redis和MySQL HandlerSocket，最終我們採用了MySQL HanlderSocket作爲我們的NoSQL解決方案。
NoSQL對SNS類的應用場景來說還是很實用且必要的。因爲我們要求的Write throughput很大，數據結構簡單，僅需要弱一致性，所以在這種場景下使用NoSQL還是比較合適的。
但對於目前主流NoSQL產品推崇的自動分區等高端功能特性，我們經過測試和權衡還是覺得很難用到實際場景下。一方面是這種自動化分區管理功能使得 系統自身的複雜性太高，部署和監控複雜；另一方面是NoSQL產品缺乏專用的備份工具，系統出現單點故障後，恢復的代價太高，給運維造成了很大的壓力。
我們最終選擇實用MySQL HanlderSocket作爲NoSQL解決方案的原因是此方案能夠利用MySQL數據庫本身的全部分佈式特性和管理特性，系統可控性更強，對於運維、數據老化處理、性能調整等方面都有成熟的方向。
對於NoSQL本身的發展和應用方向目前我個人還不是看得很清楚，例如幾乎全能的Redis出現，大家會如何使用？在我們的技術體系內使用Redis作爲內存緩存，替代了Memcached，沒有啓用持久化功能。
我個人認爲，採用NoSQL技術還是需要經過充分評估的，尤其是與物理架構設計師和運維部門充分溝通，平衡開發和運維的整體工作壓力。另外使用之前儘量充分閱讀源代碼，具備自我技術支持能力後再投入使用。
孫立：你如何看待橫向擴展（Scale Out）和縱向擴展（Scale Up）？
孫朝暉：我個人認爲，Scale Out是互聯網服務的必由之路，分佈式技術是互聯網服務不可或缺的技術能力。但隨着服務器規模的不斷擴大，運維的壓力會越來越大，到了一定系統規模，必須 迴歸到提升單機QPS能力的方向上來。但是我覺得這裏的提升單機QPS不是簡單的ScaleUp，而是一個綜合優化的過程，比如下面這些實例。
- • 我們採用配置了SSD卡的服務器，以本地存儲方式替代SAN存儲設備作爲MySQL數據庫的文件存儲，提升了MySQL單機訪問能力。
- • 我們正在測試使用虛擬機的方式，將Java中間件的物理服務器分拆成爲多個虛擬機服務器。由於受到JVM的內存限制，我們的單機中間件服務器始終沒有得到充分的利用，可以嘗試一分多，提高系統並行訪問能力。
- • 對單機的性能提升，我們更傾向於在單機內部採取應用結構內的Scale Out方式，比如剛纔說的虛擬機拆分，還有使用異步I/O替代多線程、對象池技術等，最後可能採取選用內存升級或CPU升級的方案。而Scale Up僅是爲了滿足某個具體需求採用的綜合解決方案的一個組成部分。
孫立：大型網站往往會將多種語言進行融合使用，關於這方面，你有什麼經驗分享？
孫朝暉：這是一個互聯網行業遇到的通用問題，由於互聯網行業採用開源軟件比較多，往往由於開源軟件的引入，引入了一些非本服務體系內的主流開發語言，比如Scala、Erlang等。這個問題我有兩點想說。
第一，在我們的技術體系內，我是比較傾向於減少開發語言使用的。我們每個層次採用的技術都比較確定，Web採用PHP，中間採用Java，基礎通信部分採用C語言開發，個人認爲引入太多的開發語言和技術，會對技術團隊成長和線上業務的可維護性帶來很大的問題。
第二，雖然我們的開發技術較少，但仍然有異構平臺之間的通信問題。在我們的業務中，還有一部分是用Windows平臺C#技術開發的。爲了解決異構 通信的問題，我們自主研發了基於ProtocolBuffer序列化協議和TCP的RPC通信協議，分別使用C#、Java、C（包括PHP Extension）開發了RPC的通信協議棧，解決了跨平臺通信問題。當然選用Thift也是一個不錯的選擇，我們沒有選用它主要是爲了兼容我們IM軟 件的採用SIP協議。我認爲解決異構系統通信問題的需要考慮以下幾點。
- • 在技術層次之間的通信協議儘量不要選用某種語言的私有標準，尤其是數據序列化，這樣有利於擴展到通用的技術平臺。
- • 在通信模型上儘量選用通用設計結構。比如我們的進程間通信模型選擇了Unix Domain Socket，保持與遠程通信方式接口一致，保持可一致性，方便於服務的物理架構遷移。
- • 在開源軟件選擇上儘量選擇我們技術標準範圍內的技術。如果沒有找到對應項，一般選擇改造現有相似開源軟件或者獨立開發的方向。由於我們選擇Java和C開發技術，開源軟件很多，目前來看還沒有出現某個方面找不到對應功能的開源軟件的情況。
孫立：對於大型系統的突發性故障，如何在架構層面幫助快速定位故障的原因？
孫朝暉：互聯網應用系統由於涉及多服務集成，以致多數的異步調用造成突發性故障很難排查，針對這個問題我們主要採取以下幾點策略。
- • 每次出現故障時進行分析，準確定位故障的源頭邏輯節點與物理節點，統計後作爲知識庫，標識出每個系統中的脆弱節點，出現故障後，優先挑選脆弱節點排查。
- • 在架構進行Review時，儘量保持每個業務流程保證不超過3個物理節點的請求跳轉，儘量減少物理層次深度。還有保證在一次調用流程中，級聯的異 步調用至少2次以下。在所有發出連續同步調用的初始節點上負責統一trace，方便故障排查。在物理架構圖中標出這些調用流程中的關鍵節點，出現問題優先 從關鍵節點開始排查。
- • 在物理架構上，儘量明確服務器的角色，在某個角色服務器上部署同類型的服務。對於Java中間件服務器由於服務數目較多，儘量採用虛擬機技術拆分。單獨服務器承載獨立服務，比較容易定義監控策略併發出預警。
- • 每次故障後Review告警與故障的關係，對沒有及時告警的部分增加告警監控，告警不準確的部分及時修正，增強監控和告警的準確性。
- • 在我們的技術體系內開發了針對分佈式應用系統的部署和監控系統，應用服務器會集中的監控服務器彙總系統日誌，統一與預警和告警系統集成。
主持人介紹：馮大輝，現任丁香園 （http://www.dxy.cn）網站CTO。曾歷任支付寶架構師、數據庫團隊負責人等職。
提問嘉賓介紹：孫立，去哪兒網高級系統架構師，曾就職於鳳凰網、酷6和搜狐。對分佈式搜索引擎開發、大數據量網站系統架構優化、運維監控等有豐富的經驗。開源項目phplock和phpbuffer的作者，近期開發了NoSQL數據庫存儲INetDB。
回答嘉賓介紹：孫朝暉，飛信互聯網產品首席架構師。負責飛信SNS業務相關產品，空間、開放平臺的總體架構設計與飛信
開發團隊技術社區建設。2010年加入北京新媒傳信科技有限公司。曾歷任微軟（中國）高級顧問、高級項目經理。
（本文選自《程序員》雜誌11年05期，更多精彩內容敬請關注05期雜誌）