摘要：作者结合自身工作经历，以一个项目为案例，通过多个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生态系统之外的更简单、更强大的替代解决方案。
