如何选择和设计微服务网关

• 1. 背景

  • 1.1. 容器化支持
  • 1.2. 灰度发布
  • 1.3. 统一身份鉴权
  • 1.4. 可观测
  • 1.5. 协议代理和转换

• 2. 如何设计微服务网关

  • 2.1. 高性能
  • 2.2. 稳定性
  • 2.3. 丰富治理能力
  • 2.4. 可扩展性
  • 2.5. 可观察
  • 2.6. 可视化管理

• 3. 常见主流API网关

  • 3.1. 平台锁定
  • 3.2. 无法二次开发
• 4. 如何选型
• 5. 主流API网关对比
• 6. 鸣谢

1. 背景

API网关 并非一个新兴的概念，在十几年前就已经存在，它的作用主要是作为流量的入口，统一的处理和业务相关的请求，让请求更加安全、快速和准确的得到处理。是所有流量请求响应出入流量的必经之路，它除了可以做最基础的反向代理之外，还可以处理通用的公共服务逻辑，如负载均衡、灰度发布、限流熔断、统一认证授权、可观测性、动态路由、协议转换、服务编排、流量镜像、健康检查、监控报警、安全防御等。以下为 API网关 常见的具体的特性，虽然开源领域网关并不都全部满足，但是这些都可以纳入网关上来实现的。它有以下传统的功能：

• 反向代理和负载均衡，这和 Nginx 的定位是一致的；即当服务器负载上升时候，网关需要对系统资源进行容量评估，适当增加服务器资源，让每个应用节点可以平均处理请求，一般使用的负载策略有轮询、IP哈希、随机分发、标记权重等
• 动态上游、动态 SSL 证书和动态限流限速等运行时的动态功能，这是开源版本 Nginx 并不具备的功能；
• 上游的主动和被动健康检查，以及服务熔断；在实际生产中发现某应用系统不健康或者处理超定义的上限，为了保护整个服务链，主动触发限流现频和熔断机制，引导请求到预定义的处理方式，并产生告警信息，避免因服务不可用进一步造成整个服务链发生雪崩
• 在 API网关 的基础之上进行扩展，成为全生命周期的 API 管理平台。

在最近几年，随着微服务架构的结构变迁，服务之间的流量也开始爆发性的增长。在这种新的业务场景下，催生了 API网关 更多、更高级的功能：

1.1. 容器化支持

云原生友好，架构要变得轻巧，便于容器化。

1.2. 灰度发布

相比较于传统发布，灰度发布可以在入口处可以设置对新功能的请求流量可按照定义分配，从而在一定时间内在试用过程中，发现和解决问题，从而使得产品在大面积推广过程中更加成熟。

1.3. 统一身份鉴权

当前很多企业的系统权限鉴权逻辑散落在各站点服务中，可以将当前基于角色的认证逻辑和对外开放平台所使用的 OAuth 授权认证完全抽离出来，统一挪移至网关。

承担 OpenID Relying Party 的角色，对接 OAuth 、Okta 等身份认证提供商的服务，把流量的安全作为头等大事来对待；

1.4. 可观测

承接集群流量，就需要掌握每个接入站点的流量分布情况；以及每个API接口的处理时长；响应的状态，再细分的话可以观察到业务响应异常的分布情况；监控往来的短信业务与邮件业务，统一处理告警规则与策略，最终汇聚为统一的网关业务看板。对接 Prometheus、Zipkin、Skywalking 等统计、监控组件；

1.5. 协议代理和转换

支持 gRPC 代理，以及 HTTP 到 gRPC 之间的协议转换，把用户的 HTTP 请求转为内部服务的 gRPC 请求；

API网关 除具备上述特性，还应该具备在通过运行时动态执行用户函数的方式来实现 Serverless，让网关的边缘节点更加灵活；不锁定用户，支持混合云的部署架构；网关节点要状态无关，可以随意的扩容和缩容等，这样的网关才就可以让用户的服务只关心业务本身，而和业务实现无关的功能，比如服务发现、服务熔断、身份认证、限流限速、统计、性能分析等，就可以在独立的网关层面来解决。从这个角度来看，API网关 既可以替代 Nginx 的所有功能，来处理南北向的流量，也可以完成 Istio 控制面和 Envoy 数据面的角色，来处理东西向的流量。

2. 如何设计微服务网关

上述是一些对微服务网关的认识，在有了明确目标和需要解决的问题，后面就是针对性选择响应技术，这里大致提供六个关键性因素，供参考。

2.1. 高性能

作为集群流量入口，性能首先要保证的，包括吞吐量和延迟，二者是衡量一个高性能网关的关键要素。所以性能自然要求越高越好，要满足对性能要求最苛刻的那一个业务方的需求。

还有一点，所谓高性能，不一定是吞吐量和延迟达到某个固定标准，很多时候只要满足业务方的实际需求就是高性能网关，在此之前，没有必要过早优化。很多时候，网关的开销只有几毫秒，而业务本身开销几十毫秒，瓶颈不在网关。

2.2. 稳定性

网关稳定性的保证是一个同高性能一样重要问题，一般除软件的质量之外，更多的还是要依赖流程的控制以及针对性的技术方案，比如灰度发布、金丝雀发布之类的。但是总体来说，就是要经历实际生产上大规模、多场景的的业务考验和流量验证。

2.3. 丰富治理能力

它作为整个集群入口，常用的治理能力如身份鉴权、限流、降级、熔断、监控报警/调用链追踪、黑白名单、灰度发布、请求分发、条件路由、API管理 等。举个例子，现在乘坐高铁检票，都会对人像和证件进行匹配，一人一闸。网关也类似，被要求做越来越多的与业务逻辑无关的额外治理功能。

2.4. 可扩展性

和治理能力非常相关的一个关键特性就是 可扩展性 ，因为业务方的需求总是在无穷无尽的变，很多场景下甚至会有一些非常定制化的需求，网关也难以覆盖所有需求，所以 可扩展性 就非常关键。

• 良好的 可扩展性 可以帮助网关快速迭代新功能，对网关来说可以降低扩展新的治理能力的成本和开销；
• 降低网关开发的门槛，对于具有一定技术能力的团队，业务可以根据自身需求特点实现最合适的功能扩展，可以提高自身的自主能力；

2.5. 可观察

可观察性在微服务架构当中非常重要。因为业务不再是单体，为排障监控带来了新的复杂度，所以需要可观察性的支持。

• 辅助排障：日志指标也会包含业务的一些特征情况，可以帮助业务方快速定位出问题所在。
• 观察趋势：最后，作为流量统一入口，网关的可观察性可以让用户了解到集群内的流量现状、趋势，并且形成长效的监控告警系统，提前发现问题。
• 自证清白：实践得来的一个经验是，一旦集群内流量产生了一些业务层面的波动，作为入口的微服务网关几乎总是第一个被怀疑的对象。明确的可观察数据比如说日志、指标可以有说服力的证明网关的清白；

2.6. 可视化管理

一个友好、易用的可视化管理控制台，可以实现对网关的 路由配置、 服务管理 、 监控审计 的可视化。要求可视化管理控制台必须满足以下三点要求：

• 简化操作：通过平台产品的封装，简化网关的操作流程和配置过程，隐藏或者减少底层技术的复杂性，降低 API 网关的使用门槛。
• 实现约束：实现约束，通过产品的封装和合理的提示，降低在使用 API 网关的过程中，用户犯错的风险，让用户以一种更加正确的姿势使用网关。
• 监控报警可视化。

3. 常见主流API网关

微服务 API网关 如此重要，所以传统的 IT 巨头在这个领域很早就都有布局，比如谷歌、CA、IBM、红帽、salesforce、以及 AWS、阿里云等公有云厂商。这些闭源的商业产品，它们的功能都很完善，覆盖了 API 的设计、多语言 SDK、文档、测试和发布等全生命周期管理，并且提供 SaaS 服务，有些还与公有云做了集成，使用起来非常方便，但同时也带来两个痛点：

3.1. 平台锁定

API网关 是业务流量的入口，它不像图片、视频等 CDN 加速的这种非业务流量可以随意迁移，API 网关上会绑定不少业务相关的逻辑，一旦使用了闭源的方案，就很难平滑和低成本的迁移到其他平台。

3.2. 无法二次开发

一般的大中型企业都会有自己独特的需求，需要定制开发，这时候你就只能依靠厂商，而不能自己动手去做二次开发。

[[CNCF]]

鉴于以上这些闭源产品的 平台锁定、无法二次开发 ，所以我们在产品选择过程中更偏重于开源 API网关 ， Kong 、Apigee、akana 等，此类网关在设计之初，带有一定局限性，比如容器化支撑能力不足；因为他们是应用型网关，先天性的缺点就是的性能比较差，满足不了对快速增长的流量进行处理；而同时它们的治理能力也是一块短板。下图从 云原生计算基金会Github 中截取的一部分。（想了解更多关于 云原生计算基金会）

4. 如何选型

在使用 API网关 过程中，我们主要应该考虑部署和维护成本、功能是否满足当下和未来可能出现会出现需求以及社区的支持是否丰富，这将决定你的 API网关 是否能更好的契合自身产品需要。

5. 主流API网关对比

6. 鸣谢

Apache APISIX

感谢 APISIX 无私奉献，也希望这些总结可以给正在为网关如何做的你带来一些帮助