微服务去中心化架构下为何还要用API网关

 

今天准备再谈下API网关，发现很多人对去中心化的微服务架构下为何还要用API网关本身存在诸多的疑惑，因此准备在对一些关键的问题点进行说明。

微服务架构下API网关的位置

 

上图是一个标准的基于SpringCLoud的微服务架构体系图，在图中可以明确的看到API网关或微服务网关所处的位置，即前面谈到过的API网关的定义。

即API网关是内部微服务的统一对外出口，所有需要外部的应用或APP访问的接口都通过API网关暴露一个统一的地址给外部使用。

因此API网关最基本的作用首先是要实现一次接口服务的代理，实现内部的微服务对外界透明。否则所有的内部微服务将全部暴露给外部应用，这个风险是相当大的。

如果仅仅是实现接口转发，那么Ngnix反向代理也可以完全实现，因此当前架构也可以看到很多的微服务架构体系并没有采用API网关。

微服务注册和微服务API接口注册

 

在微服务架构里面的注册一定要将微服务注册和微服务API接口注册两个概念分开。

微服务注册中心只到微服务模块级注册，而API网关可以到API接口级别注册。

比如我们常说的Eureka服务注册中心，实际是整个微服务模块注册，而不是该微服务提供的具体多个API接口服务的注册。因此后续的心跳监控，负载均衡等也全部是在微服务这个颗粒度上面。

而微服务API接口注册，即微服务提供出来的Http Rest API接口的具体注册动作，比如一个微服务本身提供了100个接口，但是只有10个API接口需要外部APP访问，那么这个时候实际上只需要将这10个接口注册和接入到API网关即可。

去中心化和中心化的思路区别

对于微服务架构下的服务管控治理，要首先考虑中心化和去中心化的区别。

对于中心化架构，简单来说就是所有的API接口服务全部都要注册和接入到API网关中，等于是API网关基于原始的业务服务API接口做了一层封装，然后发布代理服务。

那么对于所有API接口服务的调用，涉及到的调用请求，消息的输入和输出，都可以在API网关中进行拦截。