微服务架构-API网关(3.18)

今天再谈下微服务架构里面的API网关，前面实际上已经谈过多篇文章，包括也谈了类似当前API能力开放平台提供的网关能力，类似开源Kong提供的网关能力等。今天再做下简单总结。对于API网关实际上前面已经多次强调，可以看做是ESB总线的轻量化实现，不再需要复杂的协议转换，适配和数据映射等能力，但是提升了流量控制和安全，实时监控等方面的能力。

对于为什么需要API网关。对于该点可以总结如下：

1. 通过网关实现底层服务和微服务模块的位置透明，也可说提供统一服务目录

这点是网关和常规点对点服务注册中心最大的一个区别点，就是位置透明，消费端只需要和网关打交道，具体网关如何和后台的微服务模块打交道，后台微服务模块的部署逻辑，模块提供服务的IP地址等都不用关心。由于实现了位置透明，带来一点就是数据流必须通过网关，那么网关本身又成为了去中心的微服务架构中的中心化节点，那么就必须考虑网关节点的性能，可靠性和弹性扩展能力。

网关要实现位置透明，延伸出来对应的网关必须提供的能力就包括了

a. 提供服务注册和服务接入的能力

b. 提供服务代理和服务路由能力，能够将服务路由到具体的原始服务上

c. 提供负载均衡能力（该点并不是必须具备）

注意API网关是否需要具备负载均衡能力，是必须考虑的一个点，即如果底层微服务模块提供的API接口服务本身能够提供负载均衡后的地址，那么网关不需要进行负载均衡。如果底层模块不具备这个能力，那么网关必须具备负载均衡能力，同时该负载均衡能力还需要和微服务架构下的容器技术融合。

即在容器自动化扩展后，能够对负载均衡和路由参数配置进行自动化的更新。能够监控容器化中每个节点的状态，对于服务异常能够均衡到其它提供节点进行重试等。

一说到网关，就一定存在数据流传输，并且成为中心化节点，虽然不再需要协议转换，数据映射等重能力，但是网关本身也很难说真正的轻量。这也是为何在整个微服务架构体系里面网关只用于对外服务暴露的原因。

2. 通过网关的拦截能力来实现所有共性能力抽取和实现

刚才已经谈到启用网关后就承载了数据流，因此可以通过对接口访问输入和输出的拦截来实现所有共性可复用能力的抽取和实现。这些共性能力可以理解为网关实现的一个个拦截插件，本身可插拔，灵活可配置。

这些插件能力中最核心的就是安全，日志，流控。

其中安全可以实现访问安全，传输安全，数据安全等，其中访问安全本身又可以实现类似Token，IP，用户名密码等多种安全控制策略。包括对Auth2.0等标准规范的支持等。

对于日志也是网关提供的一个关键能力，即可以实现对服务消费日志，详细的输入和输出报文的查询能力，这个在各开源网关往往并不具备这个能力，也无法面向业务系统人员去使用，因此这块能力提升往往都需要在开源网关基础上做大量扩展。

流控是我们谈的另外一个关键能力，包括了服务限流和服务熔断。对于服务限流主要是实现对服务消费前线程数控制，资源分配实现消费前等待。而对于服务熔断，即直接对服务进行下线或禁用，以避免大并发服务消费调用对网关造成的影响或带来的服务雪崩等。

一个网关来说，流控能力相对关键，因为网关是中心化节点，必须保证网关的高可靠运行。因此网关流控能力强弱直接影响到网关的高可靠性和性能，而判断流控能力强弱的关键则在于灵活的流量控制策略配置，只有这样才能够做到既实现流控，又不影响到关键业务和接口服务的访问。

因为对于企业集成环境，简单来说不能因为流控策略不准确导致非必要情况下触发流控导致的业务中断。

3. 满足前后端分离的需求

注意，如果一个企业开发的业务系统涉及到手机APP端，而手机APP端一定涉及到公网访问，按业务系统内部部署安全策略也一定涉及到DMZ区的设置和硬件防火墙隔离。

而对于API网关本身恰好又是可以部署到DMZ区的一个内容，既实现了服务代理路由，又实现了安全隔离，如果存在这种场景，即使业务应用不和外部系统打交道，为了前后端的隔离和外部访问，往往也需要API网关能力支撑。如果仅仅是业务应用内部的Web前端和后端访问，则完全没有必要启用网关。

4. 灰度发布或金丝雀发布

这个在我原来谈网关的文章的时候很少谈到这点，但是实际上在DevOps和微服务架构实施下，对于灰度发布能力往往也是必须的。比如我们对已有的一个接口服务做了修改，我们想先在某些业务系统试用，没有问题再发布到所有的业务系统。这个时候就涉及到金丝雀发布的问题。当然你可以配置是按系统，按IP，按用户还是其他的发布策略。

这块的能力不仅仅是DevOps的自动部署，同时也必须考虑网关层能够基于动态发布的内容进行路由。确保服务调用消费的路由路径是隔离开的。而对于金丝雀发布策略允许你直接只导入指定量的流量到新的版本，API网关就可以帮你来做这件事情。你可以配置10%的请求到新的版本，然后一旦你确保了新版本没有bug，你可以把流量切换到100%。

5. 服务组合能力

实际上当我们谈API网关的时候，一般不会谈服务组合能力，因为一涉及到服务组合或编排，那么必然导入网关整体架构变重。从当前主流网关看，一般也不提供类似能力。

实际上服务组合编排难点在于，上个服务的输出往往要成为下一个服务的输入，同时服务输入和输出还存在大量的数据映射操作。我们回顾下类似智慧家庭里面的组合场景编排，实际上很简单，比如我回到家后需要打开空调，关窗帘，打开热水器，开灯的一系列动作，我只是需要简单将这些动作编排在一起。

对应到API网关的服务组合，实际上我们也可以做轻量的服务组合，即去掉数据映射等复杂组合场景，只需要实现简单的服务多次调用，服务返回数据的组合等即可。而服务自动化组合能力，后面准备专门写篇文章来思考实现逻辑和实现的可行性。