日前，Netflix 发布了一篇 博文 ，阐述了在微服务架构中缓解应用程序 DDoS 攻击的策略。该博文概要阐述了如何识别触发这种攻击的请求，如何使用开源的 Repulsive Grizzly 和 Cloud Kraken 框架进行测试，最后，还提供了保护系统的一些最佳实践。
Netflix 应用程序安全专家 Scott Behrens 与产品和应用程序安全主管 Bryan Payne 首先指出，微服务架构特别容易受到应用程序 DDoS 攻击，这是因为频繁的 API 调用会导致服务周围产生多个网络跳跃（ network hops），很容易导致系统攻击自身：
“微服务架构中的单一请求可能会生成数以万计的复杂中间层和后端服务调用。”
这些应用程序 DDoS 攻击带来的第一个挑战是识别。有些看起来像是用户合法的 API 调用，当这种调用即将引发大量内部资源消耗时，如何及时检测出来？
他们列出的首要策略之一就是确定 API 调用需要多长时间。这里我们不会监控前端的请求时间，这有可能会带来误报，监控后端服务的请求时间更为有利。然后对这些请求进行逆向工程，以确定哪种原始 API 调用可能会触发它。
当开发人员找寻出这些 API 调用时，它是一个查看请求本身的过程，并找出可以使其更为耗时的方法。比如，我们可以扩大搜索请求中的范围参数，以获得更大的结果集。在确定是否找到了正确的请求时，可以使用错误指示器（indicator），比如速率限制和异常，或简单地增加延迟。
一旦开发人员确定了这些请求，我们建议使用 Repulsive Grizzly （一个应用层 DDoS 测试框架）来运行它们。它并非一个识别工具，它会针对被测系统触发这些请求，从而提供了一种简化测试过程的方法。
他们还引入了 Cloudly Kraken，这是一个开源的 AWS 测试工具，有助于在全球范围内协调测试运行。这是通过管理一组可扩展的跨区域 AWS 实例完成的，每个实例都运行 Repulsive Grizzly 测试套件。它还提供时间同步功能，确保测试并行运行。
一旦请求被识别并通过测试验证，我们会建议采取以下缓解策略：
生成这样的一种架构，最大限度减小微服务之间的依赖关系。如果一个服务失败，理想状况下，它应该实现故障隔离，而不会影响其他服务。 了解服务队列和服务请求。例如，限制批量大小或请求的对象。 提供从后端服务到 Web 应用程序防火墙的反馈环路。这为它提供了在 API 调用时下游资源利用率的额外信息，在很多 Web 应用程序防火墙的部署中，它只会监控边缘（edge）服务器，无法得到请求对 API 网关的影响。 监视缓存未命中，多数情况下可能是因为高速缓存未正确配置。 利用客户端的各种弹性模式，如断路器和超时设定。完整的博文可以点 此处 在线阅读，在文章中作者通过案例研究深入分析了该主题。
查看英文原文： Netflix: Application DDoS Protection in Microservice Architectures
感谢张卫滨对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。
