api网关功能有哪些（api网关和服务网关）

本文目录一览：

• 1、为什么需要api网关

• 2、关于API网关（四）——限流

• 3、阿里API网关使用总结

• 4、北大青鸟设计培训：API网关设置基础知识？

• 5、北大青鸟java培训：微服务架构中API网关的角色？

为什么需要api网关

API网关跨一个或多个内部API提供单个统一的API入口点。 通常还包括限制访问速率限制和有关安全性等特点。 诸如Tyk.io的API管理层增加了额外的功能，例如分析，货币化和生命周期管理。

基于微服务的架构可以具有10到100个或更多个服务。 API网关可以为外部消费者提供统一的入口点，而与内部微服务的数量和组成无关。

API网关对于微服务的好处：

1、防止内部关注暴露给外部客户端

API网关将外部公共API与内部微服务API分开，允许添加微服务和更改边界。 其结果是能够在不对外部绑定客户端产生负面影响的情况下重构和适当大小的微服务。 它还通过为您的所有微服务提供单一入口点，对客户端隐藏了服务发现和版本控制详细信息。

2、为您的微服务添加额外的安全层

API网关通过提供一个额外的保护层来防止恶意攻击，例如SQL注入，XML解析器漏洞和拒绝服务（DoS）攻击。

3、支持混合通信协议

虽然面向外部的API通常提供基于HTTP或REST的API，但是内部微服务可以从使用不同的通信协议中受益。 协议可能包括的Protobuf或AMQP ，或者用SOAP，JSON-RPC或XML-RPC系统集成。 API网关可以在这些不同的协议之上提供外部的，统一的基于REST的API，允许团队选择最适合内部架构的API。

4、降低微服务复杂性

如果微服务具有共同的关注点，例如使用API令牌的授权，访问控制实施和速率限制。 每个这些关注可以通过要求每个服务都实现它们，但这为微服务的开发增加更多的时间成本。 API网关将从您的代码中删除这些问题，允许您的微服务关注手头的任务。

5、微服务模拟和虚拟化

通过将微服务API与外部API分离，您可以模拟或虚拟化服务，以验证设计要求或协助集成测试。

API网关的服务对象

API网关可以为Web端、APP提供API访问，也可以给物联网设备提供API接口。另外致力于开发生态的企业还会为一些合作伙伴提供API网关，供其调用通用的微服务。对于可以提供数据或算法服务的企业，可以在云市场的API网关注册自己的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 = 94. 用户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、4的后缀就可以了。

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

说着把流量调度的也说完了哈哈，那下一篇再说说监控好了，顺便推一下我现在在用的国产网关：GOKU，来自Eolinker。我觉得比KONG好用，感兴趣的同学可以自行去了解一下。

阿里API网关使用总结

API网关  API Gateway）提供高性能、高可用的 API 托管服务，帮助用户对外开放其部署在 ECS、容器服务等阿里云产品上的应用，提供完整的 API 发布、管理、维护生命周期管理。用户只需进行简单的操作，即可快速、低成本、低风险地开放数据或服务。

利用API网关你可以提高自己公司API安全性，也可以上架到API云市场，供用户购买和使用。

这个没什么可说的，主要是你要想办法尽可能安全地存储你的AppKey和AppSecrect。

所属分组是API的基本属性，所以需要先创建分组，再在分组下创建API。每个账号默认最多可创建100个分组，如需更多分组需要提交工单。分组有所属区域（Region）的概念，比如华东上海区，选择之后就不能修改了。创建完分组之后，系统会给该分组分配一个二级域名，供测试使用，不过，每个二级域名每天最多可访问1000次。

如果你的API支持HTTPS协议，还需要为该独立域名上传 SSL 证书。我们需要把我们的域名解析到该分组上，之后才能绑定到该分组上。绑定的域名需要现在阿里云系统备案。绑定域名之后，该分组下的API就可以通过该域名来访问了，不再需要调用系统分配的二级域名了。

在API分组的环境管理中，你可以自定义环境变量，同一个变量可以再在线上、预发和测试三个环境下对应不同的值，这样在API的定义中就可以使用这里定义好的环境变量了。可以在Path、入参默认值和后端服务服务地址中加入环境变量，在API的定义中使用环境变量需要以 #变量名# 的方式使用。 如果要修改已发布的API用到的环境变量，先把老的环境变量给删掉，再重新定义一个新的同名环境变量赋上新值之后再把全部对应的API重新发布一遍，这个是异步生效的，一般发布后1分钟内生效。

这里的内容还是蛮多的，包括基本配置，前端和后端地址，请求参数配置等，详细文档可以看阿里API的官方文档，这里说几点重要的：

创建好API之后，就可以对应用进行授权了，点击API的“授权”就可以在指定环境下授权某个APP可以访问该API了，如果你在调用API的过程中控制台打印了x-ca-message中包含了Unauthorized错误，你应该想到你的API还未对该APP进行授权访问。

API编辑完成之后就可以发布到指定环境上去了，发布之后就立马生效了。可以多次编辑然后发布到不同的环境下，如果你编辑完了忘记发布到指定环境下了，是不会生效的。在分组API列表下，直接点击API名字进入的是当前API最后一次编辑保存的状态，不一定跟发布的状态一直哦。点击API右边的线上、预发或测试后面的"运行中"可以看到在该环境下最后一次编辑发布后的状态哦。

网关会在请求的时候加上日期、时间戳、nonce、userAgent、Host、AppKey、version等参数值，如果是POST请求的话，需要对参数值进行urlEncode。如果有body值的话，需要对body值，将body中的内容MD5算法加密后再采用BASE64方法Encode成字符串，放入HTTP头中。最后再通过将httpMethod、headers、path、queryParam、formParam经过一系列的运算，合成一个字符串用hmacSha256算法双向加密进行签名。

在我们分组上绑定好了域名之后，我们不管是预发还是线上环境都可以通过这同一个域名进行访问，那网关是怎么帮我们区分环境的呢？这个时候就用到上面的环境变量管理了，我们通过在环境变量中定义一个变量在不同环境下不同的值达到区分环境的效果。在网络请求的时候，我们可以在头部指定 X-Ca-Stage 参数值来让网关帮我们转发到对应环境的后端服务上，对应的值分别是：线上（RELEASE）默认、预发（PRE）和测试（TEST）。

这里重点说一下参数位置下可选的Body选项，这个地方坑了我们蛮久。我们知道在我们客户端发起POST请求时，我们会在头部指定“Content-Type”为“application/x-www-form-urlencoded”，然后把请求的参数组装成"key1=value1key2=value2"的字符串，然后在编码成二进制，放在请求的Body里，以Form表单的形式提交的。所以呢，我们在定义API的参数时，应该把参数位置选择为Body选项。但是我们在很长一段时间里，创建API时或编辑API时，参数位置处下拉一直没有Body选项，我们就把参数定义成了Query类型的了。在使用时也没有啥问题，但是一旦当我们的参数值非常长时，比如一个json字符串，这个是就报错了“414 Request-URI Too Large”，这个时候呢，网关就不会再帮我们把请求转发到服务端了。排查了很久终于找到了罪魁祸首在这里等着呢，通过把参数位置改成Body就可以了。这个可能是阿里API网关前端页面上的一个bug，有时候根本选不到Body选项，这个时候你可以先把“请求Body（非Form表单数据，比如JSON字符串、文件二进制数据等）”选项给勾选上，然后再取消勾选，再下拉展开“参数位置”就可以看到Body选项了。（该文发布时是如此，我已经将该问题反馈给阿里API网关，可能后面会修复该bug。）

另外一个问题是如果你的参数值中包含了emoji表情，需要对参数值进行urlEncode，服务端在收到请求时需要对参数值进行urlDecode。否则用的过程中会出现各种奇怪的问题。问了阿里网关的服务人员，他们的解释是，如果不进行urlEncode，参数在传到网关时可能会丢失。可以对所有Post请求的参数值统一urlEncode，服务端对收到的参数值统一进行urlDecode。

在使用网关时，timestamp和nonce这两个header参数值是可选的，如果加上这两个值，网关层会对请求进行校验，防止重放攻击。不过有个问题：在当前时间的前后15分钟的时间戳都是可以的，一旦超过15分钟就会请求失败，所以，如果用户修改了客户端的系统时间的话，API就会调不通了。这个校验有点严格，如果不知道这一点的话，用户反馈客户端不能用，而你这里测试又没有任何问题，那就泪奔了，哈哈。当然这个是可选的校验，如果不传这两个值的话，就不会校验，这个时候防重放攻击的工作就需要我们自己的服务端做了。

目前网关不支持multipart形式的上传，所以一般我们的上传API不太适合录入网关，阿里的说法是现在大家的做法普遍是先将文件上传到文件服务器，然后通过调用接口把文件地址等信息报错到服务器的方式，所以，目测以后也不大可能支持定义multipart形式的上传API。

每个 API 分组的默认流控上限是500QPS，如果你要调大QPS，需要提交工单并支付相应费用。另外网关有个“流量控制策略”的功能，它是针对API的，也就是说定好策略之后，选中对哪些API生效，这些API就会单独的受这个流量控制策略的控制。但是，需要注意的是，如果你要调大流量控制策略，也必须先调大API所在分组的QPS才会生效，否则流量控制策略可以创建但不会实际生效。

虽然我们可以在分组的环境管理中添加不同的环境变量来实现同一个API分组下可以定义不同服务域名的API，这样我们客户端在发起请求的时候，域名只需要配一个就可以了，非常方便。但是，一旦网关这一层瘫痪（尽管是小概率事件，但不排除），这个时候我们就心有余而力不足了，只能等网关尽快恢复了。如果我们一个分组对应一个我们真正的服务域名的话，一旦网关出问题，我们可以快速把该分组绑定的域名指向我们真正的该分组的服务上。

北大青鸟设计培训：API网关设置基础知识？

如果大家了解网络构成的话，对于网关应该就不会陌生了，今天我们就一起来了解一下，API网关的一些基础知识，希望对大家以后的服务器开发工作有所帮助，下面就开始今天的主要内容吧。

一、API网关产生背景在微服务的架构中，一个大的应用会被拆分成多个小的单一的服务提供出来，这些小的服务有自己的处理，有自己的数据库(也可以共用)，也许语言也是不一样的，他们可以部署在一个或多个服务器上，其实也就是对复杂的应用进行了解耦，那为什么微服务需要API网关呢?我们看看微服务后产生的问题：客户端需要知道多个服务地址通用的功能怎么处理?例如鉴权、流量控制、日志等以前一个功能可能是一次请求就可以完成，现在可能要多个服务一起进行才可以，那如何减少客户端请求的时间呢?由于以上几点的问题，所以在所有的服务前面还需要定义一个代理，即API网关，所有的客户端请求都必须经过API网关代理到真实的服务地址，这也可以有效的避免真实地址的暴露，同时API网关也可以集成鉴权、流量控制、日志、API聚合、黑白名单等。

二、kong的介绍Kong是由Mashape开发的并且于2015年开源的一款API网关框架，基于nginx以及OpenResty研发，主要特点是高性能以及其强大的扩展性，由于本身是基于nginx进行开发，因此网上很多关于nginx的调优等资料都可以用到kong的上面，包括负载均衡、或者充当web服务器等kong的扩展是通过插件机制进行的，并且也提供了插件的定制示例方法，插件定义了一个请求从进入到反馈到客户端的整个生命周期，所以电脑培训认为可以满足大部分的定制需求，本身kong也已经集成了相当多的插件，包括CORS跨域、logging、限流、转发、健康检查、熔断等，API聚合功能从github上看也已经进入开发阶段。

北大青鸟java培训：微服务架构中API网关的角色？

“当你想到网关的时候，你通常会想到一个集中的层，一个额外的跳在网络上处理附加的功能。

但这并不一定是真的，”Palladino上周在洛杉矶举行的2017年MesosCon上发表的讲话。

网关还可以提供一种有效的方式来处理跨微服务之间的通信。

他说：“你也可以在现有的微服务上运行Kong，摆脱额外的跳跃，减少延迟。

”在过去的10年里，湖南电脑培训认为API一直是一种受欢迎的通信交互方式，Docker使其易于设置微服务架构，其中应用程序和服务是由较小的可交换组件组成。

但这些组件之间需要一种方式进行发现与调用。

这就是API网关的作用。

API网关“可以成为一个抽象层它位于这些微服务中每个请求的访问路径上，”Palladino说道。

网关巩固了通往系统常用功能的所有路径，比如身份验证或者服务发现，通过插件都能被网关识别。

“插件是一种有效的中间件功能你能动态应用于所有的微服务上，”他讲到。

API网关可以聚合服务请求和这些特性。

客户端可以做出一个响应，网关可以将其分解为多个请求，节省了客户端自身调用的带宽。

网关同样还可以跟踪这些请求。

当一个组织开始把一个单体应用拆分为微服务时，网关可以将对客户端的影响最小化。

“网关就像装载单体应用前的一个窗帘。

客户端只会处理网关，而你可以在窗帘后面解耦你的单体应用，不必担心更新你的客户端，”他说道。

他说：“当你没掌控你的客户端的时候这个特别有用”。

传统上，API网关在组织网络的边缘上被使用，处理的流量大部分来自于单体应用和外部客户端之间的交互。

然而微服务架构将大部分的流量转移到内部网络，因为不同的微服务之间要进行交互。

“你可以有外部的客户端使用案例，但这成为了当前消费微服务的众多客户端之一。

”

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