迁移成功案例：ScraperAPI的DevOps团队如何利用App Platform构建他们的DigitalOcean Kubernetes应用
内容提要
ScraperAPI是一家网络爬虫平台，因带宽需求增长而迁移至DigitalOcean Kubernetes（DOKS），实现每秒抓取14,000个网站，月处理360亿请求。通过DOKS，他们提高了可扩展性和可靠性，节省了时间，专注于新功能开发，提供99.9%的正常运行时间。
延伸解读
迁移策略：提升和转移的适用性
ScraperAPI采用“提升和转移”方法，将现有虚拟机直接迁移到Kubernetes，不修改架构和代码。这种方法适合希望快速获得Kubernetes可扩展性优势、但不想立即重构应用的团队。不过，文章也指出他们至今仍依赖单体应用，说明迁移并未解决架构层面的所有问题，后续仍需逐步拆分。
小团队如何管理大规模基础设施
ScraperAPI仅由五名工程师组成的DevOps团队，管理着每秒14000次抓取、月处理360亿请求的基础设施。他们依靠DOKS和其他托管服务来降低运维负担，并通过自动化工具（如GitHub Actions）简化流程。这表明，合理利用托管服务和自动化，小团队也能支撑高负载业务。
从App Platform到DOKS的开发工作流
ScraperAPI先在DigitalOcean App Platform上创建概念验证（POC），验证可行后再迁移到DOKS进行扩展。他们使用GitHub Actions自动化迁移，包括生成Kubernetes YAML文件、上传镜像到DigitalOcean容器注册表等。这种工作流允许团队快速试验新功能，同时保持生产环境的稳定和可扩展性。
成本与可靠性：自动扩展和高可用控制平面
ScraperAPI启用了DigitalOcean集群自动扩展器，可根据负载自动调整节点，控制成本。同时，他们激活了高可用控制平面，以获得99.95%的SLA正常运行时间。文章提到，迁移后扩展时间从以往的两周缩短到不到一分钟，这有助于他们快速响应流量变化，并维持99.9%的对外服务可用性。
Q&A
ScraperAPI为什么选择迁移到DigitalOcean Kubernetes？
ScraperAPI因带宽需求增长和对可扩展性、可靠性的需求，选择迁移到DigitalOcean Kubernetes。
ScraperAPI迁移后每秒能抓取多少个网站？
迁移后，ScraperAPI每秒能抓取14,000个网站。
ScraperAPI的迁移过程是如何自动化的？
ScraperAPI使用GitHub Actions自动化从App Platform到DOKS的迁移过程。
ScraperAPI在迁移前使用了什么架构？
迁移前，ScraperAPI使用了Droplets（虚拟机）架构。
ScraperAPI的团队规模是多少？
ScraperAPI的团队由五名工程师组成。
迁移到DOKS后，ScraperAPI的正常运行时间是多少？
迁移到DOKS后，ScraperAPI提供99.9%的正常运行时间。
