为什么做微服务的需要「API网关」呢？「API网关」到底有些啥功能呢？我们以前项目结构比较简单的时候有用到过「API网关」概念的模块吗？
实际上，当我们的项目是单个应用程序时，尽管没有“API网关”的概念，但是项目中通常使用filter/过滤器之类的东西。过滤器的功能是抽离一些非业务逻辑功能，并将这些功能是独立处理的，以避免与业务逻辑混合以增加代码复杂性。例如，身份验证功能，Session处理，安全性检查，日志处理等。
现在，我们采用了微服务架构。一个项目中有许多微服务节点。如果要求每个节点处理上述“身份验证和身份验证功能，会话处理，安全检查，日志处理等”，则将有很多冗余的代码。该代码会增加业务代码的复杂性，因此我们需要一个“API网关”将这些公共功能分离为一个服务，以统一方式处理这些事情。
我们看一下下面这个微服务架构示意图：
其主要功能有：
路由转发
之前说了「API网关」是内部微服务的对外唯一入口，所以外面全部的请求都会先发到这个「API网关」上，然后由「API网关」来根据不同的请求去路由到不同的微服务节点上。例如可以根据路径来转发、也可以根据参数来转发。
并且由于内部微服务实例也会随着业务调整不停的变更，增加或者删除节点，「API网关」可以与「服务注册」模块进行协同工作，保证将外部请求转发到最合适的微服务实例上面去。
负载均衡
由于“API网关”是内部微服务的单个入口点，因此在接收到外部请求之后，“API网关”还可以根据内部微服务的每个实例的负载来执行动态负载平衡调整。一旦内部微服务实例具有较高的负载，甚至无法及时响应，“API网关”将通过负载平衡策略减少或停止将请求转发到该实例。当无法处理所有内部微服务实例时，“API网关”还可以采用限流或熔断的形式阻止外部请求，以保障整个系统的可用性。
安全认证
「API网关」就像是微服务的大门守卫，每一个请求进来之后，都必须先在「API网关」上进行身份验证，身份验证通过后才转发给后面的服务，转发的时候一般也会带上身份信息。
同时「API网关」也需要对每一个请求进行安全性检查，例如参数的安全性、传输的安全性等等。
日志记录
既然所有的请求都需要走「API网关」，那么我们就可以在「API网关」上统一集中的记录下这些行为日志。这些日志既可以作为我们后续事件查询使用，也可以作为系统的性能监控使用。
数据转换
因为「API网关」对外是面向多种不同的客户端，不同的客户端所传输的数据类型可能是不一样的。因此「API网关」还需要具备数据转换的功能，将不同客户端传输进来的数据转换成同一种类型再转发给内部微服务上，这样，兼容了这些请求的多样性，保证了微服务的灵活性。
