首先給出 原文鏈接.
網(wǎng)上有很多該文章的翻譯版本节猿，但是筆者認(rèn)為機(jī)翻痕跡嚴(yán)重碌冶，并不利于新手閱讀理解
筆者覺(jué)得此文寫(xiě)的通俗易懂沸柔，言簡(jiǎn)意賅毫缆，于是打算翻譯出來(lái)供go服務(wù)器新手學(xué)習(xí)參考痒留，好了廢話不說(shuō)佩憾，開(kāi)始正文

在Malwarebytes的工作讓我經(jīng)歷的驚人的成長(zhǎng)挚币，一年前艾凯，在我加入這家公司之前摘投，我在硅谷的主要工作內(nèi)容就是定制解決方案煮寡，以應(yīng)對(duì)快速增長(zhǎng)的公司每天數(shù)百萬(wàn)的使用頻率。我已經(jīng)在不同的公司從事反病毒和反惡意軟件行業(yè)工作了12年犀呼，我知道這些系統(tǒng)的復(fù)雜程度取主要決于我們每天要處理多大量數(shù)據(jù)幸撕。

有趣的是，在過(guò)去的9年當(dāng)中外臂，我從事的所有網(wǎng)站開(kāi)發(fā)都是在Ruby on Rails的方案下實(shí)施的坐儿。不要誤會(huì)我的意思，我非常熱愛(ài) Ruby on Rails宋光，我認(rèn)為這是一個(gè)令人驚奇的開(kāi)發(fā)方案貌矿。但是在一段時(shí)間以后，當(dāng)你開(kāi)始用Ruby on Rails的思路去思考和設(shè)計(jì)系統(tǒng)罪佳，你就會(huì)忘記那些可以利用的多線程逛漫、并行，快速執(zhí)行和小的內(nèi)存開(kāi)銷的解決方案赘艳，而這些將會(huì)使你開(kāi)發(fā)的軟件高效和簡(jiǎn)潔酌毡。多年來(lái)，我一直是一個(gè)C / C++蕾管、Delphi和C #開(kāi)發(fā)者枷踏，我開(kāi)始意識(shí)到，當(dāng)你使用適合的工具時(shí)掰曾，事情會(huì)是多么的簡(jiǎn)潔旭蠕。

作為一個(gè)架構(gòu)師，我不是很在意那些網(wǎng)站之間的關(guān)于語(yǔ)言和框架之間孰優(yōu)孰劣的紛爭(zhēng)。我相信下梢，效率客蹋，生產(chǎn)力和代碼的可維護(hù)性主要依賴于如何簡(jiǎn)單的構(gòu)建你的解決方案。

一個(gè)難題

當(dāng)我們?cè)谶M(jìn)行一個(gè)匿名的測(cè)試和分析系統(tǒng)時(shí)孽江，我們的目標(biāo)是能夠處理來(lái)自數(shù)百萬(wàn)端點(diǎn)的大量POST請(qǐng)求讶坯。web處理程序?qū)⒔邮找粋€(gè)包含眾多數(shù)據(jù)集合的JSON文檔，它們將被寫(xiě)入Amazon S3數(shù)據(jù)庫(kù)岗屏，以供我們的大數(shù)據(jù)系統(tǒng)進(jìn)行后續(xù)操作

面對(duì)這樣的需求辆琅，通常我們會(huì)考慮諸如：
Sidekiq
Resque
DelayedJob
Elasticbeanstalk Worker Tier
RabbitMQ
等等框架和方案...
并且，我們會(huì)設(shè)置2個(gè)不同的集群这刷，一個(gè)用于Web前端婉烟，另一個(gè)用于后臺(tái)服務(wù)，這樣我們就可以通過(guò)增加減少后臺(tái)服務(wù)器的數(shù)量來(lái)控制我們能夠處理的請(qǐng)求數(shù)暇屋。但是似袁，從一開(kāi)始我們的團(tuán)隊(duì)就決定采用Go語(yǔ)言作為開(kāi)發(fā)方案，因?yàn)榻?jīng)過(guò)討論咐刨，我們發(fā)現(xiàn)這將會(huì)是一個(gè)非常龐大的系統(tǒng)昙衅。我們已經(jīng)從事Go語(yǔ)言開(kāi)發(fā)兩年，在工作中設(shè)計(jì)架構(gòu)了一些系統(tǒng)定鸟，但是還沒(méi)有任何一個(gè)系統(tǒng)有如此龐大的數(shù)據(jù)量而涉。

我們首先創(chuàng)建了一些結(jié)構(gòu)體來(lái)定義POST的request中內(nèi)容，以及一個(gè)上傳到S3庫(kù)的方法联予。

p1.png

小試牛刀

最初我們采取了一個(gè)非常簡(jiǎn)單的POST請(qǐng)求處理實(shí)現(xiàn)方案啼县，嘗試簡(jiǎn)單并發(fā)goroutine去處理任務(wù)

p2.png

對(duì)于中等的負(fù)載量，這個(gè)方案可以滿足大多數(shù)人的需求沸久。但是當(dāng)數(shù)據(jù)量增大的時(shí)候季眷，它開(kāi)始顯得不那么好用了。在第一版投入生產(chǎn)環(huán)節(jié)中麦向，我們預(yù)估了一下request的數(shù)量瘟裸，事實(shí)上我們完全低估了這個(gè)龐大的數(shù)據(jù)量。

上面的方案在有很多弊端诵竭，首先我們無(wú)法控制開(kāi)啟的goroutine數(shù)量话告，然后，當(dāng)請(qǐng)求達(dá)到每分鐘一百萬(wàn)次的數(shù)量級(jí)卵慰，很快這段代碼就崩潰了沙郭。

再次嘗試

我們需要一個(gè)新方案，在一開(kāi)始的討論中裳朋，我們明確了幾點(diǎn)病线，首先要保證request handler 的生命周期足夠短，其次要做到在后臺(tái)進(jìn)行異步并發(fā)處理。顯然如果采用Ruby on Rails的方案送挑，這些都是必要的事情绑莺，不然就會(huì)阻塞整個(gè)網(wǎng)絡(luò)。那么惕耕，我們將不得不采取一些常見(jiàn)的方案來(lái)解決這個(gè)事情比如使用 Resque, Sidekiq, SQS等等纺裁。

所以，第二次迭代的任務(wù)就是創(chuàng)建一個(gè)用于緩存列隊(duì)的通道司澎，用來(lái)緩存請(qǐng)求欺缘，并將它們逐一存入S3服務(wù)器。因?yàn)槲覀兛梢钥刂脐?duì)列通道內(nèi)的最大容量谚殊，并且我們有足夠大的內(nèi)存來(lái)緩存隊(duì)列，我們認(rèn)為這將會(huì)一個(gè)是極好的方案蛤铜。

p3.png

然后嫩絮，為了將任務(wù)列隊(duì)并依次處理，我們用了如下面這樣的代碼

p4.png

老實(shí)的講围肥，我并不知道我們?cè)谙胄┦裁葱跫恰＿@將會(huì)是一個(gè)充滿紅牛的不眠之夜。這個(gè)方案并沒(méi)有給我們帶來(lái)任何改進(jìn)虐先。我們用一個(gè)緩存列隊(duì)代替了有缺陷的并發(fā)方案，這僅僅是推遲了問(wèn)題的產(chǎn)生時(shí)間而已派敷。我們的同步處理器每次只能上傳一分?jǐn)?shù)據(jù)到S3蛹批，而隊(duì)列中傳入請(qǐng)求的速度遠(yuǎn)大于處理器上傳數(shù)據(jù)到S3的數(shù)據(jù)，很快的我們的隊(duì)列就達(dá)到了極限篮愉，從而阻塞了后續(xù)的請(qǐng)求添加到隊(duì)列腐芍。我們僅僅簡(jiǎn)單的去回避問(wèn)題，這僅僅是開(kāi)啟了一個(gè)系統(tǒng)崩潰死亡的倒計(jì)時(shí)试躏。

p5.png

更好的方案

當(dāng)我們使用Go的通道時(shí)猪勇，我們決定利用一個(gè)公共模式來(lái)創(chuàng)建一個(gè)雙層的通道系統(tǒng)。一個(gè)用來(lái)隊(duì)列任務(wù)颠蕴，而另一個(gè)則是控制當(dāng)前處理隊(duì)列任務(wù)的線程數(shù)量泣刹。

這個(gè)想法是要采用一個(gè)合理的可持續(xù)的速率并行的上傳數(shù)據(jù)到S3服務(wù)器，既不會(huì)阻塞服務(wù)器的性能犀被，也不會(huì)從S3服務(wù)器獲取上傳失敗的錯(cuò)誤回調(diào)椅您。因此，我們構(gòu)建一個(gè)job/worker模型寡键，這看起來(lái)有些像Java, C#,等等掀泳，而我們則是考慮通過(guò)Golang的方式，利用通道來(lái)代替它們，去實(shí)現(xiàn)一個(gè)處理器線程池员舵。

p6.png

p7.png

我們已經(jīng)修改了我們的網(wǎng)路請(qǐng)求handler來(lái)創(chuàng)建一個(gè)包含載荷數(shù)據(jù)的任務(wù)實(shí)例脑沿，我們將它發(fā)送到任務(wù)隊(duì)列通道中去，供處理線程們?nèi)ヌ幚怼?/p>

p9.png

當(dāng)我們的網(wǎng)絡(luò)服務(wù)器在初始化的過(guò)程中马僻，我們創(chuàng)建了一個(gè)名叫Run()的調(diào)度器來(lái)創(chuàng)建worker線程池庄拇，并且開(kāi)始監(jiān)聽(tīng)發(fā)送到任務(wù)隊(duì)列中的任務(wù)。

p11.png

下面是我們調(diào)度器的代碼實(shí)現(xiàn)

p12.png

值得注意的是巫玻，我們提供了最大處理線程的并發(fā)數(shù)量丛忆，用來(lái)實(shí)例化任務(wù)處理線程并且將他們添加到我們的任務(wù)處理線程池當(dāng)中。我們使用亞馬遜的Elasticbeanstalk服務(wù)并且采用了docker化的Go 運(yùn)行環(huán)境仍秤，而且我們總是嘗試遵循 12要素的方法論（譯者注：應(yīng)該是一種廣泛認(rèn)可的架構(gòu)設(shè)計(jì)思路熄诡，雖然我沒(méi)聽(tīng)說(shuō)過(guò)）來(lái)配置我們?cè)谏a(chǎn)環(huán)境中的系統(tǒng)，我們通過(guò)環(huán)境變量來(lái)讀取這些值诗力。這樣我們就可以控制處理線程數(shù)量和任務(wù)隊(duì)列通道的所能承載的最大容量凰浮，因此，我們可以快速的改變這些配置而不用重新部署服務(wù)器集群

p15.png

最直觀的結(jié)果

在我們部署完它之后苇本，我們立即發(fā)現(xiàn)所有的延遲率都降到了微不足道的數(shù)量袜茧，我們處理請(qǐng)求的能力激增。

p17.png

在經(jīng)歷了幾分鐘彈性的負(fù)載均衡熱身之后瓣窄，我們看到笛厦，我們的ElasticBeanstalk應(yīng)用每分鐘接近響應(yīng)了一百萬(wàn)的請(qǐng)求。

在我們部署了新代碼之后俺夕，服務(wù)器的數(shù)量大幅下降裳凸，從100臺(tái)服務(wù)器降到20臺(tái)服務(wù)器。

p19.png

結(jié)論

在我的故事中劝贸，極簡(jiǎn)主義總是獲勝的一方姨谷。我們可以設(shè)計(jì)一個(gè)復(fù)雜的系統(tǒng)，具有許多隊(duì)列映九，異步的后臺(tái)處理梦湘，復(fù)雜的調(diào)度，但是我們決定利用Elasticbeanstalk的自動(dòng)縮放的高效的簡(jiǎn)潔的能力去實(shí)現(xiàn)Golang提供給我們的并發(fā)效果件甥。
你并不是每天需要部署一個(gè)4服務(wù)器的集群捌议，來(lái)給亞馬遜的S3服務(wù)器每分鐘寫(xiě)入100萬(wàn)次。
總會(huì)有一個(gè)合適的工具來(lái)解決問(wèn)題嚼蚀，有時(shí)禁灼，當(dāng)你的Ruby Rails系統(tǒng)需要一個(gè)功能強(qiáng)大的Web處理程序時(shí)，可以稍微考慮一下Ruby生態(tài)系統(tǒng)之外的更簡(jiǎn)單轿曙、更強(qiáng)大的替代解決方案弄捕。