[轉]專訪企業QQ SaaS團隊，談企業級LNMP架構設計

FROM : http://www.csdn.net/article/2014-08-20/2821302-interview-tencent-b-qq-shuai-wang

對比IaaS和PaaS，SaaS獲得的關注顯然要少一些。究其根本，不只由於SaaS關注的是功能方面的探索，更偏向於某個領域或層面的實際應用，還歸結於相較前二者，軟件的雲化已基本趨於成熟，些許突破並不能帶來產業上的變革。然而，較少的關注並不意味着缺少明星產品：放眼國外，企業級SaaS服務已成爲許多公司的一項重要收益來源，好比Salesforce、Oracle；而聚焦國內，一樣有不少值得咱們關注的產品，就好比本次咱們關注的焦點——騰訊企業QQ。這裏，咱們接觸到了企業QQ的Web技術團隊，與他們團隊的王帥、甘德建、趙凱、陳勝強、唐朝等幾位核心人員進行了深刻溝通，瞭解了基於LNMP，超過4萬付費企業辦公平臺的架構及優化經驗。由王帥表明團隊回答。

企業QQ平臺情況

 

 騰訊企業QQ SaaS團隊

 

CSDN：請首先介紹一下你我的、團隊，及貴團隊從事的工做和關注的重點。 

王帥：在騰訊工做近5年，一直負責企業產品的Web架構。做爲SNG乃至整個騰訊使用PHP最普遍的團隊之一，咱們爲企業內部、企業之間提供了高效的通訊。企業QQ依託QQ的帳號、通訊體系，具有內部組織架構管理、對內溝通、無縫與8.6億活躍QQ用戶溝通（文字/表情/音視頻/遠程協助等）、對外形象統1、開放API等能力。在平時辦公中，企業QQ的Rich溝通形式更是座機電話、手機的很好補充。試想在電話中解釋好久的問題，可能在企業QQ上一個截屏就能夠解決。咱們關注企業的信息溝通及管理，幫助企業掌握運營狀況，咱們堅信能幫助企業實現其目標與價值。咱們的口號是隨時隨地，隨心辦公。

CSDN：可否談一下騰訊企業QQ當下的用戶規模？都包括了哪些重量級客戶？以及這套平臺在騰訊內部的使用狀況？ 

王帥：通過幾年的積累，企業QQ擁有4W家的付費企業，超過100W的用戶數，在整個企業級SaaS市場屬於領先的地位。咱們設計定位是對座機電話、手機的補充，企業QQ提供的SaaS通訊服務，適合全部開通寬帶的企業和幾乎全部行業。咱們的客戶行業分佈十分普遍，除了快遞物流領域的每天快遞、圓通，餐飲領域的西貝，同時還包括政府機關、教育單位（好比，上海交通大學）、跨國企業（好比，IT巨頭Intel）等。

騰訊SNG的即通綜合部平時用企業QQ進行溝通辦公，可是因爲全公司範圍代替RTX的實施成本比較高，因此在騰訊內部只推廣到了企業產品部門，不過隨着產品影響力的日益加強，咱們相信企業QQ必然有機會在全公司範圍推廣。

CSDN：就騰訊企業QQ這個SaaS來講，客戶的擔憂都在什麼地方？有什麼問題是你們共同關注的？貴團隊使用什麼方法攻克了這些難關？

王帥：在使用任何一家的SaaS時，企業CIO/IT經理最擔憂的就是這套系統的穩定性和安全性。咱們從多個維度，保證系統穩定性：

 

• 服務器方面，咱們採用騰訊自建機房，在保證不間斷供電的同時，還具有火災/洪水預警、硬件/軟件雙重防火牆防禦、百G級DDoS攻擊防禦等能力；除此以外，咱們還配備了7*24小時響應的安全管理團隊。系統安全方面，採起了分佈式數據採樣與集中告警機制，不間斷的滲透性測試，提早發現系統潛在問題。
• 數據安全方面，咱們使用了異地備份機制以保證數據的完整。
• 服務穩定方面，除了優秀的負載均衡技術，咱們還使用了N+1的冗餘機制以保證系統的平穩運行。
• 軟件安全方面，咱們更採起了多個措施：客戶端防注入、登陸加密等方式自保護，消息傳輸過程採用私有加密協議，客戶端與服務端相互不信任的通訊設計保證傳輸安全，即便在網關上監聽也沒法破解。良好的代碼review機制保證核心代碼的穩定性，快速下發patch能力保證一旦問題發生能快速修復。

 

在SaaS的安全方面，咱們與Intel共同打造了一套基於SaaS服務，由廠商本身或第三方提供加密方式的解決方案，並已爲之申請專利。保證了客戶採用本身但願的加密方式，在企業QQ的安全通道中傳輸。

CSDN：能否談下QQ企業平臺系統的規模/狀態，好比RPS，QPS，TPS等？峯值又會有多少？使用什麼樣的硬件資源支撐了這個平臺？

王帥：做爲一款企業級產品，用戶量不能和我的產品相比，好比QQ空間。騰訊大部分業務是免費+增值方式，大部分服務器只有不到10%承載的是付費用戶。企業QQ的服務器規模較小，但幾乎100%承載的都是付費用戶。目前的RPS在3000左右，峯值能夠達到4000至5000，整個團隊所維護的服務器大概是幾十臺。

 

幾十臺已是算了所有支持系統，主邏輯服務器較少。咱們會不斷壓榨現有服務器性能，從最開始開發企業QQ到如今，基本沒有新增過服務器。咱們會有階段性的作架構優化，服務器負載一直保持較低水平。後面會介紹一些優化的方法。

 

走進騰訊企業QQ

CSDN：能不能詳細介紹一下這個平臺架構的構建過程？都使用了一些什麼技術，分別作了什麼？

王帥：目前的SaaS平臺架構根據產品和量級的需求經歷過屢次演變，最終演化成了如今的結構。

由最初的快慢分離和簡單容災，加強容災和提供灰度發佈能力，逐漸抽取統一數據層/減小無用請求，強化多set模型和立體監控，到最後統一數據存儲。最終演變爲：DNS+GSLB+LVS/TGW+業務邏輯機（Nginx+php-fpm+APC）+中間層和異步系統（PHPServer）+cache層+UDS、Redis、CKV等存儲層。 

LNMP經驗分享

1. 基於PHPServer的中間層：採用PHP做爲UDP/TCP Server提供中間層數據服務，每秒能夠處理請求2萬次以上。中間層封裝大部分緩存和數據邏輯，由於由PHP擴展和純PHP開發，開發人員無需關心內存泄露和core的問題，極大的提升了開發效率。同時咱們實現了CPU親和性綁定，PHP的Epoll支持，消息隊列，Unix Socket等Linux底層特性提升Server的吞吐能力。

2. 基於C++的PHP擴展：部分邏輯用C++封裝成擴展，提升運行效率。公司級業務對接大部分使用C++爲PHP編寫擴展，是PHP與公司級C/C++ API的產品無縫對接。

3. PHPServer旁路系統：使PHP的pctnl，主進程管理和監控全部的業務進程，全部後臺服務器自然支持自動拉起，接入便利，極大提升了後臺服務器的可服務範圍。

4. Xhprof：能夠在運營環境部署的性能調優插件。爲提升QPS，下降服務器CPU，提升機器利用率在業務層級提供了可靠的仰仗。

5. 數據上報和監控：基於PHPServer及公司成熟組件的UDP上報和展現以及RTX、微信通知機制進行全面系統的監控，及時發現服務器異常

6. Cache技術：採用APC進行PHP的OPCode緩存。利用共享內存進行第一層cache，緩存高頻數據，採用業界常見的memcache、redis進行分佈式cache，按照數據單元組合分爲多級cache。採用公司級別的CKV做爲落地Cache方案。 

7. 數據庫技術：採用基於MySQL的數據庫UDS系統託管。部分數據使用騰訊提供的CDB託管，保證寫熱備。

8. Yii框架：利用Yii框架的WebApp和ConsoleApp構建全部的PHP工程。

9. 前端技術：咱們產品很是重視前端體驗。隨着RIA富因特網應用程序類型產品的盛行，咱們在前端技術方面採用了分模塊按需加載（自研的LBF框架）、前端MVC模式的使用（BackBone）、Single Page Application單頁開發模式（SPA）等等。同時在移動端頁面的開發上，藉助html5的各類便利新特性，大大提升了用戶體驗（LBF Mobile）。將來，隨着在多平臺多終端上的發展，在前端方面咱們也會採用響應式佈局等的新理念，來優化多終端之間的智能適配。

10. 前端系統：自建NodeJS+ULS（海量log系統）上報JS的錯誤，使咱們對用戶瀏覽器可能出現錯誤瞭如指掌。前端代碼發佈前對模板文件預編譯（ArtTemplate），同時多個靜態資源文件合併和壓縮（Combo機制），推送到CDN，加速用戶側的加載。使用公司級OZ測速系統，可以瞭解全國的接入速度，針對性的優化服務器拓撲。

CSDN：如此規模下，平臺打造的主要挑戰在什麼地方？貴團隊在這些技術上都作了哪些方面的調優？能達到一個什麼樣的級別？

王帥：做爲一款企業級服務，穩定、安全性是咱們最重要的挑戰。在穩定性方面，咱們堅持進行灰度發佈，在正式發佈前已經通過多輪灰度用戶驗證。服務的多Set隔離，在極端狀況下一個set出問題，其餘set依然可以提供服務。服務器提供各個維度的監控（CPU、內存、流量、磁盤、程序錯誤等等），同時也有各類觸達運維人員的告警（手機、短信、微信、RTX等等），此外，在平行擴展方面也下了不少功夫，服務器負載過大的時候能夠經過增長機器輕鬆擴展。安全性方面，咱們的功能在上線前均接受公司的XSS、CSRF等各類漏洞掃描，而且時刻關注所使用的開源軟件的漏洞發佈狀況，及時防堵。

另外，不少查詢和操做須要以企業爲單位進行操做，在Cache設計上咱們支持了多級的Cache模型。

大部分公司的上班時間是一致的，所以不少請求會在早高峯上班時撞車，咱們也一直致力與削峯和減小高峯期CPU佔用率。

性能調優經驗分享

 

• 全部數據Cache化，多級Cache
• 使用Linux的運維命令查找高峯期耗時較高的CGI和進程，運用Xhprof定位業務性能問題
• 同步網絡請求異步化
• 使用Epoll提到Select提升網絡IO效率，爲使用PHP作後臺server提供基礎架構能力
• 快慢請求業務分離，互不影響。
• 有效的利用Nginx反向代理能力，將部分（如灰度邏輯）作在nginx層以提升處理性能。

 

採用上述調優後，咱們團隊在流量增大2倍的前提下未加一臺機器，CPU保持不變。

前端方面，在大型企業人員規模巨大，依然要展示整個公司組織的狀況下，咱們進行前端json文件本地緩存，對部門和成員數據查找檢索算法方面作了算法優化，可以基於拼音首字母、多音字、ID、中文等進行檢索，該檢索算法已經申請專利。在CGI方面也作了按場景和權限分離，分批拉取，在一個頁面上用戶量達到3萬級別，也能保證用戶體驗和加載速度。

CSDN：做爲web的分佈式架構大師，你認爲重點在什麼地方？架構時應該使用一個什麼樣的理念？架構師應該具有哪些知識？須要避免哪些坑？

王帥：Web架構選型，最重要的一點是選擇最合適的架構，而不是最好的。咱們設計架構最根本的理念是：任什麼時候候架構都是爲業務服務的，在選型階段要避免過分設計。任什麼時候候都要符合敏捷迭代的思想，最快速的支持業務開發。在規劃一個分佈式架構系統的時候，能夠從架構的可用性、可靠性、高性能、可管理性、可伸縮性、成本等方面重點關注，這幾個方面環環相扣缺一不可，一個成熟架構師會靈活運用各類計算機基礎知識，在上述幾個方面進行妥協。

架構儘可能不要設計得過於複雜化，越簡單的模型對於從此的維護成本越有利；同時也沒必要過分設計，知足現有需求同時爲未來擴展預留適當的空間便可，由於產品方向、業務需求的變化可能改變甚至推翻現有的架構，過分設計將形成資源的沒必要要浪費。在設計一個分佈式架構的時候，要對網絡、服務器、IDC、帶寬、均衡設施、系統容量等等方面都要有較爲深刻的認識，這些都是較爲基礎的準備，同時，也要對公司內、外相關的成熟組件有所瞭解，好比外界開源LVS能夠很好的實現負載均衡，自研的TGW/L5/CMLB等系統也能夠實現相似需求，能夠避免重複造輪子，享受開源技術紅利，集中資源去快速知足業務需求。至於如何避免哪些坑，這個就多到沒法窮舉了。服務壓力上漲屬於幸福的煩惱，服務器沒故障過幾回，不少經驗也積累不起來。。

除了自身要具有上述提到的各類前提下，還要多多關注業界主流設計方案，同時將方案請同行指點指點不失爲一個很好的方法。推薦一本書《軟件架構師應該知道的97件事》，每隔一段時間的從新閱讀都會有新的收穫。

CSDN：LNMP是個很是普及的web架構，可是不多能將他們用到大家的規模，是否能夠給你們分享一些大流量開發過程當中總結的一些祕訣，以及一些須要特殊注意的地方。

王帥：LNMP做爲最爲普及的web架構之一，在當今互聯網架構方案中起舉足輕重做用。在上述所提到作好架構設計的前提下，在應對大流量時，數據緩存機制重要性顯得尤其重要，舉例子來講，業務代碼中獲取數據源的時候，要充分考慮對數據源的訪問保護，同時也要防止因緩存失效或者預熱過程當中大流量直接穿透致使數據源被壓垮，尤爲是數據庫；代碼層面上，抽象出一些公共類庫，爲前端業務、中間層等系統服務。

另外Nginx能夠作不少事情，包括但不限於染色、錯誤處理、反向代理、容災等。

而PHP自己做爲使用C語言開發的腳本語言，在純後臺Server（WebServer）的實現上有極高的開發效率，且效率不會比純C的Server低太多，在互聯網快速變化中，可以快速的幫助產品進行試錯。

CSDN：在容災和資源調度上，這個平臺能達到什麼樣的水準？能否詳細談談，好比各個層面的副本數量，可用性能夠達到幾個9？

王帥：咱們在容災和負載均衡上都作了較大努力，從最靠近用戶的LVS/TGW接入層開始，到Nginx反向代理層，再到業務邏輯層，最後到中間層、Cache層、數據源等各層系統，每層均可以自容災，同時向下負載均衡，服務器是跨機房熱備，即便一個機房故障，也能夠給用戶提供穩定服務。同時，任何一臺機器主要性能指標達到波動閾值，咱們的全體開發成員均會及時收到微信、短信、RTX等全方位的告警，及時採起應對措施，能夠保守的說，咱們的整體系統可用性達到5個9以上。

CSDN：在企業級產品SaaS的打造上，你有什麼能夠補充給你們的？好比說如何才能得到一個更好的用戶體驗？

王帥：在企業產品SaaS的打造上，咱們團隊多年來在產品體驗上積累了至關豐富的經驗。首先，咱們的部分產品需求基本都來自用戶真實的訴求，也就是咱們產品始終秉持着爲企業用戶解決企業痛點而觸發的。其次，一個產品需求被承認須要開發前，首先產品方案會通過產品同窗內部的溝通，而後會拿到整個項目組一塊兒討論需求的可行性、合理性等，這樣在開發之出就能夠暴露出產品設計的種種缺陷，減小後期產品方案反覆變動帶來的資源浪費。再後來，產品開發、測試完畢後，咱們會先根據調查給但願嚐鮮的用戶灰度試用，在灰度的這段時間內（通常爲1~2周），積極收集用戶的反饋意見、建議，產品組同窗、項目經理全程參與其中，決策是否要調整產品。固然灰度期間，咱們整個產品中心也是灰度用戶，你們能夠就新產品暢所欲言本身的觀點。最終，產品通過道道工序後終於推向全體企業，這個時候推出的版本因爲已經通過部分用戶持續試用、反饋、修正，不管從穩定性仍是交互體驗上都通過真實用戶的驗證，更加容易獲得廣大用戶的承認。