免费API网关与API安全网关

一般而言，流量控制是一种控制用户需求的策略，主要包括：权限、限流、流量调度。
上一篇关于权限的文章已经提到了，这篇关于限流，下一篇关于流量调度。
限流是指限制用户调用的频率。（QPS/QPM）或者次数。

流量限制，从用户或运营的角度来看，最直观的效果就是-收费。
各大主流开放平台的对外API一般都有一些免费金额，可供个人测试。一旦你想大规模调用它们，你需要支付更多的金额(频率和频率)，并根据调用次数或频率收取费用。一旦超过所拥有的金额，调用将受到限制。

事实上，这是限流最大的用途，只是用户或操作同学没有感觉，所以大多数人都不太了解。
网关后面是各种服务，各种服务的接口通过网关透露给用户调用。理论上，用户的流量是不可预测的，随时都有可能出现一波。一旦流量的峰值超过服务的承载能力，服务就会挂机，比如一个大新闻发生时的微博，比如几年前的12306.
因此，网关必须确保后端服务的流量不能超过服务所能承受的上限。这个上限是网关和各种服务协商的。

由简单到难，限流可分为单机限流、单集群限流、全集群限流。
本文不讨论漏桶、令牌桶等具体限流算法，只谈概念和思想。

单机限流思想很简单，就是每台机器的限流值 x 机器数量 = 总限流值。
举例来说，A用户的QPS限制是100，网关部署了10台机器，那么，每台机器限制10QPS就可以了。
首先说一下好处，这个方法实现起来很简单，每台机器都可以在本地内存中计算qps，超过阈值就拒绝流动。
但单机限流的缺陷也非常明显，主要体现在两个方面：
当网关部署的机器数量发生变化时，需要根据机器数量调整每台机器的限流值。现实中，机器数量的变化是很常见的，因为扩容、缩容、机器停机等原因。
单机限流的前提是每个网关承载的用户流量是平均的，但实际上，在某些时候，用户的流量并没有完全平均分布在每台机器上。
举个例子：
10台机器，每台限制qps10，其中3台机器每台实际qps为15，用户流量因超限而被拒绝。剩下的7台每台qps为7。这样，用户的总qps = 15*3 + 7*7 = 用户qps没有超限，但有些流量被拒绝了，这是一个很大的问题。
事实上，为了抵消流量不均匀的问题，单个限流的阈值也会稍大一些。
由于上述问题，单机限流通常被用作一种备用手段，大多数情况下仍然使用集群限流。

首先看一张示意图：

与单机限流相比，集群限流的计数工作向redis集群中移动，解决了单机限流的缺陷。
但是集群限流并不完美，因为redis已经引入，所以当网关和redis之间的网络抖动和redis本身出现故障时，集群限流就会失效。这个时候，我们还是要靠单机限流。
也就是说，集群限流 + 单机限流配合，是一种比较安全的方案。

接下来，让我们思考一个问题:大型网关通常由多个机房和地区部署。当然，后端服务也是由多个机房和地区部署的。在保护服务方面，集群限流就足够了。但对于用户来说，仍然存在一些问题:
例如，用户购买的QPS上限为30，我们的网关部署在中国北、中、南三个地区，那么如何分配这个30QPS呢？
平均水平肯定不好。用户的流量可能明显不平衡。比如用户的业务主要集中在中国北方，那么大部分用户的流量都会进入北方的网关。如果网关限制QPS为10，用户肯定会投诉。
那么每一个区域都限制在30行吗？不，如果用户的流量均匀分布在各个区域，那么用户实际上可能已经购买了30QPS，使用了90QPS，这太可惜了。
建立一个公共redis集群，按照解决单机限流流量不均的思路来计数行吗？
不，由于信号传播速度的限制和中国广阔的领域，每个流量都是计数的，这肯定是不现实的。过高的rt会导致限流失去意义，带宽成本会变得极其昂贵，对redis的规格要求也会很高。总之，很贵，解决不了问题。
有一个巧妙的解决方案：当地集群阶梯计数 + 全集群检查。
或者刚才的例子：
限流阈值为90，所以三个区域各自计数。当该区域的值达到30时，去另外两个区域取对方当前的计数值，三个区域的计数值加起来。如果超过，告诉另外两个区域超过，开始拒绝流量。如果没有超过，当地QPS每增加10次，重复上述动作。
通过这种方式，可以有效地减少与redis的互动次数，同时实现整个地区的真实集群限流。
当然，由于rt和阶梯计数间隔的存在，这种全区域集群限流肯定是不允许的，但比单集群限流好得多。

当用户流量特别大时，redis计数会遇到典型的热点key问题，导致redis集群单节点压力过大。解决这个问题的方法有两种:分散和抽样。

分散是指在热点key中加入一些后缀，使其成为多个key，从而将hash分配到无法通过的redis节点。
例如热点key就是abcd，然后打散之后，key就变成了abcd1、abcd2、abcd3、abcd4。技术上，轮流加1、2、3、四个后缀就可以了。

抽样是指对于热点key，并不是每个请求来的时候都要计数，而是要进行抽样，比如每10个请求要记住一次，这样redis的压力就会降低到十分之一。

谈到流量调度也说完了哈哈，那么下一篇文章再谈监控，顺便推一下我现在正在使用的国产网关：GOKU，来自Eolinker。我认为它比KONG更容易使用，有兴趣的同学可以自己去了解。
www.eolinker.com
阿里云API网关
API 网关（API Gateway）提供高性能、高可用性 API 托管服务，帮助用户向外界开放部署。 ECS、阿里云产品上的应用，如容器服务，提供完整的应用 API 发布、管理和维护生命周期管理。用户可以快速、低成本、低风险地开放数据或服务，只需要简单的操作。帮助用户实现微服务聚合、前端和后端分离、系统集成，向合作伙伴和开发者开放功能和数据

保证防攻、防重放、请求加密、身份认证、权限管理、流量控制等多种手段。 API 安全，降低 API 开放风险。

提供 API 全生命周期管理，如定义、测试、发布、下线等。 SDK、API 说明文档，提升 API 管理，迭代效率。

提供方便的监控、报警、分析、API 运行维护、运行工具，如市场，减少 API 运行，维护费用。

API 网关将能力的复用率最大化，企业之间可以互相借力，企业发展可以专注于自己的业务，实现双赢。

API 方便管理(方便管理) API 管理功能，方便 API 管理工具）

API 生命周期管理：覆盖 API 整个生命周期管理的定义、测试、发布，日常管理方便，版本管理方便，支持热升级和快速回滚。

方便文件：提供页面调试工具，自动生成 API 文档和 SDK，人力成本大大降低。

安全性稳定(严格的权限管理，精确的流量控制，全面的监控报警)

安全防护：API 在到达后端服务之前，要求到达网关需要严格的身份认证和权限认证。支持 HMAC（SHA-1,SHA-256)算法签名，支持 SSL 加密

流量控制：可控单位时间 API 允许调用次数。用于保护企业的后端服务，实现业务分级和用户分级。

支持对 API 你可以按照流量控制 API 配置不同流控的重要性，从而保证重要业务的稳定运行。

你可以根据用户的重要性来支持用户、应用和例外流控。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。