斗胆推荐一款刚出的微服务网关

前言

使用 API 网关作为内部服务面向客户端的单一入口，是一种普遍采用的架构模式。企业组织通过良好定义的 API 将内部系统向内部和外部用户公开，通常都会采用 API 网关来处理横向的关注点，包括访问控制、速率限制、负载均衡等等，来实现安全可控的 API 开放。而被广泛实践的微服务架构在提供高度灵活性和弹性的同时，也给 API 网关带来了更多的挑战。

阿里云云服务总线（Cloud Service Bus）新推出微服务网关服务（CSB Micro Gateway），针对微服务架构下 API 开放的特点，提供能与微服务环境的治理策略无缝衔接的网关服务，实现高效的微服务 API 开放。

API 网关的作用

API 网关典型作用

相信许多人都熟悉 API 网关的概念。作为内部服务面向客户端的单一入口，API 网关有两个最典型的作用：

1、内外解耦：对客户端屏蔽内部服务的动态多样化实现细节，如技术框架、拆分粒度、接口结构、实例状态等

2、切面控制：让内部服务能专注在业务逻辑上，集中处理横向的关注点，如路由、安全、限流、日志、监控等

API 网关使用类型

实际使用中，对应 API 网关所在位置和针对场景的不同，可分成两种类型：

1、企业级网关：位于企业组织的外围，面对外部的 API 消费者或服务提供者。通常将企业自身的数据和能力 API 化，对外开放，也有允许外部服务入驻的情况。总的来说，以支撑服务入驻、服务运营和服务门户场景为主，侧重解决管理和运营挑战。

2、微网关：位于企业组织内部，面对内部的 API 消费者，可以看做是内部服务之前的最后一道防线。通常按内部服务的业务划分、物理环境以及技术形态的差异，设立多个微网关来分别负责。总的来说，以提供快捷开放、策略控制、服务适配能力为主，侧重提升开发和运维效率。

实际上，企业级网关和微网关只是两种使用类型，在关注的网关特性上有不同侧重，实践上并非一定需要不同的产品或两套独立的部署。

API 网关流量特征

企业级网关处理的一定是 API 消费方和后端服务之间的流量，也称为南北流量；微网关一般也只是处理南北流量，当负责的服务本身缺乏注册发现机制，例如运行在传统应用服务器上的不同应用，当相互调用需要一个切面管控时，可以用微网关来统一处理服务间流量，也称为东西流量。

微服务网关定义

在这里我们做个定义：用于微服务环境的微网关，称作微服务网关。开源产品中，Kong、Netflix Zuul、Spring Cloud Gateway、Ambassador 等都可以用来作为微服务网关，其中 Ambassador 是基于 Envoy 构建的，属于 K8s 原生微服务网关。那么，微服务网关有什么特别的地方，需要解决什么问题呢？

API 网关在微服务架构下面临的挑战

服务治理诉求

在微服务架构模式下，小型化、自包含、相对隔离、随时可运行的应用形态，带来了极大的灵活性和弹性。但是微服务架构高度动态的服务分布和复杂依赖的特点也带来了很多挑战：链路复杂，定位故障点困难；一个服务的故障可能带来雪崩效应；端到端的测试难以实施等等。对应这些问题，出现了一系列典型的服务治理手段：

• 链路压测 - 端到端实际流量特征的测试，尽可能多暴露问题与风险，好针对制定保障策略
• 监控报警 - 实时监控各个服务、组件的状态指标，即时报警
• 链路追踪 - 追踪用户请求产生的服务调用路径，分析瓶颈风险，快速定位问题
• 日志分析 - 搜集分散的日志，提供快速准确查询，配合链路追踪分析问题
• 访问控制 - 实施权限检查，规范调用控制
• 服务发现 - 动态注册发现，同步服务状态和可用性
• 流量管理 - 结合服务发现，实施灵活的负载策略和流量调度
• 熔断降级 - 核心业务失效快速响应，避免请求堆积，非核心业务降级处理，保证核心业务流畅
• 配置中心 - 集中管理配置，高效高可用推送，保护敏感配置信息

在实现上，这些横向的治理能力大都需要微服务应用配合对接，这些公共机制的实现可以通过微服务框架（例如 Spring Cloud、Dubbo）来提供，让应用开发能专注在业务逻辑上。或者采用服务网格（Service Mesh）模式，从应用实现解耦，付出一定性能代价，在应用本地的反向代理组件（Sidecar）中转发流量并处理所有这些逻辑。

微服务网关的配合

由于微服务的调用方可能在微服务环境内部，也可能在微服务环境外部，这些横向的治理能力，有时也需要同时作用到微服务环境与外部之间的南北流量上。这时就需要网关的配合。

以服务发现和流量管理这两个策略为例，考察两个非常普遍的典型场景：

场景一：流量正确路由到可用的微服务实例

场景二：同步在网关上执行金丝雀发布灰度规则

当一个微服务的实例增加、减少，或者不可用时，网关要能把流量正确地路由到可用的微服务实例上；
当微服务更新版本，采用金丝雀发布的时候，灰度策略不但需要在微服务环境内的东西流量上生效，在网关上也要执行相同的灰度策略。

很明显，网关进行这样的配合，如果采用人工操作的方式的话，会带来很多问题：
首先是实时性差，导致网关流量路由的失效和错误几率增大；
其次是运维和管理的压力，对应关系容易错乱，操作可能失误错漏，带来很大风险。

设想一下，要校对实例的可用状态，然后在网关或网关后的负载上挂载、卸载对应端点；或在金丝雀发布、中断、回滚时，在网关上进行对应的灰度判定和路由配置。如果微服务稍微多些，运维和管理的难度、风险都是显而易见的。

因此，微服务的网关，需要能够和微服务环境的治理能力自动化联动。对应上面的例子，就是要求：
能够自动基于微服务环境的服务发现策略，将服务请求动态地路由到可用的微服务实例上；
能够在微服务环境进行金丝雀发布时，自动同步配合执行对应的灰度策略。

也就是说，需要微服务网关和微服务环境在服务治理策略上能够无缝衔接，自动配合生效。对这个要求的支持，也正是新发布的微服务网关服务（CSB Micro Gateway）的核心特性之一。

微服务网关云服务

使用阿里云云服务总线（Cloud Service Bus）新发布的微服务网关服务（CSB Micro Gateway），用户可以为目标微服务环境快速创建微服务网关。指定注册中心后，微服务网关就可以动态感知微服务节点的变更，将 API 请求动态路由到后端微服务。通过控制台可以基于注册中心的服务列表快速发布 API，支持服务路由规则的动态变更生效，可以方便地管理限流、鉴权、后端负载均衡等控制策略，提供完整的 API 访问日志和统计报告，并且支持和后端微服务治理策略的联动，例如配合微服务应用的升级发布自动执行灰度路由策略。

新发布的微服务网关服务：
https://help.aliyun.com/document_detail/156009.html

微服务亲和特性

• 关联微服务环境，快捷创建、扩容缩容微服务网关
• 基于微服务环境注册中心的服务列表，方便地选取服务开放为 API
• 动态感知微服务节点的变更，将 API 请求路由到可用微服务实例上
• 支持服务路由、限流、鉴权、后端负载均衡等各种控制策略，动态生效无需重启
• 支持与微服务治理策略的无缝联动，例如无需用户干预，自动配合执行灰度路由策略等

现状与规划

微服务网关服务（CSB Micro Gateway）是阿里云上的托管式微服务网关服务，提供高度的可用性和稳定性，基于开源引擎，支持开源配置方式。将陆续提供多种微服务网关引擎的托管服务，以满足不同场景的侧重需求和使用偏好。

公测首先推出基于 Zuul 的服务版本，支持 Eureka 注册中心以及 Spring Cloud 微服务框架。
将很快支持基于 Kong、Ambassador 等引擎的托管服务
将很快推出 Nacos 等多种微服务注册中心的支持，将陆续支持 Dubbo、gPRC 等多种微服务框架
将陆续提供丰富的控制策略，包括各种鉴权方式、流量控制、安全防护、服务组装变换等等，以及支持用户自定义实现的策略
将陆续补充企业级网关所侧重的一些开放管控能力，例如 API 标准规范定义、API 文档、API 测试调用、多版本管理等

标签：斗胆,网关,服务,策略,流量,API,刚出,路由
来源： https://www.cnblogs.com/yunqishequ/p/12743834.html