文章目录
- 什么是网关?
- 网关类型
- 网关的优缺点
- 目前的网关解决方案有哪些?
- 为什么要自研Gateway网关?
- 自研网关需要注意什么?
注:
这篇文章作为我的网关的第一篇文章,并不涉及任何代码,只是提及了网关的作用,以及为什么要自研网关,后续文章将不断更新。
什么是网关?
网关(Gateway)是计算机网络中的一种重要设备,用于连接不同网络、协议或通信系统,以便它们能够相互通信和交换数据。网关的主要功能是在不同网络之间传递数据,并确保数据能够正确路由和转换,以便不同网络中的设备能够互相理解和交流。以下是网关的一些重要概念和功能:
连接不同网络:网关通常用于连接不同网络类型,如局域网(LAN)与广域网(WAN)、以太网与无线网络、IPv4与IPv6等,以实现不同网络之间的数据传输和通信。
数据转换和协议转换:网关可以将数据从一个网络协议转换为另一个,以确保不同网络中的设备可以相互通信。这通常涉及将数据从一个协议的格式转换为另一个协议的格式,例如将数据从TCP/IP协议转换为HTTP协议。
安全性与熔断限流:网关还可以用于增强网络安全性。它可以执行防火墙功能,监控数据流量,过滤恶意流量,实施访问控制策略,以保护网络免受未经授权的访问和网络攻击。
数据路由:网关可以决定数据包的最佳路径,以确保数据从源到目的地的有效传递。这通常涉及查看目的地地址,并选择适当的输出接口或下一跃点来传输数据。
协议翻译:在不同网络之间通信时,可能需要执行协议翻译,以确保数据能够正确解释。网关可以执行此类任务,确保不同网络中的设备能够相互交流。
网关类型
RESTful API网关
- RESTful API网关通常用于管理和提供对RESTful API的访问。
- RESTful API是基于HTTP协议的,通常用于请求-响应模式的通信,适用于获取、创建、更新和删除资源等操作。
- RESTful API网关提供了路由、认证、授权、访问控制、日志记录和监控等功能,以确保API的安全性和可用性。
- RESTful API网关通常不支持实时双向通信,因为HTTP是无连接的,不适用于持久性连接。
WebSocket API网关
- WebSocket API网关专门设计用于处理WebSocket协议的实时双向通信。
- WebSocket协议允许客户端和服务器之间建立长期的双向连接,以便实时传输数据,适用于实时聊天、在线游戏、实时通知等场景。
- WebSocket API网关提供了WebSocket连接的管理、路由、负载均衡、协议升级和消息传递等功能。
- WebSocket API网关支持持久性连接,而不像RESTful API那样在每个请求之间建立新的连接。
网关的优缺点
优点
-  简化客户端开发: 
 网关允许客户端应用程序与后端服务进行通信时,无需关心复杂的网络协议和细节。客户端只需要与网关通信,而不必直接与后端服务交互。这大大简化了客户端的工作,减少了开发者需要处理的技术细节。
 客户端不再需要了解后端服务的具体地址或API端点。它只需知道如何与网关通信,网关负责将请求路由到适当的后端服务。
-  降低耦合度: 
 使用网关作为中间层,可以将不同部分的系统分离开来,降低了它们之间的紧密耦合。这有助于提高系统的可维护性和可扩展性。
 网关可以处理诸如身份验证、授权、数据转换等共享的功能,而不是将这些功能分散在每个单独的服务中。这减少了功能的冗余和重复,使开发者可以更容易地维护和更新这些功能。
-  减少重复造轮子: 
 通过将共享功能抽象到网关中,开发者可以将更多精力专注于业务逻辑的开发。他们不必为每个服务都重复实现相同的功能,如身份验证或请求验证。
 网关还可以提供性能优化、负载均衡和缓存等功能,从而减轻开发者的负担,使他们更专注于业务逻辑的实现。
缺点
-  可能出现的性能瓶颈问题 
 微服务架构旨在将大型应用程序拆分成小的、相对独立的服务,以提高灵活性和可伸缩性。然而,当使用网关时,它可能成为性能瓶颈点,特别是在高负载情况下。
 网关通常需要处理大量的请求和响应,包括请求路由、认证、授权、数据转换等任务。如果网关没有经过适当的优化和扩展,它可能会限制整个系统的性能。
-  请求阻塞问题 
 微服务架构鼓励使用异步通信和非阻塞IO,以便服务可以并行处理请求,提高响应性能。然而,一些网关可能依赖于同步通信模型,这可能导致性能下降
 如果网关执行的操作需要等待外部服务的响应,而没有采用异步模型,那么网关可能会成为整个请求-响应链中的阻塞点,影响系统的性能和响应时间。
-  高耦合度 
 如果网关与微服务之间的耦合度过高,它可能限制了系统的可伸缩性和独立部署能力。例如,如果多个微服务与特定网关高度关联,那么更改该网关可能需要修改多个服务,这违反了微服务架构的原则。
 高耦合度还可能导致开发团队之间的协作问题,因为它们必须协调更多的更改,以适应网关的变化。
目前的网关解决方案有哪些?
Nginx:
 基于C/Lua
 优点:
 高性能,适用于大规模应用和高流量负载。
 强大的可扩展性,支持Lua脚本和定制插件。
 多用途,不仅限于API网关,还可用作反向代理和负载均衡。
 缺点:
 配置和管理需要技术专长,不够用户友好。
 高级功能需要OpenResty等扩展
Kong:
 基于Lua
 优点:
 易于扩展,提供了丰富的插件生态系统。
 支持微服务架构,适用于复杂的部署。
 集成性强,可与其他服务集成,如数据库和消息队列。
 缺点:
 需要管理和维护,特别是在大规模环境中。
 某些高级功能可能需要编写自定义插件。
Apigee:
 优点:
 云端托管,无需自己管理基础设施。
 提供全面的API管理功能,包括分析、监控和安全性。
 高度可伸缩,适用于大规模应用。
 缺点:
 有一定的学习曲线,需要了解Apigee的配置和设置。
 可能较昂贵,特别是对于小规模项目。
AWS API Gateway:
 优点:
 与AWS生态系统无缝集成,提供高可用性和可扩展性。
 简化了API部署和管理。
 可以利用其他AWS服务,如Lambda函数。
 缺点:
 锁定了到AWS云的依赖性,不适用于混合云环境。
 可能需要了解AWS特定的配置和设置。
Istio:
 优点:
 为微服务提供了丰富的流量管理和安全性功能。
 支持多云和混合云环境,不受限于特定云提供商。
 集成了Prometheus和Jaeger等监控工具。
 缺点:
 复杂性较高,学习和部署需要时间。
 可能需要大量配置,特别是在大规模环境中。
Spring Cloud Gateway:
 优点:
 与Spring Cloud生态系统集成,支持Spring Boot应用程序。
 轻量级,易于部署和管理。
 支持动态路由和过滤器。
 缺点:
 功能相对较少,适用于中小规模应用。
 可能不如其他网关适用于复杂的API管理需求。
Traefik:
 优点:
 专为容器化应用和微服务设计,支持Docker和Kubernetes。
 自动发现后端服务,动态配置。
 轻量级,易于部署和管理。
 缺点:
 功能相对较少,适用于较小规模应用。
 可能需要额外的插件来支持高级功能。
HAProxy:
 优点:
 高性能的负载均衡器,适用于高负载环境。
 简单配置和管理。
 支持TCP和HTTP负载均衡。
 缺点:
 较少的高级功能,不适用于复杂的API管理需求。
 缺乏API网关特定功能,如身份验证和授权。
为什么要自研Gateway网关?
目前比较流行的网关有SpringCloud Gateway,SpringCloud Zuul,他们都是比较优秀的网关。
 不过这些网关都是基于Java语言开发的,而如果我们要使用这种网关就必须会Java,而如果公司的业务大部分是go,比如我所就职的字节,目前go用的就比较多,所以用Java做网关就不太合适了。
 其次是使用这些成熟框架,由于其面面俱到,所以意味着当我们只需要使用网关中的部分功能的时候,直接使用这些框架就会使得业务项目过于庞大了。
 因此考虑自研一个网关还是有比较的,我们只需要实现其中比较重要的并且我们所需要的功能就可以,自研网关也提供了网关更强的自定义能力。
自研网关需要注意什么?
1:可扩展性。我们需要确保自己的网关具有较强的扩展性,因为我们不仅仅要考虑当前的业务需求,也需要考虑未来的业务需求。
 2:合理的架构配置。我的自研网关将会使用领域驱动模型DDD来进行开发。如果不了解DDD的可以去了解一下其优缺点。
 3:接口兼容性:我们知道网关一般会用到配置中心或者注册中心,目前比较主流的有Apollo和Nacos,因此我们还需要提供较强的兼容性,使得在不同配置中心进行切换的时候游刃有余。
 4:三高设计:作为项目的第一个关卡,网关所需要承载的请求远大于后台具体服务,因此网关的性能是一种非常需要深入考虑和设计的方面。涉及到JVM调优,代码性能优化等。