云原生网关介绍
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/?commodityCode=mse_ingresspre_public_cn
请注意 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]
