本文由作为 Going Concurrency in Go 的作者 Nathan Kozyra 撰写, 解决了互联网上最著名,最受尊敬的挑战之一, 并试图通过核心 Go 包来解决它.

原文地址: https://hub.packtpub.com/c10k-non-blocking-web-server-go/

我们已经构建了一些可用的应用程序,并且可以在日常使用的真实系统中使用这些技术. 通过这些, 我们已经能够演示Go的并发语法和方法中涉及的基本和中级模式. 然而, 现在是时候去面对一个现实世界的问题 - 一个让开发人员（以及他们的经理和副总裁）在网络的早期历史中烦恼的问题.

在解决这个问题时, 我们希望能够开发出一种能够处理大量实时, 活跃流量的高性能Web服务器.

多年来, 解决这个问题的方法完全是为了解决这个问题的硬件或侵入式缓存系统;所以, 换句话说, 用编程方法解决它应该激发任何程序员.

很多年以来, 这个问题的解决方案是调整底层硬件和使用侵入式缓存系统. 因此, 用编程方法解决这个问题将会是非常令人激动的.

我们将使用到目前为止我们学到的所有技术和语言结构, 但我们将以比迄今为止更加结构化和深思熟虑的方式进行. 到目前为止我们探索的所有内容都将发挥作用, 包括以下几点：

• 创建并发应用程序的可视化表示
• 利用 goroutine 以可扩展的方式处理请求
• 构建强大的渠道来管理 goroutine 和管理它们的循环之间的通信
• 分析和基准测试工具（JMeter, ab）来检查我们的事件循环实际工作的方式
• 超时和并发控制确保数据和请求的一致性

• C10K 问题

  C10K问题的根源在于串行, 阻塞的编程方式, 因此,我们尝试使用 Go 的并发编程方法解决这个问题将会非常适合.

  当在1999年被问到这个问题时, 对于许多服务器管理员和工程师来说, 服务 10,000 个并发访问是可以通过硬件解决的问题. 在普通硬件上来处理这种问题, 而CPU和网络带宽不会崩溃, 这对大多数人来说是很陌生.

  这个问题的解决方案的关键在于产生非阻塞代码. 当然, 在1999年, 并发模式和库并不普遍. C++ 通过一些第三方库和多线程语法的最早前身提供了一些轮询和排队选项, 后来可以通过 Boost 和 C++ 11 获得.

  在接下来的几年中, 问题的解决方案开始涌入各种语言, 编程设计和一些通用方法.

  任何性能和可扩展性问题最终都将涉及到底层硬件, 因此, 不同硬件的结果往往不同. 在一个 500MB RAM 的 486 处理器上处理 10,000 个并发连接肯定比在拥有大内存多核处理器的 Linux 服务器上处理这个问题更具挑战性.

  同样值得注意的是, 显然, 简单的回显服务器能够承担比返回大量数据的功能性 Web 服务器更多的链接. 而在这里, 我们将处理具有复杂的请求会话的情况.

  10,000个并发连接的服务器失败

  当网络诞生并且互联网商业化时, 交互水平非常低. 如果你是一个 graybeard, 你可能会想起从 NNTP/IRC 的过渡, 以及网络如何简陋.

  为了解决[页面请求]→[HTTP响应]的基本问题, 20 世纪 90 年代早期对 Web 服务器的要求非常宽松. 它会忽略所有错误响应, 标题读取和设置, 以及其他必要（但与in→out机制无关）功能, 与现代 Web 服务器相比, 早期服务器本质上非常简单.

  第一个 Web 服务器是由 Web 之父 Tim Berners-Lee 开发的.

  ERN httpd 是在 CERN（如WWW/HTTP本身）开发的, 它能处理许多你今天在网络服务器中所期望的东西 - 通过阅读代码, 你会发现核心的HTTP协议基本没有变化. 与大多数技术不同, HTTP的保质期非常长.

  在 1990 年用C编写, 它无法使用类似 Erlang 的许多语言中的并发策略. 实话说, 这样做可能是不必要的 - 大多数网络流量的主要问题是基本文件检索和协议的问题. Web服务器的的主要功能不是处理流量, 而是处理协议本身的规则.

  您仍然可以访问原始的 CERN httpd 站点并从 http://www.w3.org/Daemon/ 下载源代码. 我强烈建议您这样做, 这样做您可以学习最早的 Web 服务器解决某些最早期问题的方法.

  然而, 1990 年的 Web 和首次提出 C10K 问题的 Web 是两个截然不同的问题.

  到 1999 年, 大多数网站都有一定程度的二级或三级延迟, 由第三方软件, CGI, 数据库等软件导致, 所有这些都使问题更加复杂. 同时提供 10,000 个文件的服务的概念本身就是一个挑战.

  到 20 世纪 90 年代中期, Apache Web 服务器已经在很大程度上控制了市场（到 2009 年, 它已成为第一个服务超过1亿个网站的服务器软件）.

  Apache 的方法在互联网最早期就扎根了. 在开始时, 连接被按照先进先出的顺序处理, 然后给每个连接分配一个来自连接线程池的线程. Apache 服务器有如下两个问题：

• 阻塞连接可能导致多米诺骨牌效应, 其中一个或多个缓慢的连接可能会导致服务不可访问. 无论是在那种硬件上, Apache 都会对您可以使用的线程/工作线程数进行严格限制. 在这里, 如果使用 actor（Erlang）, 代理（Clojure）或 goroutines（Go）的并发服务器似乎完全符合要求. 并发本身并不能解决C10k问题, 但它绝对是解决这个问题的一个方法.
• 目前解决 C10K 问题的方法最值得注意和有效的例子是使用 Nginx, 它是使用并发模式开发的, 在 2002 年 C 中提供, 以解决 C10k 问题. 今天, Nginx 代表了世界上的＃2 或 ＃3 Web 服务器.

• 使用并发挑战 C10K 问题

  处理大量并发请求主要有两种方法. 第一个涉及为每个连接分配线程. 这就是 Apache（以及其他一些人）所做的事情.

  一方面, 给每个连接分配一个线程很有意义 - 它可以通过应用程序和内核的上下文切换来隔离, 控制这些连接. 而且在增加硬件时也非常方便进行扩展.

  但是大多数 Linux Web 服务器所面临的一个问题是, 每个线程默认为其堆栈保留 8MB 内存. 虽然这个内存大小可以（并且应该）被自定义, 但是这会给单个服务器带来很大程度上无法达到的内存量. 即使您将默认堆栈大小设置为 1MB, 我们也只处理 10GB 内存以处理连接的内存开销.

  这里一个极端的例子, 在显示应用中不太可能遇到. 原因如下：首先, 因为你可以决定每个线程可用的最大资源量, 其次, 因为你可以通过在几个服务器之间实现负载平衡, 而不是添加 10GB 到 80GB 的 RAM.

  即使在线程服务器环境中, 我们也会遇到导致性能下降（到崩溃点）的问题.

  首先, 让我们看一下绑定到线程的连接的服务器（如下图所示）, 这可能导致非常糟糕的情形并最终导致崩溃：

  

  这显然是我们想要避免的. 任何可能导致速度减慢的 I/O, 网络或外部进程都会带来我们所讨论的雪崩效应, 这样我们的可用线程就会被积压并且传入的请求开始堆叠.

  我们可以在这个模型中使用更多的线程, 但如前所述, 那里也存在潜在的风险, 即使这样也无法缓解潜在的问题.

  另一种方法

  为了创建可以处理 10,000 个并发连接的 Web 服务器, 我们显然会利用我们的 goroutine/channel 机制在一个循环中处理请求.

  在这个例子中, 我们假设我们正在为一家快速增长的公司建立一个公司网站.为此, 我们的网站需要能够同时提供静态和动态网页内容.

  我们想要引入动态内容的原因不仅仅是为了演示目的 - 我们希望挑战自己, 即使在其他进程阻塞时也能处理 10,000 个真正的并发连接.

  我们将尝试将并发策略直接映射到 goroutines 和 channel. 在许多其他语言和应用程序中, 这直接类似于事件循环, 我们将维护可用的 goroutine, 过期或重用已完成的 goroutine, 并在必要时生成新的 goroutine.

  在下图中, 我们展示了事件循环（和相应的goroutine）如何允许我们扩展连接而不使用太多的硬件资源, 如 CPU 线程或 RAM：

  

  这里最重要的是管理该事件循环. 我们创建一个无限循环来管理我们的 goroutine 和各个 channel 的创建和到期.

  作为其中的一部分, 我们还会打印一些内部程序执行信息的 log, 以便对我们的应用程序进行基准测试和调试.

  原本测试对比忽略, 想看的读者可以直接点击文章开始的连接进行阅读.