一、为什么需要「 API网关 」?
为什么做微服务的需要「 API网关 」呢?「 API网关 」到底有些啥功能呢?我们以前项目结构比较简单的时候有用到过「 API网关 」概念的模块吗?
其实在我们的项目曾经还是单体应用的时候,虽然没有「 API网关 」的概念,但是一般在项目中都会用到filter/过滤器之类的东西,filter的作用就是把项目中的一些非业务逻辑的功能抽离出来独立处理,避免与业务逻辑混在一起增加代码复杂度。比如 鉴权认证功能、Session处理、安全检查、日志处理等等。
现在我们采用微服务架构了,在一个项目中微服务节点很多,如果让每一个节点都去处理上面这些 “鉴权认证功能、Session处理、安全检查、日志处理等” 会多出很多冗余的代码,也会给增加业务代码的复杂度,因此我们就需要有一个「 API网关 」把这些公共的功能独立出来成为一个服务来统一的处理这些事情。
我们看一下下面这个微服务架构示意图:
「 API网关 」就像是微服务的大门守卫一样,是连通外部客户端与内部微服务之间的一个桥梁。
其主要功能有:
路由转发
之前说了「API网关」是内部微服务的对外唯一入口,所以外面全部的请求都会先发到这个「API网关」上,然后由「API网关」来根据不同的请求去路由到不同的微服务节点上。例如可以 根据路径 来转发、也可以 根据参数 来转发。
并且由于内部微服务实例也会随着业务调整不停的变更,增加或者删除节点,「API网关」可以与「服务注册」模块进行协同工作,保证将外部