搜狐服務架構優化實踐

內容來源：2017 年 08 月 10 日，搜狐研發中心架構師陳偉在「第二屆APMCon中國應用性能管理大會」進行《搜狐服務架構優化實踐》演講分享。IT 大咖說（微信ID：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2625 | 7分鐘閱讀

嘉賓演講視頻回顧及PPT： t.cn/Rdv9UjA

摘要

搜狐業務橫跨新聞，視頻，社交，移動端，垂直領域等諸多方向，業務模式也很是多樣化。在最近兩年，搜狐的後臺服務體系，運維體系，CDN架構，IDC架構都在快速的優化改進。影響用戶體驗的點都有哪些，如何優化，咱們在這一輪搜狐服務的優化中進行了深刻的思考和實踐。 本次將和你們分享在大型綜合網站的後臺架構優化，微服務體系，用戶端鏈接優化，監控體系建設等方面的經驗和教訓。

接入層優化

接入層優化其實沒有太多的技巧，最核心的要點是離用戶越近越好，這也是咱們作接入層優化的主要思路。

自有節點的流量調度

咱們在全國擁有衆多的IDC機房，這種狀況下最重要的是如何讓用戶訪問離他最近的節點。所以在自有節點的流量調度上咱們作了不少工做，這個過程當中最難的實際上是發現用戶的真實位置，傳統的作法是經過DNS體系實現總體調度，可是運營商的DNS或者說用戶的DNS並不必定能反應真實的網絡狀況。爲了更精準的調度，咱們開始使用相似EDNS這樣的協議，而且升級自身的DNS系統，採用更精準的IP庫。

第三方CDN調度

搜狐在過去的十幾年裏一直都是採用本身的IDC方案，可是最近幾年公有CDN也發展的很是快，在一些特定領域有很大的優點。因此咱們使用了自建CDN加上第三方CDN的混合方案，這其中面臨的核心問題仍是調度，隨着CDN的增長調度會愈加麻煩。這種架構下就須要與第三方CDN結合的更緊密，獲取到他們原始節點的位置，以及經過客戶端這樣的特殊方式探查當前網絡環境下效果最好的CDN。

上文的方案依然是基於EDNS，在精準度上仍是不夠。爲此咱們採用了更進一步的方案，即客戶端自主的測試域名對應的每一個CDN的速度，而後結合服務器給的必定策略，綜合主動的選擇最優策略來訪問。這個方案侷限性在於沒法在App之外的環境下得到很好的效果，另外在調度上也變得更加複雜。因此通常這種方案都是用在標準CDN訪問的狀況下，好比核心App有着大量的圖片和視頻。

以上全部策略都依賴於對全網環境和真實數據的瞭解，全部咱們作了一套全網實時品質監控系統，數據源不光來自咱們自身還有一些第三方的檢查機構提供的原始數據。

協議優化

接入層優化除開從流量調度上着手，還能夠介入協議優化。這方面優化效果比較好的就是SPDY和HTTP2，經過咱們的測試發現響應延時下降到了原先的幾分之一。實現這樣的效果還須要作一些準備，主要是頁面要自主的作適應這兩個協議的工做。以前在web環境下域名會被打散，圖片被存儲在各個域名下，這樣的方式在HTTP2中是不推薦的，所以咱們在和業務線協調以後轉而使用HTTPS，而且改進域名分佈方式，得到了不錯效果。

平臺化

搜狐與不少圍繞單一業務展開的公司不一樣，有着衆多的業務線，且業務之間的聯繫也不是很緊密。而技術的快速發展，使得咱們的技術棧不斷的更新，變得愈加複雜。這樣的體系致使業務部門之間相對獨立，沒有全公司的應用運維管理更多的是基礎運維。

平臺化的應用可以有效緩解以上問題，它經過把一些公有的基礎設施抽離出來，以下降業務線的負擔。最近幾年內咱們逐漸將數據庫、Redis集羣、對象存儲、圖片處理等都作成公司內部的私有云形式，提供給業務線使用，這個過程當中咱們還花費了不少精力讓這些組件來適應各類語言開發以及對不一樣模式的兼容。

SCS對象存儲

SCS對象存儲的底層系統是咱們本身搭建的，目前已達到了百億級的存儲量，而且和傳統的KV不一樣，這套系統不只能和多家CDN對接，與圖片處理、視頻處理系統也能完美融合。

Redis集羣

對於大多數業務Redis都是須要用到的緩存，所以咱們針對Redis集羣採用了Docker的資源分配方式而且提供自助化的申請平臺。對比以前採用工單的方式，雲化平臺無需再考慮持久性和可用性問題。

監控報警

監控報警服務有Domeos提供，自動配置通用報警。數據源來着硬件統計信息，業務日誌、負載均衡等，新開發業務幾乎無需配置便可使用。

Docker & 微服務

咱們本身研發了一個Domeos系統，它是基於Kubernetes的開源部署系統，在該平臺下可以比較容易的完成業務上線、回滾、服務配置、跨機房應用以及持續集成等。它的主要做用不只僅體如今線上環境的變化，實際上更多的是規範了整個公司的開發行爲以及歷史遺留問題。從成本上來看資源的複用大大提升，開發成本得以下降。

日誌收集和分析

日誌收集和分析的大體流程如上圖所示。App應用運行在Docker中，控制檯日誌比較容易收集，對於散落文件日誌會要求在上線以前進行配置。這些日誌會經由Flume或Flumentd收集，再交由ELK、Kafka、Storm其中之一處理。

負載均衡與服務發現

Docker之因此不能簡單的應用，不少時候都是由於負載均衡和服務發現不是很好作。因此咱們在這方面作了不少工做。基層代理使用Nginx完成，因爲動態部署的緣由，形成每一個容器的位置隨時都會改變，變動以後的新IP信息會被Nginx獲取到，而全部的外部應用經過Nginx訪問的時候可以自動的進行負載均衡和服務發現。Nginx上還能作日誌分析和監控，好比分析服務響應時間過長的緣由。

反劫持

劫持主要有三個方面的影響，一是無孔不入的廣告帶來的糟糕用戶體驗，二是對於廣告收入的影響，三是服務可控性沒法保障，因爲劫持致使改版升級沒法順利的抵達用戶端。

對此的解決方案有兩個，一是監控，利用全國的布點快速發現問題進行報警；二是投訴和協調，這也是最有用的方案，基本上可以解決大部分問題。而針對小區寬帶的廣告插入問題，更好的解決方式是HTTPS，可是因爲一些兼容性和性能上的侷限沒法大規模的遷移到HTTPS上。