奇虎360 和 go

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

在中國，奇虎 360 是一個互連網和手機安全產品及服務的主要供應商，截止到 2014 年 6 月，奇虎擁有 5 億的 PC 活躍使用者以及超過 6.4 億移動使用者。奇虎還運營著中國最受歡迎的網路瀏覽器和 PC 搜尋引擎。 我的團隊，推動服務團隊，為超過 50 個公司的產品提供服務（PC 和移動），包括成千上萬放在我們的開放平台的應用程式。

蕭邦也沒譜 翻譯於 5天前 0人頂 頂 翻譯的不錯哦!

我們對Go的青睞要從2012年第一次嘗試為奇虎的一個產品提供推送功能開始。最初的nginx + lua + redis方案因為負載過大沒能滿足我們對即時效能的需求。在這種情況下，最新發行的1.0.3版Go引起了我們的注意，藉助它提供的goroutine和channel特性，我們在幾周之內開發完成了一個原型。我們的系統最初運行在20台伺服器上，能夠處理2000萬即時串連，每天發送200萬資訊。現在這套系統在超過400台伺服器運行，支援2億即時串連，每天發送超過100億條資訊。

zypy333 翻譯於 3天前 0人頂 頂 翻譯的不錯哦!

隨著商業上的快速擴張以及對我們推送服務的需求的增長，最初的Go系統很快遇到了瓶頸：堆大小達到69G、GC停頓最高能到3-6秒。更頭疼的是，我們必須每周重啟系統來釋放記憶體。實話實話，我們考慮過放棄Go，用C來重寫全部的核心組件作為替代。然而，並未如我們所願，我們在遷移商務邏輯層的代碼時遇到了麻煩。結果就是，作為當時唯一的人員，我不可能在維護這個Go系統的時候確保商務邏輯順利遷移到C的服務架構上。 因此，我決定繼續留在Go系統上(可能是我最機智的一次無奈選擇)，並且很快就取得了重大進展。

尹綿綿 翻譯於 3天前 0人頂 頂 翻譯的不錯哦!

下面是幾個要點和我們總結的小技巧： 用長串連(使用串連池)替代短串連，減少通訊過程中緩衝區和對象的建立。 適當的使用對象池和記憶體池，減少GC的負載。 使用任務池，原理是由一組協程作為消費者輪詢並執行全域的任務或者來自訊息佇列的任務——由持有串連的協程作為生產者發送任務，用這種模式取代為每個任務產生一個臨時協程。 監視並控製程序中協程的數量。缺乏控制會使GC不堪重負，比如，因為不加控制的接受外部請求而出現的協程數峰值施加在GC上，同時發往內部服務的RPC調用可能阻塞新建立的協程。 在移動網路中，要記得給串連[設定讀寫逾時限制](http://golang.org/pkg/net/#Conn)，否則可能導致協程阻塞。在區域網路中就要謹慎使用此設定，否則會降低RPC通訊的效率。 使用Pipeline(在TCP全雙工系統特徵下)來增強RPC架構的通訊效率。

尹綿綿 翻譯於 3天前 0人頂 頂 翻譯的不錯哦!

最後，我們成功的對架構進行了三次迭代，其中有兩次對 RPC 架構的迭代還是在人手有限的情況下完成的。這都得益於 Go 開發的便利性，下面是我們當前的系統架構： 持續最佳化的過程可以通過下表來說明： 還有，在這些最佳化之後，再也不需要臨時的釋放記憶體或者重啟系統了。

尹綿綿 翻譯於 2天前 0人頂 頂 翻譯的不錯哦!

更令人興奮的時我們已經開發了一個線上即時反映 Go 程式運行概況的可視化平台。現在我們很輕鬆的就可以拿到系統狀態並做出診斷，消除隱患。這是系統運行中的： 這個平台還可以做一件很棒的事情——類比數百萬使用者線上的串連和操作。通過使用這個分布式的壓力測試工具（也是用 Go 實現），並觀察所有這些直觀的即時資料。我們評估每一次最佳化的效果並且定位系統瓶頸然後排除問題。

尹綿綿 翻譯於 2天前 0人頂 頂 翻譯的不錯哦!

到目前為止，我們幾乎試遍了所有系統最佳化的手段。我們還是期盼 GC 團隊能帶來更多的好訊息讓我們進一步的從繁重的開發工作中解脫出來。想來，也許有一天我們的這些經驗會因為 Go 的持續發展而變得無用武之地。 這也是為什麼我要以表達獲得了這次出席 Gopher China 的機會的謝意來結束此次分享的原因。這是一個我們去學習，去分享的盛會，也是一個展現 Go 在中國的普及和繁榮的契機。在奇虎內部有許多其他的團隊開始去瞭解 Go，或者已經在試著使用 Go。 在可預見的將來，我相信中國會有更多的互連網公司加入我們的行列，用 Go 來重新建立他們的系統，而 Go Team Dev的成果會使更多的開發人員和公司收益。

尹綿綿 翻譯於 2天前 0人頂 頂 翻譯的不錯哦!

本文中的所有譯文僅用於學習和交流目的，轉載請務必註明文章譯者、出處、和本文連結
我們的翻譯工作遵照 CC 協議，如果我們的工作有侵犯到您的權益，請及時聯絡我們