自定义实现网关

背景

​ 现在社区中有netflix的zuul和spring cloud gateway等现成的网关框架，他们的原理是什么，为什么具有请求转发的能力，市面上的网关框架能够满足公司需求吗，为什么有的公司会自己实现一套。上面这些疑问我相信大家都会思考过，接下来这篇文章会从怎么实现自定义网关的角度来解答这些问题。

思考

自定义网关应该具备什么的能力

• 应该市面具备上的网关框架的能力，比如请求转发、负载均衡等，如果正常情况下连这些都不能具备的话，那还不如直接用现成的
• 针对基础能力的改造或者说是进阶能力吧，比如说请求转发是不是可以提供配置化，动态负载均衡等
• 提供全新的进阶能力，比如说是多租户，api市场，限流熔断等。

自定义网关的定位

定位应该是一个提供服务的平台，具备以下特点：

• saas平台，不仅提供多租户的能力，而且具备了API市场的特点。
• 服务消费方从接入多种提供方过渡到只接入网关即可，节省时间。
• 提供公共能力，如限流/熔断等。
• 以后可以提供sdk，调用方引入后可以代码编写。

架构

要点以及实现思路

​以下列举了大概要点：

动态网关路由规则

设计一套路由规则，用于决定请求应该被转发到哪个后端服务。这些规则可以基于请求的路径、方法、头部信息等进行匹配和路由。

实现：比如说利用数据库，设计一张路由表，其中记录了请求路径、转发的链接以及请求类型等，这样每次请求过来时查询这种表就可以知道转发到哪儿了。并且，之后可以围绕这张表扩展一些功能，如权限、限流等，这快可以单独设计一个微服务，作为以后的saas平台的基础。

实现请求转发

当网关接收到请求时，根据定义的路由规则将请求转发到相应的后端服务。可以使用底层的HTTP客户端库（如Apache HttpClient、OkHttp、AsyncHttpClient等）来实现请求的转发。

实现：暂时利用HttpClient实现转发。之后，可以将此功能抽象出来，方便接入其它的库。

添加过滤器机制

实现一个过滤器链，用于在请求转发前后进行一些通用的处理操作，如请求的验证、参数的修改、请求头的添加等。过滤器可以根据需要进行自定义扩展。

实现：其实这些属于扩展功能，暂不实现。

实现负载均衡

借鉴ribbon和loadbalancer的负载均衡规则。

实现：注册到同一个注册中心的服务需要用到负载均衡，看情况能否支持eureka和nacos等。如果只是单独使用了网关能力的，不涉及。

添加安全认证和授权

包括身份验证、访问令牌验证、角色权限验证、服务消费方认证等。

实现：这些都可以自定义filter。

提供监控和日志功能

添加监控和日志记录功能。集成actuator和prometheus。

实现：自定义关键参数，如转发次数，失败次数以及其它参数等，利用micrometer库进行数据上报。grafana和prometheus监控。

熔断功能

慢请求熔断，条件熔断等，提高网关并发能力。

实现：集成resilience4j的circuitbreaker功能，熔断规则也可以在控制台配置。

提供可扩展性和高可用性

部署架构

实现：基于公司生态，现在都基本上都是k8s了。

未完，之后再补充吧。