网关应该具备哪些功能

网关应该具备哪些功能：

路由

诸多的服务通过不同的入口访问，所有的请求此时都会挂在网关服务上转发，或者是更粗暴的通过 ip:port 的形式访问服务。随着服务化的进程愈演愈烈，更多的新生服务开始部署，这时候如上的做法会让管理服务变得更加痛苦。

image

鉴于此类情形，微服务中的服务注册和发现势在必行，服务治理之下，网关一层接入服务发现，极好地支撑起了微服务体系下服务的快速扩展。服务在应用内部被管理而通过网关路由定位，这个实现很好的屏蔽外部调用对服务的不必要信息的感知。

网关作为边界，分割了内部应用和外部调用。

image

微服务架构下，所有的应用都不应该是单点的，同应用多实例组成的集群体系才是关键，网关此时也可以担任负载均衡的能力。

在前面网关负责路由，划分了内外部边界后，外部对我们内部的系统就是一个单纯的调用关系，内部的优化可以由我们自己来进行。

image

因为服务的区分更加细微，导致单个服务提供的能力有限，针对复杂业务，外部调用可能需要多个接口才能返回一个业务对象。

网关做一次接口聚合，将多个请求结果合并返回，这样外部调用只需要调用指定接口就可以得到业务数据，降低外部使用复杂性。

image

微服务中，每个单独的服务都会有权限检查的需求，而单独部署在每个服务中的鉴权代码会高度重复，难以管理，且重复鉴权会给授权服务带来更大的压力。请求通过网关可以标识当前访问者身份和部分权限，合理解耦大部分重复代码，业务中有具体复杂的权限需求可以在应用中再次通过身份标识获取权限。

image

可以在网关层面实现断路器, 即超过了指定的阈值，API网关就会停止发送数据到那些失败的模块。这样可以防止服务之间的调用延时造成的雪崩，又有足够的时间来分析日志，修复问题。

同样可以对流量进行限制，实现限流的能力，缓解下层服务的压力。

还可以通过黑白名单设置，直接禁止某些请求到达下层应用，防止恶意访问等情况。

网关作为流量在业务的第一层入口，可以监控各个应用的基础指标；又如在聚合能力之上，可以记录聚合业务日志，标记异常堆栈，方便追踪排查。

image

通过网关的流量控制，可以实现新旧版本同时"服役"，通过实际流量检验服务情况，并实现服务的平滑升级。

如上所述，我总结了三点：

网关凭借着自己在微服务架构上独特的"地理"优势，发展大有可为。

比如隔离，因为外部服务只对接网关，从而解放了内部服务，内部服务可以不再使用 RESTful 的形式暴露接口，而可以通过 RPC 的形式实现内部服务的调用，提高内部的传输效率，从而带动整体性能的提高。

比如解耦，使得内部繁多的鉴权业务得以统一，提高了内部服务编码的便捷性和安全性。

比如脚手架，网关支撑着整体对外的流量，诸如想要知道最活跃的用户群等信息，都可以通过这个脚手架。不过这里要注意业务的轻量，避免对网关造成压力而导致整体的吞吐量的下降，得不偿失。

基于以上三点，可以放开想象力，挖掘网关的更多能力。