深入Java微服务之网关系列1：什么是网关

前言

近来，在想着重构一个新的产品。准备采用微服务的技术解决方案，来搭建基础设施框架。网关，是一个必不可少的组件。那么，网关到底是什么？

其又有什么特点或者特性，成为微服务必不可少的组件呢？今天，我们就来探讨下这个问题。希望通过本文，大家能够明白，为何用。

演变过程

传统的单体技术架构，所有的内容，被打包进一个包内。为了保证，系统的稳定、安全，需要开发一些过滤器、拦截器，来实现对客户端请求的过滤与拦截，以及完成最终请求的转发。如下图所示

微服务技术解决方案下，同样需要为每个服务开发过滤器、拦截器来进行请求管理。但由于服务数量众多，同时，客户端形式多样化，如果在每个服务身上开发，将会造成很大的代码冗余与开发负担。因此，期待，将相同的一些功能，抽取到一个服务内实现，这便成为了一个组件，就是现在的网关。

网关存在的原因：

• 解决微服务技术架构下，请求管理功能

• 解决微服务技术架构下，多客户端的适配，采用单一入口，完成协议适配

网关的基本功能

微服务技术解决方案下的，网关，至少需要具备图示基本功能。

1. 网关作为单点入口，完成统一的请求管理

2. 免去客户端直接对接众多微服务的复杂性，采用单点入口，实现路由转发，从而实现服务调用

3. 服务对于整个系统来讲，是不稳定的，那么网关，需要进行限流熔断，保持系统的稳定与分区容错性

4. 对于服务调用的链路，网关有职责进行记录，日志监控，保证整个系统，在监控下工作

5. 系统可能不仅仅是由自有客户端调用，很多时候，系统开放能力API给外部，因此网关需要安全认证，来保证安全

这些年来，API网关正在经历一些身份危机。

• 它们是否是集中的、共享的资源，从而促进了API对外部实体的暴露与治理？

• 它们是集群入口（ingress）哨兵，从而可以严格控制哪些用户流量进入或离开集群吗？

• 或者它们根据自己拥有的客户端类型，使用某种API结合胶水来更简洁地表达API？

• 当然，房间里的大象和我经常听到的一个问题：“服务网格会使API网关过时吗？

房间里的大象：英语习语，指的是一些虽然显而易见，但却由于可能造成尴尬、争执、触及敏感或禁忌等原因被人刻意忽视的事情。

一些背景

随着技术发展日新月异，整个行业通过技术和架构模式进行快速洗牌，如果你说“所有这些都使我头大”，也可以理解。在本文中，我希望总结出“ API网关”的不同身份，阐明公司中的哪些群体可以使用API网关（他们正在尝试解决的问题），并重新关注这些首要原则。理想情况下，在本文结束时，您将更好地了解API基础架构在不同层级、对不同团队的作用，同时明白如何从每个层级获得最大价值。

在深入探讨之前，让我们先明确API一词的含义。

我对API的定义：

一个明确定义和目的型接口，通过网络调用，使软件开发人员能够以受控且方便的方式，对组织内的数据和功能进行编程访问。

这些接口抽象了实现它们的技术架构细节。对于这些设计的网络端点，我们希望获得一定程度的文档、使用指南、稳定性和向后兼容性。

相反，仅仅因为我们可以通过网络与另一软件进行通信，并不一定意味着远程端点就是符合此定义的API。许多系统相互通信，但是通信发生更加随意，并在与耦合和其他因素之间进行权衡。

我们创建API来为业务的各个部分提供周全的抽象，以实现新的业务功能以及偶然的创新。

在谈论API网关时，首先要提到的是API管理。