740
如何用Go語言每分鍾處理100萬個請求
摘要：作者結合自身工作經曆，以一個項目為案例，通過多個Go語言程序實例的嚐試，闡述了Go語言是如何每分鍾可以處理100萬個請求的，以下是譯文。
我在幾個不同的公司從事反垃圾郵件，反病毒和反惡意軟件工作超過15年，現在我知道這些係統的複雜性可能是由於我們每天處理的大量數據造成的。
目前，我是 smsjunk.com 的CEO和 KnowBe4 的首席架構師，兩個活躍在網絡安全行業的公司。
有趣的是，在過去10年左右的時間裏，作為一名軟件工程師，我所參與的所有web後端開發大部分都是以Ruby on Rails(Rails是使用Ruby語言編寫的網頁程序開發框架，目的是為開發者提供常用組件)開發的。不要誤會我，我熱愛Ruby on Rails,我相信它是一個令人著迷的開發環境，但一段時間後，你開始以Ruby的方式思考和設計係統，忘了如何高效和原本可以利用多線程、並行、快速執行和小的內存消耗來簡化軟件架構。多年來，我是一個C / C++、Delphi和C #開發人員，我剛剛意識到，用合適的工具來完成工作可能會降低事情的複雜度。
我不太熱衷於開發語言和框架的戰爭，網站之間總是為此爭吵。我相信效率、生產率和代碼的可維護性主要取決於如何簡單地構建解決方案。 問題
當我們在一個匿名的遙測和分析係統上工作時，我們的目標是能夠處理來自數百萬終端的大量的POST請求。Web處理程序將接收一個JSON文檔，其中可能包含需要寫入Amazon S3的許多有效負載的集合，這是為了使map-reduce係統稍後操作這個數據。
傳統上，我們將研究創造一個一階作業者架構，利用諸如：
- Sidekiq
- Resque
- DelayedJob
- Elasticbeanstalk Worker Tier
- RabbitMQ
- 等等…
設置2個不同的集群，一個用於web前端，另一個用於作業者，這樣會擴大可以處理的後台工作的數量。
但從一開始，我們的團隊就知道應該這樣做，因為在討論階段，我們預見這可能是一個非常大的流量係統。我使用Go語言大約2年左右的時間，我們開發了一些在用的係統，但是沒有一個係統能得到這麼多的負載。
首先通過創建一些structure，定義通過POST調用來接收到的web請求負載，還有一個上傳請求負載到S3 bucket的函數。
Go語言程序的單純方法
最初我們采取了一個非常單純的POST處理方式，僅僅試圖將任務並行化處理放到一個簡單的goroutine：
對於中等負載來說，這可能對大多數人是有效的，但這很快證明在大型負載時，效果不太好。我們預期有很多的請求，但當我們部署第一個版本到產品中時，並沒有看到這個數量級的請求。我們完全低估了流量。
上麵的方法在幾個方麵都不好，沒有辦法控製我們正在大量生產的Go程序要產生多少個例程。由於我們每分鍾收到100萬個POST請求，理所當然的，這段代碼很快就崩潰了。
再次嚐試
我們需要尋找一個不同的方式。從一開始，我們就討論如何保持請求處理程序的生命周期非常短，並在後台生成處理進程。當然，這是必須在Ruby on Rails領域要做的，否則這將限製所有可用的web處理器，無論你使用的是puma, unicorn, passenger中的哪一個(請不要參加JRuby討論)。那麼我們就需要利用通用的解決方案去做這個，例如Resque, Sidekiq, SQS,等等。清單還可以繼續列下去，因為有很多方法可以做到這一點。
所以第二個版本是創建一個緩存通道，在這裏我們可以對一些作業進行排隊並上傳到S3，由於我們可以控製隊列中的最大項目數，在內存中我們有足夠多的RAM對任務進行排隊，我們認為隻在通道隊列中緩存作業是可以的。
然後實際上的作業出列和處理，我們使用的是類似的函數：
說實話，我不知道我們在想什麼。這一定是一個充滿紅牛的深夜。這種方法沒有給我們帶來任何好處，我們用緩衝隊列來交換有缺陷的並發，也隻是推遲了問題的產生時間而已。我們的同步處理器一次隻上傳一個有效負載到S3,而且由於傳入請求的速率比單處理器上傳到S3的能力大得多，所以緩衝通道很快就達到了極限，限製了請求處理程序來排隊更多項目的能力。
我們隻是簡單地回避這個問題，最終導致係統的死亡。在我們部署了這個有缺陷的版本之後，我們的延遲率以不變的速率持續增長。
更好的解決方案
當使用Go語言通道時，我們決定利用通用模式以便創造一個2階的通道係統，一個用於作業排隊，另外一個控製多少作業者同時在JobQueue上操作。
這個想法是以某種可持續的速度並行上傳到S3，它既不會削弱機器性能，也不會從S3開始生成連接錯誤。所以我們選擇了創建一個作業/作業者模式。對那些熟悉java,C#等語言的人來說，可以考慮采用Go語言實現通道方式而不是作業者線程池的方式。
我們修改了Web請求處理程序，創建一個帶負載的jobstruct實例，發送到JobQueue通道，便於作業者去拾取。
在網站服務器初始化過程中，我們創建一個Dispatcher，調用Run()去創建一個作業者池，開始偵聽出現在JobQueue的作業。
- dispatcher := NewDispatcher(MaxWorker)
- dispatcher.Run()
下麵是用於dispatcher執行的代碼：
注意，我們會提供被實例化和被添加到作業者池的最大的作業者量。 因為我們這個帶有dockerized Go環境的項目使用了亞馬遜Elasticbeanstalk，我們總是設法遵循12要素方法論來配置生產中的係統，從環境變量中讀取這些數值。這樣就可以控製有多少作業者和作業隊列的最大值，因此，我們可以快速地調整這些值，而不需要重新部署集群。
- var (
- MaxWorker = os.Getenv(“MAX_WORKERS”)
- MaxQueue = os.Getenv(“MAX_QUEUE”)
- )
在部署完它之後，我們立刻發現所有的延遲率都降到了無關緊要的數字，係統處理請求的能力急劇上升。
彈性負載均衡完全預熱幾分鍾後，我們看到ElasticBeanstalk應用服務每分鍾逼近100萬個請求。通常在早晨的幾個小時裏，流量高峰會超過每分鍾100萬個請求。
一旦我們部署了新的代碼，服務器的數量從100台減少到大約20台。
在恰當地配置了集群和自動縮放設置以後，我們能夠把它降低到僅有4x EC2 c4。如果CPU連續5分鍾超過90%，大型實例和彈性自動縮放設置就生成一個新實例。
結論
簡單總是在我的字典裏獲勝。我們可以設計一個複雜係統，它具有多隊列，後台作業者，複雜部署的特點。但是相反我們決定利用Elasticbeanstalk的自動縮放和高效簡單的方式去並發，Go語言很好的提供了這些功能。
並不是每天你僅有四台機器的集群，去處理每分鍾寫入到亞馬遜S3 bucket的100萬個POST請求，這可能比我最新的MacBook Pro功能強大的多。
總有合適的工具適合這項工作。有時，當您的Ruby on Rails係統需要一個非常強大的web處理程序時，可以稍微考慮一下Ruby生態係統之外的更簡單、更強大的替代解決方案。
本文作者：佚名
來源：51CTO
最後更新：2017-11-02 15:05:20