概念介绍
如果大家清楚“网关”这个概念，那就很容易理解“API网关“，即所有API的入口。 从面向对象设计的角度看，它与外观模式类似，封装了系统内部架构。在单体应用架构中，没有「 API网关 」的概念，每个项目都会用到filter/过滤器之类的东西，filter的作用就是把项目中的一些非业务逻辑的功能抽离出来独立处理，避免与业务逻辑混在一起增加代码复杂度。比如 鉴权认证功能、Session处理、安全检查、日志处理等等。
如果采用微服务架构，那一个项目中微服务节点很多，如果让每一个节点都去处理上面这些 “鉴权认证功能、Session处理、安全检查、日志处理等” 会多出很多冗余的代码，也会给增加业务代码的复杂度，因此就需要有一个API网关把这些公共的功能独立出来成为一个服务来统一的处理这些事情。
主要功能
API网关就像是微服务的一扇门，是连通外部客户端与内部微服务之间的一个桥梁。
其主要功能有：
- 路由转发 API网关是内部微服务的对外唯一入口，所以外面全部的请求都会先发到API网上，然后由API网关来根据不同的请求去路由到不同的微服务节点上。
- 负载均衡 API网关收到外部请求之后，可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高，甚至是不能及时响应，则API网关就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候，API网关还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。
- 安全认证 API网关就像是微服务的大门守卫，每一个请求进来之后，都必须先在API网关上进行安全验证或身份验证，验证通过后才转发给后面的服务。
- 日志记录 所有的请求都需要走API网关，那么就可以在API网关上统一集中的记录下这些行为日志。
- 数据转换 因为API网关对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此API网关还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。
OpenResty
API网关最主要的功能实现就是请求拦截，在网络请求的整个生命阶段加入各种filter/过滤器, OpenResty提供了这样的功能。
OpenResty® 是一个基于 Nginx 与 Lua 的高性能 Web 平台，其内部集成了大量精良的 Lua 库、第三方模块以及大多数的依赖项。用于方便地搭建能够处理超高并发、扩展性极高的动态 Web 应用、Web 服务和动态网关。
OpenResty 处理一个请求，它的处理流程请参考下图(从 Request start 开始)：
依据OpenResty的请求处理流程，和各种第三方模块，就可以在流程节点中加入我们的API网关逻辑代码。例如，对API请求数量进行统计：
lua_package_path "module/lua-resty-hmac/lib/?.lua;module/lua-resty-redis/lib/?.lua;module/lua-resty-mysql/lib/?.lua;module/lua-resty-jwt/lib/?.lua;;";server { listen 80; server_name gw.gitlib.cn; access_log /var/log/nginx/gw.gitlib.cn.access.log access; # lua_code_cache off; set $redis_host "192.168.1.106"; set $redis_port "6379"; set $redis_incrkey "api:access:num"; access_by_lua_file gateway/intercept.lua; # 对所有请求进行拦截处理 location = /num { content_by_lua_block { local _redis = require "resty.redis" local redis = _redis:new() redis:set_timeout(1000) local ok, err = redis:connect(ngx.var.redis_host, ngx.var.redis_port) if not ok then ngx.say("failed to connect: 
