用Golang处理每分钟百万级请求翻译原文链接 转帖／转载请注明出处 原文链接@medium.com 发表于2017/08/30 我在防垃圾邮件，防病毒和防恶意软件领域已经工作了15年，前后在好几个公司任职。我知道这些系统最后都会因为要处理海量的数据而变得非常复杂。 我现在是smsjunk.com的CEO并且是KnowBe4的首席架构师。这两个公司在网络安全领域都非常活跃。 有趣的是，在过去10年里作为一个码农，所有我经历过的网站后台开发用的几乎都是用
问题在开发我们的匿名遥测和分析系统时，我们的目标是能够处理从上百万个端点发来的大量POST请求。HTTP请求处理函数会收到包含很多载荷（payloads）的JSON文档。这些载荷（payloads）需要被写到Amazon S3上，接着由map-reduce系统来处理。 通常我们会创建一个worker池架构（worker-tier architecture)。利用如下的一些工具： 然后设置两个集群，一个用作处理HTTP请求，另外一个用作workers。这样我们能够根据处理的后台工作量进行扩容。 从一开始我们小组就觉得应该用Go来实现，因为在讨论阶段我们估计这可能会是一个处理非常大流量的系统。我已经使用Go语言两年并用它在工作中开发了一些系统，但它们都没有处理过这么大的负载（load）。 我们首先创建了几个结构来定义HTTP请求的载荷。我们通过POST请求接收这些载荷，然后用一个函数上传到S3 bucket。 简单地使用Goroutines一开始我们用了最简单的方法来实现POST请求的处理函数。我们尝试通过goroutine来并行处理请求。 对于适量的负载，这个方案应该没有问题。但是负载增加以后这个方法就不能很好地工作。当我们把这个版本部署到生产环境中后，我们遇到了比预期大一个数量级的请求量。我们完全低估了流量。 这个方法有些不尽如人意。它无法控制创建goroutine的数量。因为我们每分钟收到了一百万个POST请求，上面的代码很快就奔溃了。 再次尝试我们需要一个不同的解决方案。在一开始，我们就讨论到需要把HTTP请求处理函数写的简洁，然后把处理工作转移到后台。当然，这是你在 第二个版本是创建带缓冲的channel。这样我们可以把工作任务放到队列里然后再上传到S3。因为可以控制队列的长度并且有充足的内存，我们觉得把工作任务缓存在channel队列里应该没有问题。 然后我们需要从队列里提取工作任务并进行处理。代码下图所示： 坦白的说，我不知道我们当时在想什么。这肯定是熬夜喝红牛的结果。这个方法并没有给我们带来任何帮助。队列仅仅是将问题延后了。我们的处理函数（processor）一次仅上传一个载荷（payload），而接收请求的速率比一个处理函数上传S3的能力大太多了，带缓冲的channel很快就到达了它的极限。从而阻塞了HTTP请求处理函数往队列里添加更多的工作任务。 我们仅仅是延缓了问题的触发。系统在倒计时，最后还是崩溃了。在这个有问题的版本被部署之后，系统的延迟以恒定速度在不停地增长。 0_latency.png 更好的解决办法我们决定使用Go channel的常用编程模式。使用一个两级channel系统，一个用来存放任务队列，另一个用来控制处理任务队列的并发量。 这里的想法是根据一个可持续的速率将S3上传并行化。这个速率不会使机器变慢或者导致S3的连接错误。我们选择了一个Job／Worker模式。如果你们对 我们修改了HTTP请求处理函数来创建一个含有载荷（payload）的 在初始化服务的时候，我们创建了一个 下面是我们的dispatcher实现代码： 这里我们提供了创建worker的最大数目作为参数，并把这些worker加入到worker池里。因为我们已经在docker化的Go环境里使用了Amazon的Elasticbeanstalk并且严格按照12-factor方法来配置我们的生产环境，这些参数值可以从环境变量里获得。我们可以方便地控制worker数目和任务队列的长度。我们可以快速地调整这些值而不需要重新部署整个集群。 部署了新版本之后，我们看到系统延迟一下子就降到了可以忽略的量级。同时处理请求的能力也大幅攀升。 1_latency.png 在Elastic Load Balancers热身后几分钟，我们看到Elasticbeanstalk应用开始处理将近每分钟一百万个请求。我们的流量通常在早上的时候会攀升至超过每分钟一百万个请求。同时，我们也将服务器的数目从100台缩减到了20台。 2_host.png 通过合理地配置集群和auto-scaling，我们能够做到只配置4台EC2 c4.Large实例。然后当CPU使用率持续5分钟在90%以上时用Elastic Auto-Scaling来创建新的实例。 3_util.png 结束语对我来说简洁（simplicity）是第一位的。我们可以利用无数队列，很多后台worker以及复杂的部署来设计一个复杂系统，最终我们还是使用了Elasticbeanstalk auto-scaling的强大功能和Go语言提供的应对并发的简单方法。用仅仅4台机器（可能还不如我的MacBook Pro强大）来处理每分钟一百万次POST请求对Amazon S3进行写操作。 每项任务都有对应的正确工具。当你的 |
|
|
