300亿及以上

几年前，我创建了一个免费的网络服务，ipify。

ipify 是一款免费且高度可扩展的 IP 地址查询服务。当您查询其 REST API 时，它会返回您公开的 IP 地址。

我创建 ipify 是因为当时我正在构建复杂的基础设施管理软件，需要在不使用任何管理 API 的情况下动态发现某些云实例的公共 IP 地址。

当我在线搜索免费提供的反向 IP 查找服务时，我没有找到任何合适的解决方案：

• 我可以尝试从某些网站上抓取我的 IP（但这是不好的做法，而且可能会导致主机商的投诉）
• 有一些 API 需要收费（呸！）
• 有一些 API 允许您每天进行有限次数的查找（这让我感到害怕，因为当时我管理着很多实例）
• 有些 API 看起来正是我想要的，但使用时却会出错、随机宕机，或者质量不佳。当我检查dig某个提供商的记录时，我注意到整个服务都运行在一台服务器上（带有 A 记录），而这台服务器会直接终止请求：这可不是世界上最具可扩展性/高可用性的服务。
• 有一个 API 服务看起来还不错，但正在努力通过捐款筹集资金以维持运营。与一个濒临倒闭的 API 服务集成让我感到非常不安。

出于所有这些原因，我决定自己做一个小服务，尽可能多地解决这个问题。毕竟，编写一个返回单个字符串的软件并不难，我为什么不试试呢？

我认为最坏的情况是我每月要花费 30 美元左右，并将其视为一项公共服务。

ipify v0

ipify 的第一次迭代非常简单。我
用 Node 编写了一个非常小巧的 API 服务（不到 50 行代码）（当时我经常使用 Node）。由于 ipify 服务的整个前提就是返回一个字符串，所以我认为这是 Node 技术的一个完美用例：以最小的 CPU 占用率处理大量请求。

在 Node 中构建好 API 服务后，我搭建了一个简单的静态网站
来支持前端，并将其部署到 Amazon 的 S3 存储桶中。然后，我
配置了一个 CloudFront 源站（Amazon 的 CDN 服务），将其置于 S3 存储桶的前端，并缓存页面以实现超快的加载速度。

现在，无论如何我都不是一个设计师...但是，有了一点
引导爱，事情就变得还不错=)

一切正常后，我做了一些快速测试，一切似乎都运行正常，所以我进入了下一阶段：部署。

进入 Heroku

我是Heroku 的忠实粉丝，甚至还写了一本关于它的书。

我使用 Heroku 已经很多年了，我认为它是开发者世界中最被低估的服务之一。如果你还没用过，一定要去试试！

我决定，如果我想以可扩展、高可用性和廉价的方式运行 ipify，那么 Heroku 是最简单和最好的选择：所以我选择了它。

我在一两分钟内将 ipify 部署到 Heroku，在一台测力计（Web 服务器）上运行，并进行了一些有限的测试。一切似乎都运行良好，我对自己感到非常满意。

如果您不熟悉 Heroku，让我解释一下 ipify 的基础设施是如何运作的：

• Heroku 在一个配备 512M RAM 和有限 CPU 的小型 dyno（Web 服务器）上运行我的 ipify Web 服务
• 如果我的进程崩溃或出现任何严重问题，Heroku 会自动为我重启它
• Heroku 运行了一个负载均衡器，它接受我应用程序的所有传入请求，并将它们转发到我的 dyno（Web 服务器）来处理请求

这是一个很好的设置，因为：

• 一切都高度可用：Heroku 的负载均衡器、我的测功机、一切
• 它无需维护、配置管理或任何类型的部署代码。它是 100% 自动化的。
• 它很便宜：我每月支付约 7 美元来运行这个 Web 服务器
• 速度很快：Heroku 运行在亚马逊网络服务 (AWS) 上，所以我的基础设施运行在全球最受欢迎的云托管目的地之一：AWS 美国东部（弗吉尼亚州）。这意味着它在地理位置上位于美国东海岸：与欧洲仅一海之隔，距离美国本土其他地区也不算太远。这意味着来自世界大部分地区的用户无需长途跋涉即可访问该服务。

此刻，我感觉非常好。构建、设置、测试并投入生产只用了不到一天的时间。

然后我将 ipify 集成到我自己的基础设施管理代码中，以解决我最初需要解决的问题。

在我开始注意到一些问题之前，大约一个月一切都很顺利......

人气……呃

我从未推广过 ipify，但它最终在 Google 上“IP 地址 API”搜索词条中排名很高。我想，这些年来在文字编辑和 SEO 方面的努力终于有了回报。

大约一个月后，ipify 在 Google 搜索结果中排名靠前，吸引了数千名新用户。随着这项服务的知名度不断提升，我开始发现一些问题。

我的 Heroku 负载均衡器发出了警告，因为我的 Node 服务器无法足够快地处理传入的请求。最终发生的情况是：

• 太多用户会向 ipify 发出 API 请求
• 我的 Node 服务器响应请求的速度会变慢，因此延迟会增加
• Heroku 负载均衡器会注意到这一点，并在将请求发送到我的 Node 服务器之前开始缓冲请求
• 由于我的 Node 服务器无法足够快地处理请求，我的负载均衡器会向用户返回 503 错误，请求就会终止

这不是一幅美丽的图画。

所以我的做法很简单：我又加了一个 Heroku 测功机。这样，我的容量就翻倍了，一切又能顺利运行了。缺点是，在 Heroku 上运行两个“生产级”测功机让我的成本飙升到了 50 美元。一旦超过一个测功机，你就得按正常费率付费了：每个测功机每月 25 美元。

我认为现在这项服务的受欢迎程度可能已经达到顶峰，而且我可以接受每月支付 50 美元，所以我只需这样做，一切就会恢复正常。

但是……事情并没有那么顺利。

不到一周，我就收到了 Heroku 的警报，说我又遇到了和以前一样的问题。查看统计数据后，我发现流量翻了一番，而且看起来 ipify 的使用率又太高了。

我又加了一台测功机（每月成本增加到约75美元），但还是决定进一步调查一下。我是个节俭的人——每月损失超过50美元的想法实在令人难以接受。

调查

当我开始调查发生了什么事情时，我做的第一件事就是检查 ipify 每秒实际收到的请求数 (rps)。结果让我大吃一惊：它很低。

如果我没记错的话，ipify 当时的吞吐量只有 10 rps 左右。看到这个数字这么小，我立刻意识到我的代码肯定出了问题。如果我无法在两台小型 Web 服务器上同时处理 10 rps，那我肯定是哪里出了问题。

我首先注意到的是，我运行的是一个 Node 进程。这个问题很容易解决：我开始使用 Node集群模块，然后，砰！我立即为每个 CPU 核心运行了一个进程。这有效地使我的 Heroku 测功机的吞吐量翻了一番。

但 20 rps 似乎还是个小数目，所以我做了进一步的挖掘。我没有在 Heroku 上进行负载测试，而是在笔记本电脑上进行了一些本地负载测试。

我的笔记本电脑比小型 512M RAM Heroku 测功机强大得多，所以我认为我应该看到更好的吞吐量。

我使用ab 工具进行了一些测试，惊讶地发现即使在我的笔记本电脑上，我的 Node 进程也无法超过 30 rps 的阈值（我的笔记本电脑上运行着 Linux，ab 在那里运行良好）。之后，我进行了一些基本的性能分析，发现 Node 花费了大量时间执行基本的字符串操作（从数据包头中提取 IP 地址X-Forwarded-For并进行清理）。无论我尝试什么方法，都无法将吞吐量提升到远高于该限制的水平。

此时，生产环境的 ipify 服务能够在两个测功机上提供大约 20 RPS 的响应速度。ipify 每月总共处理约 5200 万个请求。这并不令人印象深刻。

为了提高性能，我决定用 Go（几个月前我开始使用它）重写该服务，看看是否可以从等效的 Go 服务器中获得更高的吞吐量。

ipify v1

用 Go 重写 ipify 是一个简短（但有趣）的实验。

它让我有机会尝试许多不同的 Go 路由栈：Gorilla/mux、Martini 和httprouter。在对这三种路由工具进行基准测试和试用之后，我最终选择了 httprouter，因为它的性能明显优于其他两个更受欢迎的选项。

在我的笔记本电脑上，我的 Go 服务器每秒可以处理约 2,500 个请求。这是一个巨大的进步。内存占用也低了很多，大约在 5M 左右。

由于我对 Go 产生了新的热爱，我立即采取行动并在 Heroku 上部署了我的新的基于 Go 的 ipify 服务。

结果非常棒。我能够从一台测功机获得大约 2000 RPS 的吞吐量！这使我的托管费用降至每月 25 美元，总吞吐量达到每月约 52 亿次请求。

几天后，在与一位经验丰富的 Go 开发人员交流时，我最终重写了部分字符串处理功能，这使我的吞吐量增加了约 1k RPS。此时，我能够在每个测功机上维持约 77 亿次/月的请求（略有不同）。

我至少可以说很激动。

更受欢迎

虽然我能够在短时间内将托管费用降低到合理范围内，但大约两个月后，ipify 又开始出现问题。它的增长速度令人震惊。大约在这个时候，我为 ipify 设置了Google 快讯，这样当有人提到它时我就能及时收到通知。

我开始收到通知，越来越多的人开始在个人和工作项目中使用 ipify。之后，我开始收到一些公司的电子邮件，询问是否可以将其嵌入到他们的产品中（其中包括一家大型智能电视提供商、众多媒体机构、物联网供应商等）。

在我意识到这一点之前，ipify 每月要处理大约 150 亿个请求，而我现在每月的托管费用又要回到 50 美元。

但这也没有持续多久。

我很快注意到，ipify 的流量持续快速增长。有几个月的时间，它每月都会增加 10 亿个请求。

我还开始遇到突发流量的问题——ipify 会在短时间内收到大量突发流量，但很快就会消失。我推测这些流量是引导脚本、cron 作业和其他类似的定时操作的一部分。

后来我通过用户通知发现，杀毒软件厂商开始屏蔽 ipify，因为它开始被 root kit、病毒和其他恶意软件使用。攻击者会利用 ipify 获取受害者的公网 IP 地址，然后将其发送到一个中心位置，用于恶意目的。我猜想这种使用方式是造成大量流量爆发的原因。

虽然我并不喜欢帮助 VX 开发者，也不喜欢花钱去帮助他们，但我决定保持 ipify 的中立运行，为所有想使用它的人提供服务。我从来都不喜欢那种挑三拣四的开发者服务。我喜欢让事情变得简单。

这就让我不得不处理突发流量的问题。处理突发流量很棘手，因为我主要有两个选择：

• 需要花费一些成本来运行额外的测功机，并随时为突发流量做好准备，或者
• 使用像Adept这样的自动缩放工具，根据流量模式自动创建和销毁测功机

我最终决定亲自参与，选择方案 1，因为我不想在 Adept 的服务上额外花钱（尽管我以前用过，而且它真的很棒）。那时候我每月花费 150 美元，而 ipify 每月处理的请求数约为 250 亿次。

这让我们回顾不久前的往事。

ipify 处理了 300 亿次请求

在过去的几个月里，ipify 屡创佳绩，每月请求数多次突破 300 亿次。这是一个激动人心的里程碑，也是一件令人欣喜的事情。

如今，ipify 的常规服务速度在 2k 到 20k RPS 之间（几乎从来都不稳定）。流量总是变化无常，而且使用率经常居高不下，以至于我完全放弃了尝试以任何有意义的方式检测流量模式。平均响应时间在 1 到 20 毫秒之间，具体取决于流量模式。

目前，该服务的月费在 150 美元到 200 美元之间，具体取决于突发流量和其他因素。如果我把这个成本算进去（假设每月支出 200 美元），ipify 处理每个请求的总成本似乎只有 0.000000007 美元。这真是低得惊人。

如果将其与在 Lambda 等平台上运行相同服务的预期成本进行比较，ipify 的总费用将达到：1,243.582 美元/月（计算）+ 6,000 美元/月（请求）= 约 7,243.58 美元。简单来说，这只是餐巾纸背面的简单计算。我将 ipify 的数据代入了 AWS 网站上 Lambda 定价示例中：https://aws.amazon.com/lambda/pricing/。注意：这并未将 API 网关的成本计算在内，因为 API 网关的成本可能会更高。

总而言之，我对 ipify 的价格非常满意。它是一款经济实惠、用途简单的服务。

ipify 的未来

这引领我走向未来。随着 ipify 的不断发展，这项服务收到了许多不同的需求：IPv6 支持（Heroku 不支持 :(）、更好的网页设计、其他有关 IP 地址的元数据等等。

由于我最近忙于其他项目，我最终将 ipify 的所有权转让给了我在https://www.whoisxmlapi.com的好朋友。

乔纳森和他的团队都是非常优秀的人才，他们致力于构建一系列有价值且有趣的开发人员 API 服务。

虽然我仍然会不时地提供帮助，但 Jonathan 和团队目前正在为 ipify 实现新功能，并努力推出一些令我兴奋的非常酷的变化（包括改进的 UI 和更多的数据端点）。

我期待看到ipify在未来几年继续发展。

如果您有任何疑问或想与我联系，请给我发送电子邮件。

-R