共计 3586 个字符，预计需要花费 9 分钟才能阅读完成。
作者：澄潭
云原生网关介绍
MSE 云原生网关是阿里云提供的下一代网关解决方案，齐全兼容 Kubernetes Ingress 规范 API，将流量网关、微服务网关和平安网关三合一，解决了多层网关架构独立设计、独立运维导致的资源耗费大、性能损耗大、稳定性难控、平安防护简单等难题。相比传统网关，云原生网关在资源老本、性能、安全性和易用性上更有劣势。
传统多层网关架构
在这个架构中，用 WAF 网关实现平安能力，SLB 实现负载平衡能力，Ingress 网关实现集群入口网关能力（非 K8s 场景也会部署一层 Nginx），Zuul 实现微服务网关能力。这样的架构须要对每一层网关都进行容量评估，每一层网关都是潜在的瓶颈点，都可能须要进行扩容。这样造成的资源老本和运维人力老本都是微小的。并且每多一层网关，就多一层可用性危险。
MSE 云原生网关架构
应用 MSE 云原生网关，在保留 SLB 作负载平衡的根底上，只通过一层网关就实现了集群入口网关、WAF 网关、微服务网关的全副能力。并且这一层网关由阿里云托管部署，无需用户本人运维机器实例，并且提供网关可用性的 SLA 保障。除了大幅度降低人力老本、资源老本，还能提供更好的稳定性。
EDAS 场景的 Quick Start 示例
云原生网关反对多种服务发现机制，包含 K8s Service/MSE Nacos/MSE Zookeeper/EDAS 注册核心等。在 EDAS 场景下，微服务空间的注册核心，不管指定为 MSE Nacos 或者 EDAS 注册核心，云原生网关均能够发现 EDAS 上部署的服务，并创立路由进行转发。上面以应用 EDAS 注册核心为例，阐明如何疾速上手云原生网关。
Step 1. 购买创立云原生网关
购买链接：
https://common-buy.aliyun.com…
请留神 VPC 专有网络须要与 EDAS 中服务实例部署所在的 VPC 统一
Step 2. 创立服务起源
在服务治理一栏的起源治理中，创立服务起源，以部署在 Default 微服务空间下的 EDAS 利用为例，此处抉择对应的微服务空间即可。DEFAULT_GROUP 为 EDAS 注册核心默认的服务分组，若利用配置应用了 dubbo.registry.group、spring.cloud.nacos.discovery.group 等指定了服务分组时，须要额定增加对应的服务分组。
每个 EDAS 微服务空间对应一个服务起源，此处能够创立多个服务起源，各自对应不同的微服务空间。
Step 3. 创立服务
能够一键导入指定微服务空间下的所有服务
导入后能够看到每个服务对应的后端实例 IP，这表明服务发现曾经 OK；健康检查状态阐明网关到这些服务实例 IP 的网络联通性也是 OK 的。
Step 4. 创立路由
先填写路由匹配规定，能够别离针对 HTTP 门路 / 办法 / 申请头 / 申请参数配置匹配规定
点击下一步，抉择指标服务进行路由，下拉列表能够看到 Step 3 中导入的 EDAS 服务。点击保留并上线，这条路由将立刻失效。
作为全链路灰度的入口网关
利用 EDAS 成熟的微服务治理能力，配合云原生网关，能够轻松利用多套逻辑环境实现全链路灰度。EDAS 实现了基于字节码加强技术在编译时对开发框架进行性能拓展，这种计划业务无感知，不须要批改任何一行业务代码，即可领有全链路灰度的治理能力，并且反对近 5 年内所有的 Spring Boot、Spring Cloud 和 Dubbo。实现架构如下图所示：
用不同的色彩来示意不同版本的灰度流量，能够看出无论是入口微服务网关还是微服务自身都须要辨认流量，依据治理规定做出动静决策。当服务版本发生变化时，这个调用链路的转发也会实时扭转。相比于利用机器搭建物理灰度环境，这种计划不仅能够节俭大量的机器老本和运维人力，而且能够帮忙开发者实时疾速的对线上流量进行精细化的全链路管制。
上面以 SpringCloud 利用为例，演示如何在 EDAS 上，搭配云原生网关，实现全链路灰度。
Step 1. 部署服务
假如利用的架构由 MSE 云原生网关以及后端的微服务架构（Spring Cloud）组成，后端调用链路有 3 个：购物车（sc-A），交易中心（sc-B），库存核心（sc-C），能够通过客户端或者是 HTML 来拜访后端服务，这些服务之间通过 EDAS 注册核心实现服务发现，调用链路为：sc-A -> sc-B -> sc-C。
能够通过镜像的形式部署这三个服务，三个服务的镜像地址别离是：
sc-A：
msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-a:0.1
sc-B：
msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-b:0.1
sc-C：
msecrinstance-registry.cn-hangzhou.cr.aliyuncs.com/mse-demo/spring-cloud-c:0.1
是用自定义镜像形式部署：
- sc-A 服务
服务 A 是须要裸露给网关，网关会通过注册核心的元数据信息中获取服务的版本信息，所以这里通过环境变量的形式别离设置。
为基线版本设置利用配置：
spring.cloud.nacos.discovery.metadata.version=base
为灰度版本设置：
spring.cloud.nacos.discovery.metadata.version=gray
同时在灰度版本的 pod annotations 中设置 alicloud.service.tag: gray，用于 Java Agent 辨别以后服务所在的逻辑环境。
基线版本部署配置：
灰度版本部署配置：
- sc-B 服务 /sc-C 服务
这两个服务无需裸露给网关，除了镜像地址配置不同外，其余部署配置一样。只需在灰度版本的 pod annotations 中设置 alicloud.service.tag: gray，用于 Java Agent 辨别以后服务所在的逻辑环境。
基线版本部署配置：
无需任何配置
灰度版本部署配置：
Step 2. 在云原生网关创立服务
前置步骤须要创立服务起源，在 Quick Start 中曾经给出阐明，此处不再赘述，间接到创立服务这步，导入 sc-A 这个服务。
导入胜利后点击服务名称，进入服务策略配置，设置对应的服务版本。定义两个版本 base 和 gray，基于服务注册元数据信息中的 version 标签值进行辨别（Step 1 中通过 spring.cloud.nacos.discovery.metadata.version 配置）
Step 3. 在云原生网关创立路由
首先创立两个不同的域名，用于辨别基线环境和灰度环境：
别离创立两条路由：
准确匹配门路 /a 转发给 sc-A 服务，通过标签路由的形式，将 gray.example.com/a 转发给 sc-A 服务的 gray 版本；将 base.example.com/a 转发给 sc-A 服务的 base 版本。以前者为例，配置形式如下：
指定路由匹配形式：
抉择指标服务为标签路由，配置路由到 sc-A 服务的特定版本：
点击 gray 路由名称，对于这条灰度环境路由，通过设置申请头的形式，进行环境标签的设置，该申请头起到流量染色的作用，会在后续服务调用链上一路透传，Java Agent 会依据该申请头抉择对应环境的服务
Step 4. 验证全链路灰度成果
路由配置实现后，实现了如下环境隔离的成果（本例中通过域名辨别不同环境，还能够通过不同的路由匹配规定，实现基于 header、url 参数等辨别不同环境）：
- 拜访 base.example.com 路由到基线（base）环境
-
- curl 命令
curl -H "Host: base.example.com" http://118.31.XX.XX/a-
- 执行后果
A[10.66.3.133] -> B[10.66.0.113] -> C[10.66.3.132]- 拜访 gray.example.com 路由到灰度（gray）环境
-
- curl 命令
curl -H "Host: gray.example.com" http://118.31.XX.XX/a-
- 执行后果
Agray[10.66.2.3] -> Bgray[10.66.2.69] -> Cgray[10.66.2.195]- 如果入口利用 A 没有灰度（gray）环境，拜访到 A 的基线（base）环境，又须要在 A->B 的时候进入灰度环境，则能够通过减少一个非凡的 Header：x-mse-tag 来实现，Header 的值是流量走向的环境的标签，例如 gray。
-
- curl 命令
curl -H "Host: base.example.com" -H "x-mse-tag: gray" http://118.31.XX.XX/a-
- 执行后果
A[10.66.3.133] -> Bgray[10.66.2.69] -> Cgray[10.66.2.195]