搜狐服務架構優化實踐

搜狐在過去的十幾年裡一直都是採用自己的IDC方案，但是最近幾年公有CDN也發展的非常快，在一些特定領域有很大的優勢。所以我們使用了自建CDN加上第三方CDN的混合方案，這其中面臨的核心問題還是排程，隨著CDN的增加排程會越發麻煩。這種架構下就需要與第三方CDN結合的更緊密，獲取到他們原始節點的位置，以及通過客戶端這樣的特殊方式探查當前網路環境下效果最好的CDN。

上文的方案依然是基於EDNS，在精準度上還是不夠。為此我們採用了更進一步的方案，即客戶端自主的測試域名對應的每個CDN的速度，然後結合伺服器給的一定策略，綜合主動的選擇最優策略來訪問。這個方案侷限性在於無法在App以外的環境下獲得很好的效果，另外在排程上也變得更加複雜。所以一般這種方案都是用在標準CDN訪問的情況下，比如核心App有著大量的圖片和視訊。

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

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

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

平臺化的應用能夠有效緩解以上問題，它通過把一些公有的基礎設施抽離出來，以降低業務線的負擔。最近幾年內我們逐漸將資料庫、Redis叢集、物件儲存、圖片處理等都做成公司內部的私有云形式，提供給業務線使用，這個過程中我們還花費了很多精力讓這些元件來適應各種語言開發以及對不同模式的相容。

SCS物件儲存的底層系統是我們自己搭建的，目前已達到了百億級的儲存量，並且和傳統的KV不同，這套系統不僅能和多家CDN對接，與圖片處理、視訊處理系統也能完美融合。

對於大多數業務Redis都是需要用到的快取，因此我們針對Redis叢集採用了Docker的資源分配方式並且提供自助化的申請平臺。對比之前採用工單的方式，雲化平臺無需再考慮永續性和可用性問題。

監控報警服務有Domeos提供，自動配置通用報警。資料來源來著硬體統計資訊，業務日誌、負載均衡等，新開發業務幾乎無需配置即可使用。

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

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

Docker之所以不能簡單的應用，很多時候都是因為負載均衡和服務發現不是很好做。所以我們在這方面做了很多工作。基層代理使用Nginx完成，由於動態部署的原因，造成每個容器的位置隨時都會改變，變更之後的新IP資訊會被Nginx獲取到，而所有的外部應用通過Nginx訪問的時候能夠自動的進行負載均衡和服務發現。Nginx上還能做日誌分析和監控，比如分析服務響應時間過長的原因。

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

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