SDCC 2015架構專場札記：一線互聯網公司的架構實踐

發表于8小時前| 835次閱讀| 來源CSDN| 1 條評論| 作者么剛

SDCC架構數據庫互聯網性能優化架構師 width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-12-03%2F2826378&type=3&count=&appkey=&title=11%E6%9C%8821%E6%97%A5%EF%BC%8C%E4%B8%BA%E6%9C%9F%E4%B8%89%E5%A4%A9%E7%9A%84SDCC2015%E4%B8%AD%E5%9B%BD%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91%E8%80%85%E5%A4%A7%E4%BC%9A%E6%88%90%E5%8A%9F%E9%97%AD%E5%B9%95%EF%BC%8C%E6%88%91%E4%BB%AC%E7%89%B9%E9%82%80%E8%AF%B7%E4%BA%86%E4%B8%9A%E5%86%85%E4%B8%93%E5%AE%B6%E3%80%81%E4%B8%8E%E4%BC%9A%E8%80%85%E5%88%86%E4%BA%AB%E4%BB%96%E4%BB%AC%E7%9A%84%E5%90%AC%E8%AF%BE%E6%84%9F%E5%8F%97%E5%8F%8A%E4%BB%96%E4%BB%AC%E7%9C%BC%E4%B8%AD%E7%9A%84%E6%9E%B6%E6%9E%84%E4%B8%93%E5%9C%BA%E3%80%82%E6%9C%AC%E6%96%87%E6%98%AF%E6%9D%A5%E8%87%AA%E6%90%9C%E7%8B%97%E5%95%86%E4%B8%9A%E5%B9%B3%E5%8F%B0%E6%9E%B6%E6%9E%84%E5%B8%88%E5%8F%82%E5%8A%A0%E7%AE%97%E6%B3%95%E4%B8%93%E5%9C%BA%E7%9A%84%E5%90%AC%E8%AF%BE%E6%9C%AD%E8%AE%B0%EF%BC%8C%E4%BB%A5%E9%A3%A8%E8%AF%BB%E8%80%85%E3%80%82&pic=&ralateUid=&language=zh_cn&rnd=1449146485886" frameborder="0" scrolling="no" allowtransparency="true">摘要：11月21日，為期三天的SDCC2015中國軟件開發者大會成功閉幕，我們特邀請了業內專家、與會者分享他們的聽課感受及他們眼中的架構專場。本文是來自搜狗商業平臺架構師參加算法專場的聽課札記，以饗讀者。

【編者按】11月21日，為期三天的SDCC2015中國軟件開發者大會成功閉幕，主辦方總計邀請了95余位演講嘉賓，為參會者奉獻了10個主題演講，9大技術專場論壇（80余場技術演講），另外還有5場特色活動。另外，據官方統計參會人數高達1067名（不含工作人員）。

其中20日的架構專場，現場聽講人數一度爆滿，而沒有機會親臨現場的童鞋們，我們特邀請了業內專家、與會者分享他們的聽課感受及他們眼中的架構專場。以下是來自搜狗商業平臺架構師么剛參加架構專場的聽課札記，以饗讀者。

另外，我們在架構專場舉辦的當天也做了直播，大家也不妨看一下我們的視角：

• 架構實踐論壇（上）：航天信息、搜狗、餓了么平臺架構演化與轉型
• 架構實踐論壇（下）：小米網、途牛、快的、58同城、QQ的架構變遷與優化
  

以下為么剛的參會筆記：

航天信息股份有限公司高級架構師范剛：在互聯網+的時代,該如何應對系統變革

來自航天信息股份有限公司的范剛分享了在多年實踐中對于系統改造重構的總結與思考。在互聯網+的背景之下，很多架構師們面對的是層出不窮的需求、不斷更新迭代的新技術以及滿身補丁，讓開發運維無比頭大的老舊系統。是繼續縫縫補補還是推倒重來？何去何從，范剛給出了漸進式改造、優化與維護并行，平臺與重構并重的答案。很多老舊系統都面臨著體系老舊，業務繁雜，代碼耦合度高的問題，所謂的漸進式改造，就是在保持系統功能不變的情況下，將業務領域層和技術支撐平臺解耦，并實現業務領域層的模塊化，最終”像更換零件一樣更新系統”。在實際的生產環境中，在進行系統改造的同時，必須滿足新的業務需求，對于這個問題范剛給出的經驗總結是優化與維護并行：由改造組進行系統優化，維護組滿足業務需求，系統優化跟隨業務版本上線，快速迭代小步快跑，便于系統優化階段性效果的驗證，也可以有效避免大版本切換的系統性風險。而平臺與重構并重是技術支撐平臺和業務領域層的優化同時展開，平臺組完成技術架構的調研選型、基礎平臺、公共組件的設計和開發；業務組根據業務邏輯進行模塊劃分，結合業務需求制定項目計劃，完成漸進式重構改造。最后結合項目實例，總結得到軟件重構的七步曲（圖1）。

圖1?軟件重構七步曲

搜狗商業平臺架構師劉建：搜狗商業平臺基礎架構演化實踐

劉建以搜狗商業平臺基礎架構為例，向我們完整的展示了一個系統從ALL-IN-ONE的初始階段一步步演化成為一個高性能、高可用、高可擴展的成熟系統。搜狗商業平臺的架構演化分為初始階段、水平化、服務化和流式計算4個階段（圖2）。

• 初始階段，業務優先，快速迭代，但隨著業務規模的迅速擴張，數據庫健康度低，訪問超時等問題日益凸顯。
• 在水平化階段，通過計算水平化和存儲水平化，成功解決了系統性能和存儲問題，計算水平化的難點在于狀態的處理，理想的設計是獨立存儲中間狀態，實現計算節點的無狀態化；而在進行存儲水平化設計時，則需要更多的關注數據源的遷移成本，搜狗商業平臺是通過自研的數據庫分庫分表框架Compass實現平滑遷移。
• 在服務化階段，通過優化解耦實現資源私有化，服務接口化和模塊獨立化，有效降低了團隊之間的溝通協作成本。搜狗商業平臺的服務化基礎框架Polaris，是在Thrift基礎之上增加了認證，授權，監控，失效重連和負載均衡等機制自研形成。
• 為了更好的服務客戶，引入了kafka?+?storm?+?pump?+?Binlog?Tunnel的流式計算框架，流式系統在設計選型時需要充分考慮消息順序性，消息重復和消息丟失問題，必要時可以進行雙路比對，降低系統風險。

最后值得一提的是，搜狗商業平臺最近開源了嵌入式數據庫分庫分表框架Compass，遵循標準的DataSource接口，支持分庫分表、讀寫分離和負載均衡，可屏蔽底層數據源差異，支持方便的數據源遷移和擴容縮容，并能夠進行有效的數據源健康度監控。

圖2搜狗商業平臺基礎架構演化

餓了么創新產品研發部副總監程軍:?餓了么整體架構

餓了么技術體系是典型的業務驅動，業務量的爆發式增長推動整體架構不斷向前演化。餓了么經歷了單機時代、集群時代、SOA時代（圖3）的演進過程。為解決性能問題，核心gateway使用F5代替了HAProxy。在SOA過程中，對于核心服務采用數據庫按領域拆分、熱數據緩存、異步消息通知和服務降級的策略，有效的應對流量洪峰。在數據庫方面，餓了么自研了數據中間件DAL，實現了MySQL的連接池、分庫分表、讀寫分離、查詢拒絕等功能。引入Service?Orchestrator實現前后端分離，提高系統并發度、縮短響應時間。另外餓了么的核心服務是基于Python?構建，也為我們提供了一個用python架構支持高并發互聯網服務的一個范例。

圖3餓了么整體架構

小米科技的架構師張濤：小米網架構變遷實踐

來自小米科技的張濤，分享了小米網的架構變遷以及架構選型的一些思考。為應對業務的迅猛增長，小米網對系統架構做了如下的演進優化：對DB按系統拆分，做到水平可擴展；系統調用關系由網狀結構優化為星狀結構，引入MQ，實現系統解耦；縱向來看，把系統劃分為調度層、業務層、數據層三層結構，功能明確，接口清晰；引入Cobar解決浪涌導致的高壓。如何在架構設計層面提高效率，降低成本，小米網的做法是抽象基礎服務和基礎組建，節約開發成本，提升服務質量；按照“業務縱切，平臺橫切”的方案，實現業務的模塊化和基礎服務的平臺化。另外張濤還介紹了小米網的特色技術，包括流量控制架構、通用緩存框架MCC、異步消息推送服務Notify、庫存設計和智能調撥算法、虛擬化和云服務、監控和異常、安全策略、SOA等。其中MCC采用的是Twemproxy+redis成熟緩存方案，并考慮了數據熱加載，業務隔離，多機房災備等問題而形成的通用緩存框架；告警量爆炸也是大中型互聯網公司的常見問題，對此小米給出的建議是：區分異常和告警，只有滿足一定頻度或數量的異常才能升級為告警，而所有告警必須處理；小米網的SOA框架如下圖4?所示，框架選型是基于Thrift實現RPC核心功能，基于etcd完成服務注冊、服務發現、failover、框架支持多語言環境，研發可以用很小的成本快速搭建RPC服務。

圖4小米SOA框架

途牛旅游網研發總監高健：途牛網站無線架構變遷

途牛旅游網的高健從服務化的推進、多機房異地部署、性能優化和APP客戶端技術4個方面介紹了途牛無線架構的演進。在服務化方面，通過引入MQ實現服務的異步化，通過數據庫的分庫分表實現高性能的并發計算，通過引入NoSQL、MySQL異構同步機制，Unix域通信機制實現分布式計算（圖5），并通過注冊中心和監控中心實現整個系統的高可用性和高可維護性。多機房異地部署面臨的問題是專線不穩定和數據同步延遲過大，因此對于對實時性要求較高的數據可以采用應用層雙寫的方案。在性能優化部分，途牛采用Codis進行熱數據緩存，并且自研了緩存更新系統BWT和監控系統OSS，保障Codis的易用性和平穩運行。而在APP技術方面，采用插件式開發框架，模塊之間相互獨立，降低耦合度；使用靜態化資源，提升響應速度；引入alibaba的AndFix框架，實現熱修復。

圖5途牛分布式計算架構

快的打車架構師王小雪：快的打車架構實踐

快的架構師王小雪完整的回顧了快的打車架構演化過程，從最開始的功能基本可用，到核心鏈路優化，再到體系化架構設計。在核心鏈路優化階段面臨的主要問題是LBS查詢性能瓶頸和長連接服務不穩定，直接影響到快的核心業務，問題的原因更多地涉及實現層面的細節：比如MongoDB早期版本全庫鎖的問題，頻繁內存拷貝的問題，超時管理算法效率的問題，考驗著架構師問題快速定位的能力。而在體系化架構設計階段則是更為全局和宏觀的設計和優化，包括：系統分布式改造、無線開發平臺、日志收集檢索系統、實時計算與監控和數據層改造等。其中系統分布式改造的技術選型是dubbo+RocketMQ，實現服務之間的接口化和異步化；日志收集和檢索系統主要功能是實現問題的快速定位，技術選型是log4j?+?flume?+?elasticsearch的組合，單個請求的鏈式調用關系通過flag進行串聯，實現分布式系統的問題追蹤和定位；快的的實時計算系統目標是提供實時準確的運營數據，技術選型是較為通用的RocketMQ+storm+HBase，RocketMQ為storm和HBase提供流量平滑功能，HBase在使用時根據業務場景避免update操作，提升性能；在數據源改造（圖6）的基本思路是用HBase查詢代替Mysql的SQL查詢，其中最核心的技術點是Mock?Mysql?Slave，從mysql?master得到binlog數據通過MQ同步到HBase、HDFS等異構存儲介質之上，另外HBase的二級索引也是一個社區比較熱門的話題，快的的方法是在客戶端插入二級索引，相比Coprocessor的方案可更好的兼容HBase批量插入操作。

圖6?統一數據同步方案

58同城系統架構師孫玄：58同城高性能移動Push推送平臺架構演進之路

孫玄介紹了58移動Push從單平臺、多平臺，再到高性能平臺的演進過程。58最先提供的是iOS的Push服務，iOS不允許service后臺常駐，因此APSN幾乎是IOS Push的唯一選擇，單平臺階段，58搭建了iOS?Provider平臺和APSN對接，提供了證書驗證、連接池、錯誤處理等功能。隨著移動流量的爆發，多終端，多APPs，多策略的業務需求，推動Push進入多平臺階段。關于Android推送，58采用的是自研Android?Provider和第三方Push平臺對接的方案；采用抽象公共邏輯，統一封裝接口的方式解決需求多樣化，邏輯復雜化的問題，提升開發效率。高性能階段則重點解決的是Push性能和穩定性的問題，在性能優化方面，搭建IOS/Android統一的push平臺（圖7），并通過Push的并行化，異步化提升整體性能；關于穩定性的討論主要是集中在Android終端，根據不同機型選擇不同的Push通道，也可以根據策略選擇失敗重試機制。

圖7?58同城移動Push架構

騰訊高級工程師徐漢彬：QQ會員活動運營平臺的架構設計演變

來自騰訊的徐漢彬以會員活動為背景介紹了AMS的架構演變。QQ活動運營的特點是活動多、周期短、個性化強而且過期作廢。人力成本極為有限和層出不窮的業務需求是需要解決的主要矛盾，這里徐漢彬給出答案是構建高效的運營開發模式，整個系統架構從上至下分為前端層、CGI層和服務層，前端層提供基礎組件，CGI實現業務邏輯，服務層提供平臺支撐，通過活動配置文件實現前端邏輯和后端服務的自由組合（圖8），使產品運營同學可以獨立完成活動發布。除此之外，系統的性能、可用性和安全性也是架構師需要考慮的問題。性能優化方面，AMS引入NoSQL優化增查改刪的性能；并采用了帶版本號的CAS樂觀鎖機制提升高頻操作的并發度，從而支撐了5w+/s的秒殺活動。對于可用性從架構設計和多維度運維監控兩個方面來保證，架構設計層面充分考慮了水平擴容、failover、過載保護、服務降級等問題；在運維監控角度，建立多通道，多維度的監控告警機制，確保及時發現響應線上問題。關于安全體系，AMS采用了技術手段、產品設計、安全支撐體系多管騎下的思路，最大程度上保障業務安全。

其實這里有一個可以引申開來的話題——科技公司的工具文化，有種比較激進的觀點是用最優秀的人才來開發工具，提升整個團隊，整個公司的效率，徐漢彬的分享也從一個側面展示了技術工具的強大威力。

圖8騰訊AMS自動化運營體系

總結

聽了上述一線架構大牛的分享，收獲良多，同時也頗有感觸。

全棧架構。從本次架構會場的分享涵蓋了從基礎架構到業務形態，從系統設計到持續交付，從安全、監控到虛擬化技術，從版本迭代到項目投入產出比等諸多領域。本質上，架構師的職責就是充分評估業務，人員，成本等要素在技術層面上保障服務的順利落地，穩定運行并適時推動平滑升級，期間遇到的所有技術的問題都是架構師需要直面的。既是新業務新技術的探路者，又是掃清線上系統瓶頸的急先鋒，架構師的擔子，不輕。

趨同存異。一天的分享中，服務化、分庫分表、異步、分布式、安全、監控等這些高頻詞反復出現，說明架構設計的基本原則和架構師們關注點是趨同的，甚至各自系統架構演化到不同階段遇到的瓶頸和應對的舉措也是驚人的相似。當然也有不同，比如安全，有些場景下關注的業務安全，有些則更關注數據安全；比如數據一致性，有些場景要求強一致性，有些只需關注最終一致性。而其實也正是業務場景的差異給了架構師們展示自己聰明才智的舞臺。

擁抱變化。從分享的主題來看，變化、變遷、演化，主線是一個“變”字。業務量的迅猛增長會倒逼架構的優化和升級，快的和餓了么是典型的例子。而新技術出現也會推動架構的變革，比如服務化可以提升開發效率，降低協作成本；比如流式計算，可以改善用戶體驗甚至是引導用戶需求。無論是業務驅動還是技術驅動，架構師都需要做的就是時刻擁抱變化，成為一個敏銳的觀察者，技術航線的引領者和架構的實踐者。

總結

以上是生活随笔為你收集整理的SDCC 2015架构专场札记：一线互联网公司的架构实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。