微服务：简述微服务架构中的API网关
API网关是任何微服务架构的重要组成部分。有了它我们可以在一个独立的模块上方便的处理一些非业务逻辑，可以让微服务本身专注在自身特定的功能上，使得每个微服务的开发更容易和更快速。
一、为什么需要API网关
在我们的项目曾经还是单体应用的时候，虽然没有API网关的概念，但是在项目中都会用到filter/过滤器之类的东西，filter的作用就是把项目中的一些非业务逻辑的功能抽离出来独立处理，避免与业务逻辑混在一起增加代码复杂度。比如 鉴权认证功能、Session处理、安全检查、日志处理等等。
采用微服务架构后，在一个项目中微服务节点很多，如果让每一个节点都去处理上面这些 “鉴权认证功能、Session处理、安全检查、日志处理等” 会多出很多冗余的代码，也会给增加业务代码的复杂度，因此我们就需要有一个API网关把这些公共的功能独立出来成为一个服务来统一的处理这些事情。
API网关就像是微服务的大门守卫一样，是连通外部客户端与内部微服务之间的一个桥梁。其主要功能有：
- 路由转发
API网关是内部微服务的对外唯一入口，所以外面全部的请求都会先发到这个API网关上，然后由API网关来根据不同的请求去路由到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。并且由于内部微服务实例也会随着业务调整不停的变更，增加或者删除节点，API网关可以与服务注册模块进行协同工作，保证将外部请求转发到最合适的微服务实例上面去。 - 负载均衡
因为API网关是内部微服务的单一入口，所以API网关在收到外部请求之后，还可以根据内部微服务每个实例的负荷情况进行动态的负载均衡调节。一旦内部的某个微服务实例负载很高，甚至是不能及时响应，则API网关就通过负载均衡策略减少或停止向这个实例转发请求。当所有的内部微服务实例都处理不过来的时候，API网关还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。 - 安全认证
API网关就像是微服务的大门守卫，每一个请求进来之后，都必须先在API网关上进行身份验证，身份验证通过后才转发给后面的服务，转发的时候一般也会带上身份信息。同时API网关也需要对每一个请求进行安全性检查，例如参数的安全性、传输的安全性等等。 - 日志记录
因为所有的请求都需要走API网关，那么我们就可以在API网关上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。 - 数据转换
因为API网关对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此API网关还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。 - 协议转换
内部的API可能是由很多种不同的协议实现的，比如HTTP、Dubbo、GRPC等，但对于用户来说其中很多都不是很友好，或者根本没法对外暴露，比如Dubbo服务，因此需要在网关层做一次协议转换，将用户的HTTP协议请求，在网关层转换成底层对应的协议，比如HTTP -> Dubbo, 但这里需要注意很多问题，比如参数类型，如果类型搞错了，导致转换出问题，而日志又不够详细的话，问题会很难定位。
二、API网关的原理与市场上的成熟方案
虽然我们可以自己去开发一套API网关，但是如果没有特殊需求，还是不建议重复造轮子了，市面上有很多成熟的方案可以直接使用，下面简单介绍一下 Zuul、Tyk、Kong三个比较热门的开源组件。
2.1 Zuul
Zuul 是由 Netflix 所开源的组件，基于JAVA技术栈开发的。使用热度非常高，并且集成到了 Spring Cloud 全家桶中了，使用起来非常方便。
上图可以看到Zuul的一个简化结构，过滤器filter是整个Zuul的核心，分为前置过滤器（pre filter）、路由过滤器（routing filter）、后置过滤器（post filter）以及 错误过滤器（error filter）。
一个请求过来，会先执行所有的 pre filter，然后再通过 routing filter 将请求转发给后端服务，后端服务进行结果响应之后，再执行 post filter，最后再响应给客户端。在不同的filter里面可以执行不同的逻辑，比如安全检查、日志记录等等。
2.2 Tyk
Tyk是一个基于GO编写的，轻量级、快速可伸缩的开源的API网关。可以通过下图简单了解一下Tyk的流程原理。
2.3 Kong
Kong是基于OpenResty技术栈的开源网关服务，因此其也是基于Nginx实现的。Kong可以做到高性能、插件自定义、集群以及易于使用的Restful API管理。
