① 开源API网关系统（Kong教程）入门到精通
1、Kong的简介和安装
2、使用Docker安装Kong
3、开源API网关：KONG入门培训
1、配置详解
2、代理详解
3、身份验证详解
4、负载均衡详解
5、健康检查和断路器详解
6、集群详解
7、网络与防火墙详解
8、共有Lua API详解
9、管理API安全保护详解
一、身份验证郑腔扒插件
1、Basic验证
2、Key验证
3、OAuth2.0验证
二、权限安全插件
1、ACL鉴权
2、动态SSL
3、IP限制（黑白名单）
4、爬虫控制
三、流量控制插件
1、请求大小限制
2、请求速率限制
3、请求终止
四、Serverless插件
1、Serverless功能
五、分析与监控插件
1、Zipkin
六、数据转换插件
就是请求，和返回的时候加喊昌减点数据。
七、日志插件
日志插件发送目标包括圆搜：TCP、UDP、HTTP、FILE、STATSD、SYSLOG 等，比较简单，自己找资料看看
1、玩转SERVICE服务
2、玩转ROUTE路由
3、玩转API对象 （不推荐）
4、玩转CONSUMER消费者
1、Kong整合Consul 附： Consul快速入门
2、Kong整合Spring Security实现OAuth2.0验证
3、实现Kong的Java管理API
② API网关从入门到放弃
假设你正在开发一个电商网站，那么这里会涉及到很多后端的微服务，比如会员、商品、推荐服务等等。
那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务? 如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:
更好的方式是采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展，比如鉴权、限流、权限、熔断、协议转换、错误码统一、缓存、日志、监控、告警等，这样将通用的逻辑抽出来，由网关统一去做，业务方也能够更专注于业务逻辑，提升迭代的效率。
通过引入API网关，客户端只需要与API网关交互，而不用与各个业务方的接口分别通讯，但多引入一个组件就多引入了一个潜在的故障点，因此要实现一个高性能、稳定的网关，也会涉及到很多点。
API 注册
业务方如何接入网关?一般来说有几种方式。
协议转换
内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位。
服务发现
网关作为流量的入口，负责请求的转发，但首先需要知道转发给谁，如何寻址，这里有几种方式:
服务调用
网关由于对接很多种不同的协议，因此可能需要实现很多种调用方式，比如HTTP、Dubbo等，基于性能原因，最好都采用异步的方式，而Http、Dubbo都是支持异步的，比如apache就提供了基于NIO实现的异步HTTP客户端。
因为网关会涉及到很多异步调用，比如拦截器、HTTP客户端、bbo、redis等，因此需要考虑下异步调用的方式，如果基于回调或者future的话，代码嵌套会很深，可读性很差，可以参考zuul和spring cloud gateway的方案，基于响应式进行改造。
优雅下线
性能
网关作为所有流量的入口，性能是重中之重，早期大部分网关都是基于同步阻塞模型构建的，比如Zuul 1.x。但这种同步的模型我们都知道，每个请求/连接都会占用一个线程，而线程在JVM中是一个很重的资源，比如Tomcat默认就是200个线程，如果网关隔离没有做好的话，当发生网络延迟、FullGC、第三方服务慢等情况造成上游服务延迟时，线程池很容易会被打满，造成新的请求被拒绝，但这个时候其实线程都阻塞在IO上，系统的资源被没有得到充分的利用。另外一点，容易受网络、磁盘IO等延迟影响。需要谨慎设置超时时间，如果设置不当，且服务隔离做的不是很完善的话，网关很容易被一个慢接口拖垮。
而异步化的方式则完全不同，通常情况下一个CPU核启动一个线程即可处理所有的请求、响应。一个请求的生命周期不再固定于一个线程，而是会分成不同的阶段交由不同的线程池处理，系统的资源能够得到更充分的利用。而且因为线程不再被某一个连接独占，一个连接所占用的系统资源也会低得多，只是一个文件描述符加上几个监听器等，而在阻塞模型中，每条连接都会独占一个线程，而线程是一个非常重的资源。对于上游服务的延迟情况，也能够得到很大的缓解，因为在阻塞模型中，慢请求会独占一个线程资源，而异步化之后，因为单条连接所占用的资源变的非常低，系统可以同时处理大量的请求。
如果是JVM平台，Zuul 2、Spring Cloud gateway等都是不错的异步网关选型，另外也可以基于Netty、Spring Boot2.x的webflux、vert.x或者servlet3.1的异步支持进行自研。
缓存
对于一些幂等的get请求，可以在网关层面根据业务方指定的缓存头做一层缓存，存储到Redis等二级缓存中，这样一些重复的请求，可以在网关层直接处理，而不用打到业务线，降低业务方的压力，另外如果业务方节点挂掉，网关也能够返回自身的缓存。
限流
限流对于每个业务组件来说，可以说都是一个必须的组件，如果限流做不好的话，当请求量突增时，很容易导致业务方的服务挂掉，比如双11、双12等大促时，接口的请求量是平时的数倍，如果没有评估好容量，又没有做限流的话，很容易服务整个不可用，因此需要根据业务方接口的处理能力，做好限流策略，相信大家都见过淘宝、网络抢红包时的降级页面。
因此一定要在接入层做好限流策略，对于非核心接口可以直接将降级掉，保障核心服务的可用性，对于核心接口，需要根据压测时得到的接口容量，制定对应的限流策略。限流又分为几种:
稳定性
稳定性是网关非常重要的一环，监控、告警需要做的很完善才可以，比如接口调用量、响应时间、异常、错误码、成功率等相关的监控告警，还有线程池相关的一些，比如活跃线程数、队列积压等，还有些系统层面的，比如CPU、内存、FullGC这些基本的。
网关是所有服务的入口，对于网关的稳定性的要求相对于其他服务会更高，最好能够一直稳定的运行，尽量少重启，但当新增功能、或者加日志排查问题时，不可避免的需要重新发布，因此可以参考zuul的方式，将所有的核心功能都基于不同的拦截器实现，拦截器的代码采用Groovy编写，存储到数据库中，支持动态加载、编译、运行，这样在出了问题的时候能够第一时间定位并解决，并且如果网关需要开发新功能，只需要增加新的拦截器，并动态添加到网关即可，不需要重新发布。
熔断降级
熔断机制也是非常重要的一项。若某一个服务挂掉、接口响应严重超时等发生，则可能整个网关都被一个接口拖垮，因此需要增加熔断降级，当发生特定异常的时候，对接口降级由网关直接返回，可以基于Hystrix或者Resilience4j实现。
日志
由于所有的请求都是由网关处理的，因此日志也需要相对比较完善，比如接口的耗时、请求方式、请求IP、请求参数、响应参数(注意脱敏)等，另外由于可能涉及到很多微服务，因此需要提供一个统一的traceId方便关联所有的日志，可以将这个traceId置于响应头中，方便排查问题。
隔离
比如线程池、http连接池、redis等应用层面的隔离，另外也可以根据业务场景，将核心业务部署带单独的网关集群，与其他非核心业务隔离开。
网关管控平台
这块也是非常重要的一环，需要考虑好整个流程的用户体验，比如接入到网关的这个流程，能不能尽量简化、智能，比如如果是bbo接口，我们可以通过到git仓库中获取源码、解析对应的类、方法，从而实现自动填充，尽量帮用户减少操作；另外接口一般是从测试->预发->线上，如果每次都要填写一遍表单会非常麻烦，我们能不能自动把这个事情做掉，另外如果网关部署到了多个可用区、甚至不同的国家，那这个时候，我们还需要接口数据同步功能，不然用户需要到每个后台都操作一遍，非常麻烦。
这块个人的建议是直接参考阿里云、aws等提供的网关服务即可，功能非常全面。
其他
其他还有些需要考虑到的点，比如接口mock，文档生成、sdk代码生成、错误码统一、服务治理相关的等，这里就不累述了。
目前的网关还是中心化的架构，所有的请求都需要走一次网关，因此当大促或者流量突增时，网关可能会成为性能的瓶颈，而且当网关接入的大量接口的时候，做好流量评估也不是一项容易的工作，每次大促前都需要跟业务方一起针对接口做压测，评估出大致的容量，并对网关进行扩容，而且网关是所有流量的入口，所有的请求都是由网关处理，要想准确的评估出容量很复杂。可以参考目前比较流行的ServiceMesh，采用去中心化的方案，将网关的逻辑下沉到sidecar中，
sidecar和应用部署到同一个节点，并接管应用流入、流出的流量，这样大促时，只需要对相关的业务压测，并针对性扩容即可，另外升级也会更平滑，中心化的网关，即使灰度发布，但是理论上所有业务方的流量都会流入到新版本的网关，如果出了问题，会影响到所有的业务，但这种去中心化的方式，可以先针对非核心业务升级，观察一段时间没问题后，再全量推上线。另外ServiceMesh的方案，对于多语言支持也更友好。
③ 使用netty构建API网关实践之路
随着互联网的快速发展，当前以步入移动互联、物联网时代。用户访问系统入口也变得多种方式，由原来单一的PC客户端，变化到PC客户端、各种厅派浏览器、手机移动端及智能终端等。同时系统之间大部分都不是单独运行，经常会涉及与其他系统对接、共享数据的需求。所以系统需要升级框架满足日新月异需求变化，支持业务发展，并将框架升级为微服务架构。“API网关”核心组件是架构用于满足此些需求
很多互联网平台已基于网关的设计思路，构建自身平台的API网关，国内主要有京东、携程、唯品会等，国外主要有Netflix、Amazon等。
业界为了满足这些需求，已有相关的网关框架。
1、基于nginx平台实现的网关有：kong、umbrella等
2、自研发的网关有：zuul1、zuul2等
但是以上网关框架只能是满足部分需求，不能满足企业的所有要求，就我而言，我认为最大的问题是没有协议转换及OPS管理控制平台
另外：对于微服务架构下，如果基于HTTP REST传输协议，API网关还承担了一个内外API甄别的功能，只有在API网关上注册了的API还能是真正的堆外API
整个网关系统由扮兆三个子系统组成：
说明：
1） 整个网关基于Netty NIO来实现同步非阻塞是HTTP服务，网关是外部API请求的HTTP服务端，同时是内部服务的客户端，所以有Netty Server Handler和Netty Client Handler的出现；
2）对于Netty Server Handler来说，当一个HTTP请求进来时，他会把当前连接转化为ClientToProxyConnection，它是线程安全的，伴随当前此HTTP请求的生命周期结束，它也负责ClientToProxyConnection的生命周期的维护；
3）对于Netty Client Handler来说，当ClientToProxyConnection需要传递请求到内部服务时，会新建(或者获取扮缺贺原来已建)的ProxyToServerConnection来进行内部的请求，它也是线程安全的；
4）对于Filter来说，他运行在ClientToProxyConnection上，插入请求进来及收到后端请求之间；
从以上分析，网关选择同步非阻塞方式是一个合适的选择
其中转化的过程如下：
2：根据FileDescriptorSet获取gRPC的入参和出参描述符，然后再创建gRPC所需要的MethodDescriptor方法描述对象
2） HTTP ----> bbo
在bbo的框架设计中，其中已经包含了泛化调用的设计，所以在这块，基本上就延用了bbo的泛化调用来实现http转bbo的协议，而关于bbo的参数部分，可以指定参数映射规范，利用参数裁剪的技术对http请求参数进行抽取，如果bbo的接口是java类型，则直接抽取，如果是pojo，按照bbo的用户文档，把他组成一个Map的数据结构即可，而操作这一步需要映射规则
整个网关目前基本完成并且也开源到GitHub上，欢迎拍砖及使用
tesla
④ 关于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好用，感兴趣的同学可以自行去了解一下。
www.eolinker.com
⑤ 阿里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=value1&key2=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 网关做服务编排
服务编排/数据聚合 指的是可以通过一个请求来依次调用多个微服务，并对每个服务的返回结果做数据处理，最终整合成一个大的结果返回给前端。
例如一个服务是“查询用户预定的酒店”，前端仅需要传一个订单ID，后端会返回整个订单的信息，包括用户信息、酒店信息和房间信息等。
这个服务背后可能对应着以下几个操作：
微服务架构上对功能做了解耦，使用服务编排可以快速从各类服务上获取需要的数据，对业务实现快速响扒毕应。总的来说，编排有以下几点优势：
Goku API Gateway （中文名：悟空 API 网关）是一个基于 Golang 开发的微服务网关，能够实现高性能 HTTP API 转发、服务编排、多租户管理、API 访问权限控制等目的，拥有强大的自定义插件系统可以自行扩展，并且提供友好的图形化配置界面，能够丛念快速帮助企业进行 API 服务治理、提高 API 服务的稳定性和安全性。
Goku API Gateway支持一个编排API对应多个后端服务，每个后端服务的请求参数可以使用前端传入的参数，也可以在编排里自定义（写静态参数或从返回数据里获得）。每个后端服务的返回数据支持过滤、删除、移动、重命名、拆包和封包等操作；编排API能够设定编排失败时的异常返回。
Goku API Gateway 的社区版本（CE）同时拥有完善的使用指南和二次开发指南，内置的插件系统也能够让企业针对自身业务进行定制开发。
项目地址： https://github.com/eolinker/goku-api-gateway
官网地址： https://www.eolinker.com
我们将编排的整个操作渗此困放到网关进行，由网关对数据做处理与转换，这样无需对后端服务做改动。一个请求到达网关，网关调用多个后端服务，并且在网关上对各个服务的返回数据做处理（操作有过滤、移动、重命名、封包、拆包，后面会对各操作做详细解释），最后由网关将数据整合好返回给前端。
网关将编排过程中对 API的转发处理过程 （转发->获取返回数据->数据处理）称为一个 Step 。
添加一个转发服务，该服务为 查询订单详情API，配置相应的转发地址、传入的参数、对返回数据做何种处理等。
由于篇幅原因，后续的Step（查询用户详情、查询酒店详情、查询房间详情）就不一一展示了。
网关将编排过程中对 API的转发处理过程 （转发->获取返回数据->数据处理）称为一个 Step。
我们将处理查询订单详情API称为 Step1 ，其中Step1的返回数据有：用户ID、酒店ID、房间ID。同理，将查询用户信息这步称为 Step2 ，将查询酒店信息称为 Step3 ，将查询房间信息称为 Step4 。
传参规则：
以下为转发路径的传参写法：
Step2中需要接收Step1里返回的userID作为参数，同时需要接收前端传入的Authorization参数
在网关里Step2的请求参数配置如下所示，请求参数存在多个的话用换行表示：
1.查询订单详情的API，返回数据称为json1，内容如下：
2.查询用户详情的API，返回数据称为json2，内容如下：
3.查询酒店详情的返回数据，称为json3，内容如下：
4.查询房间详情的返回数据，称为json4，内容如下：
5.可以在每一个Step里对返回Json做处理，网关会将处理过的数据最后整合起来，再返回前端，例如这是通过网关返回的最终数据：
这里以查询酒店详情API的返回数据json3为例，讲解网关如何在编排过程中对返回数据做处理。
查询酒店详情API返回的原始数据如下：
从网关返回给前端的数据中截取酒店信息的数据如下：
从原始数据到处理后的数据需要经过以下操作：
字段黑名单的作用是排除某些字段，支持数组形式。
在网关的Step3里配置如下：
经过网关处理后，实际的返回数据如下，可以看到data对象里的id字段已经被过滤掉：
拆包是指将指定对象的内容提取出来作为该步骤（step）的返回结果。其中匹配目标只能为object，匹配目标为空时，结果为 {}，可用于清除数据。
在网关的Step里配置如下：
经过网关处理后，实际的返回数据如下，可以看到data对象被拆开，最终数据仅保留了data对象里面的字段：
字段封包会将当前的数据整体打包为最终返回数据中的一个对象，不支持*，不支持数组。
在网关的Step里配置如下：
经过网关处理后，实际的返回数据如下，数据被整体打包为hotelinfo对象：
经过三个步骤，就可以将原始数据变成最终的数据。
本文仅列举了编排过程中部分数据处理的操作，如需了解更多编排细则，可通过文末给出的教程链接。
相关链接
⑦ API网关设置基础知识
如果大家了解网络构成的话，对于网关应该就不会陌生了，今天我们就一起来了解一下，API网关的一些基础知识，希望对大家以后的服务器开发工作有所帮助，下面就开始今天的主要内容吧。
一、API网关产生背景
在微服务的架构中，一个大的应用会被拆分成多个小的单一的服务提供出来，这些小的服务有自己的处理，有自己的数据库(也可以共用)，也许语言也是不一样的，他们可以部署在一个或多个服务器上，其实也就是对复杂的应用进行了解耦，那为什么微服务需要API网关呢?
我们看看微服务后产生的问题：
客户枯罩锋端需要知道多个没晌服务地址
通用的功能怎么处理?例如鉴权、流量控制、日志等
以前一个功能可能是一次请求就可以完成，现在可能要多个服务一起进行才可以，那如何减少客户端请求的时间呢?
由于闷汪以上几点的问题，所以在所有的服务前面还需要定义一个代理，即API网关，所有的客户端请求都必须经过API网关代理到真实的服务地址，这也可以有效的避免真实地址的暴露，同时API网关也可以集成鉴权、流量控制、日志、API聚合、黑白名单等。
二、kong的介绍
Kong是由Mashape开发的并且于2023年开源的一款API网关框架，基于nginx以及OpenResty研发，主要特点是高性能以及其强大的扩展性，由于本身是基于nginx进行开发，因此网上很多关于nginx的调优等资料都可以用到kong的上面，包括负载均衡、或者充当web服务器等
kong的扩展是通过插件机制进行的，并且也提供了插件的定制示例方法，插件定义了一个请求从进入到反馈到客户端的整个生命周期，所以电脑培训认为可以满足大部分的定制需求，本身kong也已经集成了相当多的插件，包括CORS跨域、logging、限流、转发、健康检查、熔断等，API聚合功能从github上看也已经进入开发阶段。
⑧ “微服务架构”部署NGINX Plus作为API网关，第1部分 - NGINX
了解着名的Nginx服务器（微服务必不可少的东西）如何用作API网关。
现代应用程序体系结构的核心是HTTP API。 HTTP使应用程序能够快速构建并轻松维护。无论应用程序的规模如何，HTTP API都提供了一个通用接口，从单用途微服务到无所不包的整体。通过使用HTTP，支持超大规模Internet属性的Web应用程序交付的进步也可用于提供可靠和高性能的API交付。
有关API网关对微服务应用程序重要性的精彩介绍，请参阅我们博客上的构建微服务：使用API网关。
作为领先的高性能，轻量级反向代理和负载均衡器，NGINX Plus具有处理API流量所需的高级HTTP处理功能。这使得NGINX Plus成为构建API网关的理想平台。在这篇博文中，我们描述了许多常见的API网关用例，并展示了如何配置NGINX Plus以便以高效，可扩展且易于维护的方式处理它们。我们描述了一个完整的配置，它可以构成生产部署的基础。
注意：除非另有说明，否则本文中的所有信息均适用于NGINX Plus和NGINX开源。
API网关的主要功能是为多个API提供单一，一致的入口点，无论它们在后端如何实现或部署。并非所有API都是微服务应用程序。我们的API网关需要管理现有的API，单块和正在部分过渡到微服务的应用程序。
在这篇博文中，我们引用了一个假设的库存管理API，即“仓库API”。我们使用示例配置代码来说明不同的用例。 Warehouse API是一个RESTful API，它使用JSON请求并生成JSON响应。但是，当部署为API网关时，使用JSON不是NGINX Plus的限制或要求; NGINX Plus与API本身使用的架构风格和数据格式无关。
Warehouse API实现为离散微服务的集合，并作为单个API发布。库存和定价资源作为单独的服务实施，并部署到不同的后端。所以API的路径结构是：
例如，要查询当前仓库库存，客户端应用程序会向/ api / warehouse / inventory发出HTTP GET请求。
使用NGINX Plus作为API网关的一个优点是，它可以执行该角色，同时充当现有HTTP流量的反向代理，负载平衡器和Web服务器。如果NGINX Plus已经是应用程序交付堆栈的一部分，那么通常不需要部署单独的API网关。但是，API网关所期望的某些默认行为与基于浏览器的流量的预期不同。出于这个原因，我们将API网关配置与基于浏览器的流量的任何现有（或未来）配置分开。
为实现这种分离，我们创建了一个支持多用途NGINX Plus实例的配置布局，并为通过CI / CD管道自动配置部署提供了便利的结构。 / etc / nginx下的结果目录结构如下所示。
所有API网关配置的目录和文件名都以api_为前缀。这些文件和目录中的每一个都启用API网关的不同特性和功能，并在下面详细说明。
所有NGINX配置都以主配置文件nginx.conf开头。要读入API网关配置，我们在nginx.conf的http块中添加一个指令，该指令引用包含网关配置的文件api_gateway.conf（下面的第28行）。请注意，默认的nginx.conf文件使用include伪指令从conf.d子目录中引入基于浏览器的HTTP配置（第29行）。本博文广泛使用include指令来提高可读性并实现配置某些部分的自动化。
api_gateway.conf文件定义了将NGINX Plus公开为客户端的API网关的虚拟服务器。此配置公开API网关在单个入口点https://api.example.com/（第13行）发布的所有API，受第16到21行配置的TLS保护。请注意，此配置纯粹是HTTPS - 没有明文HTTP侦听器。我们希望API客户端知道正确的入口点并默认进行HTTPS连接。
此配置是静态的 - 各个API及其后端服务的详细信息在第24行的include伪指令引用的文件中指定。第27到30行处理日志记录默认值和错误处理，并在响应中讨论错误部分如下。
一些API可以在单个后端实现，但是出于弹性或负载平衡的原因，我们通常期望存在多个API。使用微服务API，我们为每个服务定义单独的后端;它们一起作为完整的API。在这里，我们的Warehouse API被部署为两个独立的服务，每个服务都有多个后端。
API网关发布的所有API的所有后端API服务都在api_backends.conf中定义。这里我们在每个块中使用多个IP地址 - 端口对来指示API代码的部署位置，但也可以使用主机名。 NGINX Plus订户还可以利用动态DNS负载平衡，自动将新后端添加到运行时配置中。
配置的这一部分首先定义Warehouse API的有效URI，然后定义用于处理对Warehouse API的请求的公共策略。
Warehouse API定义了许多块。 NGINX Plus具有高效灵活的系统，可将请求URI与配置的一部分进行匹配。通常，请求由最具体的路径前缀匹配，并且位置指令的顺序并不重要。这里，在第3行和第8行，我们定义了两个路径前缀。在每种情况下，$ upstream变量都设置为上游块的名称，该上游块分别代表库存和定价服务的后端API服务。
此配置的目标是将API定义与管理API交付方式的策略分开。为此，我们最小化了API定义部分中显示的配置。在为每个位置确定适当的上游组之后，我们停止处理并使用指令来查找API的策略（第10行）。
使用重写指令将处理移至API策略部分
重写指令的结果是NGINX Plus搜索匹配以/ _warehouse开头的URI的位置块。第15行的位置块使用=修饰符执行完全匹配，从而加快处理速度。
在这个阶段，我们的政策部分非常简单。位置块本身标记为第16行，这意味着客户端无法直接向它发出请求。重新定义$ api_name变量以匹配API的名称，以便它在日志文件中正确显示。最后，请求被代理到API定义部分中指定的上游组，使用$ request_uri变量 - 其中包含原始请求URI，未经修改。
API定义有两种方法 - 广泛而精确。每种API最合适的方法取决于API的安全要求以及后端服务是否需要处理无效的URI。
在warehouse_api_simple.conf中，我们通过在第3行和第8行定义URI前缀来使用Warehouse API的广泛方法。这意味着以任一前缀开头的任何URI都代理到相应的后端服务。使用基于前缀的位置匹配，对以下URI的API请求都是有效的：
如果唯一的考虑是将每个请求代理到正确的后端服务，则广泛的方法提供最快的处理和最紧凑的配置。另一方面，精确的方法使API网关能够通过显式定义每个可用API资源的URI路径来理解API的完整URI空间。采用精确的方法，Warehouse API的以下配置使用精确匹配（=）和正则表达式（〜）的组合来定义每个URI。
此配置更详细，但更准确地描述了后端服务实现的资源。这具有保护后端服务免于格式错误的客户端请求的优点，代价是正常表达式匹配的一些小额外开销。有了这个配置，NGINX Plus接受一些URI并拒绝其他URI无效：
使用精确的API定义，现有的API文档格式可以驱动API网关的配置。可以从OpenAPI规范（以前称为Swagger）自动化NGINX Plus API定义。此博客文章的Gists中提供了用于此目的的示例脚本。
随着API的发展，有时会发生需要更新客户端的重大更改。一个这样的示例是重命名或移动API资源。与Web浏览器不同，API网关无法向其客户端发送命名新位置的重定向（代码301）。幸运的是，当修改API客户端不切实际时，我们可以动态地重写客户端请求。
在下面的示例中，我们可以在第3行看到定价服务以前是作为库存服务的一部分实现的：rewrite指令将对旧定价资源的请求转换为新的定价服务。
动态重写URI意味着当我们最终在第26行代理请求时，我们不能再使用$ request_uri变量（正如我们在warehouse_api_simple.conf的第21行所做的那样）。这意味着我们需要在API定义部分的第9行和第14行使用稍微不同的重写指令，以便在处理切换到策略部分时保留URI。
HTTP API和基于浏览器的流量之间的主要区别之一是如何将错误传达给客户端。当NGINX Plus作为API网关部署时，我们将其配置为以最适合API客户端的方式返回错误。
顶级API网关配置包括一个定义如何处理错误响应的部分。
第27行的指令指定当请求与任何API定义都不匹配时，NGINX Plus会返回错误而不是默认错误。此（可选）行为要求API客户端仅向API文档中包含的有效URI发出请求，并防止未经授权的客户端发现通过API网关发布的API的URI结构。
第28行指的是后端服务本身产生的错误。未处理的异常可能包含我们不希望发送到客户端的堆栈跟踪或其他敏感数据。此配置通过向客户端发送标准化错误来进一步提供保护。
完整的错误响应列表在第29行的include伪指令引用的单独配置文件中定义，其前几行如下所示。如果首选不同的错误格式，并且通过更改第30行上的default_type值以匹配，则可以修改此文件。您还可以在每个API的策略部分中使用单独的include指令来定义一组覆盖默认值的错误响应。
有了这种配置，客户端对无效URI的请求就会收到以下响应。
在没有某种形式的身份验证的情况下发布API以保护它们是不常见的。 NGINX Plus提供了几种保护API和验证API客户端的方法。有关基于IP地址的访问控制列表（ACL），数字证书身份验证和HTTP基本身份验证的信息，请参阅文档。在这里，我们专注于API特定的身份验证方法。
API密钥身份验证
API密钥是客户端和API网关已知的共享密钥。它们本质上是作为长期凭证发布给API客户端的长而复杂的密码。创建API密钥很简单 - 只需编码一个随机数，如本例所示。
在顶级API网关配置文件api_gateway.conf的第6行，我们包含一个名为api_keys.conf的文件，其中包含每个API客户端的API密钥，由客户端名称或其他描述标识。
API密钥在块中定义。 map指令有两个参数。第一个定义了API密钥的位置，在本例中是在$ http_apikey变量中捕获的客户端请求的apikey HTTP头。第二个参数创建一个新变量（$ api_client_name）并将其设置为第一个参数与键匹配的行上的第二个参数的值。
例如，当客户端提供API密钥7B5zIqmRGXmrJTFmKa99vcit时，$ api_client_name变量设置为client_one。此变量可用于检查经过身份验证的客户端，并包含在日志条目中以进行更详细的审核。
地图块的格式很简单，易于集成到自动化工作流程中，从现有的凭证存储生成api_keys.conf文件。 API密钥身份验证由每个API的策略部分强制执行。
客户端应在apikey HTTP头中显示其API密钥。如果此标头丢失或为空（第20行），我们发送401响应以告知客户端需要进行身份验证。第23行处理API键与地图块中的任何键都不匹配的情况 - 在这种情况下，api_keys.conf第2行的默认参数将$ api_client_name设置为空字符串 - 我们发送403响应告诉身份验证失败的客户端。
有了这个配置，Warehouse API现在可以实现API密钥身份验证。
JWT身份验证
JSON Web令牌（JWT）越来越多地用于API身份验证。原生JWT支持是NGINX Plus独有的，可以在我们的博客上验证JWT，如使用JWT和NGINX Plus验证API客户端中所述。
本系列的第一篇博客详细介绍了将NGINX Plus部署为API网关的完整解决方案。可以从我们的GitHub Gist仓库查看和下载此博客中讨论的完整文件集。本系列的下一篇博客将探讨更高级的用例，以保护后端服务免受恶意或行为不端的客户端的攻击。
原文：https://dzone.com/articles/deploying-nginx-plus-as-an-api-gateway-part-1-ngin
本文：http://pub.intelligentx.net/deploying-nginx-plus-api-gateway-part-1-nginx
讨论：请加入知识星球或者小红圈【首席架构师圈】
⑨ 阿里云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 的重要程度来配置不同流控，从而保障重要业务的稳定运行。
支持用户、应用和例外流控，您可以根据用户的重要性来配置不同流控，从而可以保证大用户的权益。
流控粒度：分钟、小时、天。
请求管理 （通过参数校验过滤无效请求，通过参数转换实现 API 高度复用，一套 API 多种服务）
参数校验：请求经过 API 网关，可根据您的配置进行参数类型、参数值（范围、枚举、正则、Json Schema）的校验，减少后端对非法请求、无效请求的资源消耗和处理成本。
参数转换：您可以在 API 网关定义参数映射规则，网关通过映射规则将后端服务通过映射翻译成任何形式，以满足不同用户的不同需求，从而避免功能重复开发。
监控告警 （结合阿里云监控服务，提供灵活全面的监控告警能力，该部分持续升级中）
监控告警：提供实时、可视化的 API 监控，包括：调用量、调用方式、响应时间、错误率，让您能够清楚的了解 API 的运行状况和用户的圆悉行为习惯。
支持自定义报警规则，来针对异常情况进行报警，降低故障处理时间。
API 市场 （一站式解决 API 管理和 API 变现）
API 市场：API 接入 API 网关后，还能以 API 服务的方式上架到阿里云 API 市场。API 网关和API 市场将为您解决计量计费、Quota 控制、运营售卖等需求。
⑩ API网关express-gateway初体验
昨天朋友发来一个消息，问我express源码中的一个问题，我去看了一番源码以后，发现自己并不是很懂，只能看懂一些字面意思...
不过在聊天过程中，了解到他们公司在用express做api网关，什么是api网关呢？
我将以express-gateway为例，学习 get started教程 ，对api网关进行探索。
安装
①npm i -g express-gateway
②创建一个express网关：eg gateway create
③根据提示选择server模板
④运行express网关：npm start
5分钟入门教程
目标：
1.选择一个微服务并且作为一个api暴露出去
2.定义一个api的消费者
3.使用key认证保证api的安全性
1.选择一个微服务并且作为一个api暴露出去
①直接访问微服务
curl http://httpbin.org/ip
②指定微服务
在express gateway的一个默认的管道中，服务将被分配到一个端口。一个管道指的是一个策略集合。Express Gateway有一个代理策略。在默认的管道中，会使用这个代理策略，网关现在挡在了 https://httpbin.org/ip 服务前面，并且并且路由其它请求到网关的端口。
在config/gateway.config.yml这个文件中，可以找到一个serviceEndpoints选项，这里定义了httpbin这个服务。
在默认管道的proxy选项的action中，可以找到serviceEndpoint: httpbin
③以api的方式公开微服务
通过Express Gateway，我们将暴露httpbin 服务到api端口。当通过api端口公开api后，外部可以访问到api。
在config/gateway.config.yml这个文件中，可以找到apiEndpoints选项，这里定义了api。
现在我们有一个公共api浮出水面了，我们应该确保自己可以穿过express网关获取到service的权限。
2.定义一个api网关的消费者
管理我们api的人，在这里我们称之为“Consumer”。
eg users create
3.使用key认证方式确保安全
①现在api暴露了出去，而且也获得了访问权限。我们现在将为其加上key安全认证。
在config/gateway.config.yml这个文件中，可以找到pipelines选项，这里定义了key-auth。
②为Consumer Bob分配key。
eg credentials create -c bob -t key-auth -q
③Bob没有加key直接访问。
④Bob加了key进行访问。
That's it!