用Golang处理每分钟百万级请求

我在防垃圾邮件,防病毒和防恶意软件领域已经工作了15年,前后在好几个公司任职。我知道这些系统最后都会因为要处理海量的数据而变得非常复杂。

我现在是smsjunk.com的CEO并且是KnowBe4的首席架构师。这两个公司在网络安全领域都非常活跃。

有趣的是,在过去10年里作为一个码农,所有我经历过的网站后台开发用的几乎都是用Ruby on Rails 。不要误解,我很喜欢Ruby on Rails 并且认为它是一个非常棒的开发环境。往往在一段时间后,你开始以ruby的方式来设计系统。这时你会忘记利用多线程,并行,快速执行(fast executions)和较小的内存开销(small memory overhead),软件的架构会变得简单而高效。很多年来,我一直是C/C++DelphiC# 的开发者。我开始意识到使用正确的工具,工作会变得简单很多。

我对语言和框架并不是很热衷。我相信效率,产出和代码的可维护性取决于你如何架构一个简洁地解决方案。

问题

在开发我们的匿名遥测和分析系统时,我们的目标是能够处理从上百万个端点发来的大量POST请求。HTTP请求处理函数会收到包含很多载荷(payloads)的JSON文档。这些载荷(payloads)需要被写到Amazon S3上,接着由map-reduce系统来处理。

通常我们会创建一个worker池架构(worker-tier architecture)。利用如下的一些工具:

然后设置两个集群,一个用作处理HTTP请求,另外一个用作workers。这样我们能够根据处理的后台工作量进行扩容。

从一开始我们小组就觉得应该用Go来实现,因为在讨论阶段我们估计这可能会是一个处理非常大流量的系统。我已经使用Go语言两年并用它在工作中开发了一些系统,但它们都没有处理过这么大的负载(load)。

我们首先创建了几个结构来定义HTTP请求的载荷。我们通过POST请求接收这些载荷,然后用一个函数上传到S3 bucket。

type PayloadCollection struct {
    WindowsVersion  string    `json:"version"`
    Token           string    `json:"token"`
    Payloads        []Payload `json:"data"`
}

type Payload struct {
    // [redacted]
}

func (p *Payload) UploadToS3() error {
    // the storageFolder method ensures that there are no name collision in
    // case we get same timestamp in the key name
    storage_path := fmt.Sprintf("%v/%v", p.storageFolder, time.Now().UnixNano())

    bucket := S3Bucket

    b := new(bytes.Buffer)
    encodeErr := json.NewEncoder(b).Encode(payload)
    if encodeErr != nil {
        return encodeErr
    }

    // Everything we post to the S3 bucket should be marked 'private'
    var acl = s3.Private
    var contentType = "application/octet-stream"

    return bucket.PutReader(storage_path, b, int64(b.Len()), contentType, acl, s3.Options{})
}

简单地使用Goroutines

一开始我们用了最简单的方法来实现POST请求的处理函数。我们尝试通过goroutine来并行处理请求。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

    if r.Method != "POST" {
        w.WriteHeader(http.StatusMethodNotAllowed)
        return
    }

    // Read the body into a string for json decoding
    var content = &PayloadCollection{}
    err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(&content)
    if err != nil {
        w.Header().Set("Content-Type", "application/json; charset=UTF-8")
        w.WriteHeader(http.StatusBadRequest)
        return
    }

    // Go through each payload and queue items individually to be posted to S3
    for _, payload := range content.Payloads {
        go payload.UploadToS3()   // <----- DON'T DO THIS
    }

    w.WriteHeader(http.StatusOK)
}

对于适量的负载,这个方案应该没有问题。但是负载增加以后这个方法就不能很好地工作。当我们把这个版本部署到生产环境中后,我们遇到了比预期大一个数量级的请求量。我们完全低估了流量。

这个方法有些不尽如人意。它无法控制创建goroutine的数量。因为我们每分钟收到了一百万个POST请求,上面的代码很快就奔溃了。

再次尝试

我们需要一个不同的解决方案。在一开始,我们就讨论到需要把HTTP请求处理函数写的简洁,然后把处理工作转移到后台。当然,这是你在Ruby on Rails 世界里必须做的,否则你会阻塞所有worker的工作(例如puma,unicorn,passenger等等,我们这里就不继续讨论JRuby了)。我们需要用到Resque,Sidekiq,SQS等常用的解决方案。这个列表可以很长,因为有许多方法来完成这项任务。

第二个版本是创建带缓冲的channel。这样我们可以把工作任务放到队列里然后再上传到S3。因为可以控制队列的长度并且有充足的内存,我们觉得把工作任务缓存在channel队列里应该没有问题。

var Queue chan Payload

func init() {
    Queue = make(chan Payload, MAX_QUEUE)
}

func payloadHandler(w http.ResponseWriter, r *http.Request) {
    ...
    // Go through each payload and queue items individually to be posted to S3
    for _, payload := range content.Payloads {
        Queue <- payload
    }
    ...
}

然后我们需要从队列里提取工作任务并进行处理。代码下图所示:

func StartProcessor() {
    for {
        select {
        case job := <-Queue:
            job.payload.UploadToS3()  // <-- STILL NOT GOOD
        }
    }
}

坦白的说,我不知道我们当时在想什么。这肯定是熬夜喝红牛的结果。这个方法并没有给我们带来任何帮助。队列仅仅是将问题延后了。我们的处理函数(processor)一次仅上传一个载荷(payload),而接收请求的速率比一个处理函数上传S3的能力大太多了,带缓冲的channel很快就到达了它的极限。从而阻塞了HTTP请求处理函数往队列里添加更多的工作任务。

我们仅仅是延缓了问题的触发。系统在倒计时,最后还是崩溃了。在这个有问题的版本被部署之后,系统的延迟以恒定速度在不停地增长。

0_latency

更好的解决办法

我们决定使用Go channel的常用编程模式。使用一个两级channel系统,一个用来存放任务队列,另一个用来控制处理任务队列的并发量。

这里的想法是根据一个可持续的速率将S3上传并行化。这个速率不会使机器变慢或者导致S3的连接错误。我们选择了一个Job/Worker模式。如果你们对JavaC# 等语言熟悉的话,可以把它想象成是Go语言用channel来实现的工作线程池。

var (
    MaxWorker = os.Getenv("MAX_WORKERS")
    MaxQueue  = os.Getenv("MAX_QUEUE")
)

// Job represents the job to be run
type Job struct {
    Payload Payload
}

// A buffered channel that we can send work requests on.
var JobQueue chan Job

// Worker represents the worker that executes the job
type Worker struct {
    WorkerPool  chan chan Job
    JobChannel  chan Job
    quit        chan bool
}

func NewWorker(workerPool chan chan Job) Worker {
    return Worker{
        WorkerPool: workerPool,
        JobChannel: make(chan Job),
        quit:       make(chan bool)}
}

// Start method starts the run loop for the worker, listening for a quit channel in
// case we need to stop it
func (w Worker) Start() {
    go func() {
        for {
            // register the current worker into the worker queue.
            w.WorkerPool <- w.JobChannel

            select {
            case job := <-w.JobChannel:
                // we have received a work request.
                if err := job.Payload.UploadToS3(); err != nil {
                    log.Errorf("Error uploading to S3: %s", err.Error())
                }

            case <-w.quit:
                // we have received a signal to stop
                return
            }
        }
    }()
}

// Stop signals the worker to stop listening for work requests.
func (w Worker) Stop() {
    go func() {
        w.quit <- true
    }()
}

我们修改了HTTP请求处理函数来创建一个含有载荷(payload)的Job 结构,然后将它送到一个叫JobQueue 的channel。worker会对它们进行处理。

func payloadHandler(w http.ResponseWriter, r *http.Request) {

    if r.Method != "POST" {
        w.WriteHeader(http.StatusMethodNotAllowed)
        return
    }

    // Read the body into a string for json decoding
    var content = &PayloadCollection{}
    err := json.NewDecoder(io.LimitReader(r.Body, MaxLength)).Decode(&content)
    if err != nil {
        w.Header().Set("Content-Type", "application/json; charset=UTF-8")
        w.WriteHeader(http.StatusBadRequest)
        return
    }

    // Go through each payload and queue items individually to be posted to S3
    for _, payload := range content.Payloads {

        // let's create a job with the payload
        work := Job{Payload: payload}

        // Push the work onto the queue.
        JobQueue <- work
    }

    w.WriteHeader(http.StatusOK)
}

在初始化服务的时候,我们创建了一个Dispatcher 并且调用了Run() 函数来创建worker池。这些worker会监听JobQueue 上是否有新的任务并进行处理。

dispatcher := NewDispatcher(MaxWorker)
dispatcher.Run()

下面是我们的dispatcher实现代码:

type Dispatcher struct {
    // A pool of workers channels that are registered with the dispatcher
    WorkerPool chan chan Job
}

func NewDispatcher(maxWorkers int) *Dispatcher {
    pool := make(chan chan Job, maxWorkers)
    return &Dispatcher{WorkerPool: pool}
}

func (d *Dispatcher) Run() {
    // starting n number of workers
    for i := 0; i < d.maxWorkers; i++ {
        worker := NewWorker(d.pool)
        worker.Start()
    }

    go d.dispatch()
}

func (d *Dispatcher) dispatch() {
    for {
        select {
        case job := <-JobQueue:
            // a job request has been received
            go func(job Job) {
                // try to obtain a worker job channel that is available.
                // this will block until a worker is idle
                jobChannel := <-d.WorkerPool

                // dispatch the job to the worker job channel
                jobChannel <- job
            }(job)
        }
    }
}

这里我们提供了创建worker的最大数目作为参数,并把这些worker加入到worker池里。因为我们已经在docker化的Go环境里使用了Amazon的Elasticbeanstalk并且严格按照12-factor方法来配置我们的生产环境,这些参数值可以从环境变量里获得。我们可以方便地控制worker数目和任务队列的长度。我们可以快速地调整这些值而不需要重新部署整个集群。

var (
  MaxWorker = os.Getenv("MAX_WORKERS")
  MaxQueue  = os.Getenv("MAX_QUEUE")
)

部署了新版本之后,我们看到系统延迟一下子就降到了可以忽略的量级。同时处理请求的能力也大幅攀升。

1_latency

Elastic Load Balancers热身后几分钟,我们看到Elasticbeanstalk应用开始处理将近每分钟一百万个请求。我们的流量通常在早上的时候会攀升至超过每分钟一百万个请求。同时,我们也将服务器的数目从100台缩减到了20台。

2_host

通过合理地配置集群和auto-scaling,我们能够做到只配置4台EC2 c4.Large实例。然后当CPU使用率持续5分钟在90%以上时用Elastic Auto-Scaling来创建新的实例。

3_util

结束语

对我来说简洁(simplicity)是第一位的。我们可以利用无数队列,很多后台worker以及复杂的部署来设计一个复杂系统,最终我们还是使用了Elasticbeanstalk auto-scaling的强大功能和Go语言提供的应对并发的简单方法。用仅仅4台机器(可能还不如我的MacBook Pro强大)来处理每分钟一百万次POST请求对Amazon S3进行写操作。

每项任务都有对应的正确工具。当你的Ruby on Rails 系统需要一个很强大的HTTP请求处理器,可以尝试看看ruby生态系统以外的其它更强大的选项。

 

原文链接@medium.com 发表于2017/08/30