写点什么

说点大实话丨知名技术博主 Kirito 测评云原生网关

  • 2023-08-25
    浙江
  • 本文字数:8054 字

    阅读完需:约 26 分钟

作者:徐靖峰


关注了阿里云云原生公众号,经常能看到 MSE-Higress 相关的推文,恰逢这次阿里云产品举办了一个 MSE-Higress 云原生网关的测评活动,借此机会体验了一把云原生网关的功能。

购买流程体验


购买网关时,页面明确提示费用没有包含公网和私网 SLB 的费用,这里需要注意,评测时会产生额外费用,同时也建议 MSE-Higress 购买页给出具体的定价,参考 ACK 购买时的体验。

路由管理体验

通过购买页购买后,等了不多久实例便创建完成了,速度还是很快的,这个体验不错。第一个测评内容先体验下网关最主要的功能路由转发的能力,给 MSE-Higress 配置路由 & 服务,访问 httpbin.org 这个公网的服务,熟悉 HTTP 接口测试的同学一定也不会对 httpbin 感到陌生,它内置很多 endpoint,支持丰富的 HTTP 测试场景。


MSE-Higress 的产品设计和领域模型和我之前接触过的一些开源 API 网关差异不大,所以上手还是很快的,首先创建 httpbin 服务:



接着再创建路由,我准备通过 ${网关 ip}/httpbin/get 转发至 httpbin.org/get 的方式来进行路由测试。



匹配方式支持前缀匹配、精确匹配、正则匹配三种,基本覆盖了网关路由场景的常见诉求。另外还需要注意的一点是,路由路径一定要配置成 /httpbin/ 而不能是 /httpbin,否则在待会配置路径重写时,会出现问题,我一开始也是因为不了解 MSE-Higress 的设计,错配成了 /httpbin,导致路由不通。


参考文档:《配置重写策略》 [ 1]


下一步,关联好刚刚创建的服务。



最后在路由的策略配置中,配置重写策略,使得网关在请求 upstream service 时,去掉用于路由匹配的 /httpbin 前缀。



MSE-Higress 提供了一个调试的界面,可以很方便地对路由进行调试,就在我信心满满准备完成第一个测试时,竟然调试报错了:



步骤并不复杂,稍微花了点时间搜索了一下注意事项,定位到了问题,原来配置服务时是有提示的:"DNS 域名配置,如 www.aliyun.com,公网域名需要在 VPC 内配置公网 NAT 网关,内网域名暂不支持",于是给 MSE-Higress 所在的 VPC 配置了 NAT 网关,最终调用成功。


➜ ~ curl 101.xx.166.xx/httpbin/get{ "args": {}, "headers": {  "Accept": "*/*",  "Host": "101.xx.166.xx",  "Original-Host": "101.xx.166.xx",  "Req-Start-Time": "1691746441214",  "User-Agent": "curl/7.64.1",  "X-Amzn-Trace-Id": "Root=1-64d60089-5f09b9560522afd56f11b4e0",  "X-Envoy-Attempt-Count": "1",  "X-Envoy-External-Address": "140.xx.11.xx",  "X-Envoy-Original-Path": "/httpbin/get" }, "origin": "140.xx.11.xx, 121.xx.116.xx", "url": "http://101.xx.166.xx/get"}
复制代码


期间还有一个小插曲,反复保存服务,会触发一个前端的 bug,保存按钮一直在转圈,测评期间稳定复现:


路由策略-限流功能体验

刚刚在测评路由功能时,已经使用到了 MSE-Higress 的一个策略:重写策略,MSE-Higress 共支持 6 种路由策略,分别是:限流、重写、Header 设置、跨域、超时、重试,第二个测评我计划给到另外一个网关场景中常用的功能 -- 限流。


创建限流策略时发现界面有组件嵌入的痕迹,跟其他策略的配置交互体验有一定差异,盲猜是不是前端嵌入了什么已有的界面。产品支持按照 QPS 进行限流,为了方便测评,设置为 1,更容易触发限流。



通过行为管理,可以跳转到应用高可用服务 AHAS 的管理界面,看起来是内部集成了应用高可用服务 AHAS,复用了它的限流能力,专业的事情交给专业的产品来做。



通过一个 shell 脚本进行限流测试:


#!/bin/bashfor i in {1..5}docurl 101.xx.166.xx/httpbin/get &donewait
复制代码


验证限流成功。


sentinel rate limited{  "args": {},  "headers": {    "Accept": "*/*",    "Host": "101.xx.166.xx",    "Original-Host": "101.xx.166.xx",    "Req-Start-Time": "1691747565429",    "User-Agent": "curl/7.64.1",    "X-Amzn-Trace-Id": "Root=1-64d604ed-6dc526617e735d4f0f083e86",    "X-Envoy-Attempt-Count": "1",    "X-Envoy-External-Address": "140.xx.11.xx",    "X-Envoy-Original-Path": "/httpbin/get"  },  "origin": "140.xx.11.xx, 121.xx.116.163",  "url": "http://101.xx.166.xx/get"}sentinel rate limitedsentinel rate limitedsentinel rate limited
复制代码


问题记录:限流监控的页面不太稳定,间断出现控制台请求报错,需要优化。


EDAS 微服务集成体验

MSE-Higress 对微服务能力的集成是其亮点之一,除 HTTP 协议族外,还支持 Dubbo 和 gRPC 协议。EDAS 常用于进行微服务应用的托管,MSE-Higress 也对 EDAS 进行了适配,这个测评 case 的内容便是,在 EDAS 中部署一个同时集成了 SpringCloud Alibaba (用于测试 HTTP 协议)和 Dubbo (用于测试 Dubbo 协议)的微服务应用,使用 MSE-Higress 对该应用进行接口代理。

EDAS 应用部署

准备一个 Dubbo 服务:


package moe.cnkirito.sca.provider;
import java.util.List;import java.util.Map;
public interface IHelloService {
String sayHello(String str);
String sayHello();
String sayHello(List<String> name);
String sayHello(List<String> name, Integer age);
String sayHello(List<People> name, String first);
String sayHello(People name);
String sayHello(Map<String, Integer> map);
String sayHello(Integer age);
}
复制代码


准备一个 RestController:


@RestControllerpublic class DemoController {
@Autowired DemoService demoService;
@RequestMapping(value = "/echo", method = RequestMethod.GET) public String echo() { return "Hello MSE-Higress"; }
}
复制代码


配置应用信息并连接 EDAS 注册中心:


spring: application:  name: sc-dubbo-mixed-app cloud:  nacos:   discovery:    server-addr: edas-registry:8848 # EDAS会自行替换该连接串
dubbo: application: id: sc-dubbo-mixed-app name: sc-dubbo-mixed-app protocol: id: dubbo port: 20880 registry: id: nacos address: nacos://edas-registry:8848 # EDAS会自行替换该连接串
复制代码


部署到 EDAS 中,在 EDAS 应用管理的服务列表菜单,确认该应用启动完毕。


MSE-Higress 创建来源

MSE-Higress 为了更好地支持微服务的服务发现,抽象出了“来源”这一领域模型,对应微服务架构中的注册中心。



MSE-Higress 的来源支持容器服务、MSE Nacos、MSE Zookeeper、EDAS 注册中心、SAE 注册中心这几种类型,选择 EDAS 注册中心,便能关联到 sc-dubbo-mixed-app 应用部署的微服务空间。

MSE-Higress 创建服务


MSE-Higress 的管控可以直接访问 EDAS 注册中心,获取到了 sc-dubbo-mixed-app 和 providers:moe.cnkirito.sca.provider.IHelloService:1.0.0:default 这两个服务。



检查服务的协议,正确识别到是 Dubbo 协议。



这里不免让我产生了一些疑问,在导入服务时,MSE-Higress 并没有机会让我指定服务的协议类型,在协议详情中却正确识别到了服务的协议,猜测是判断了服务的命名格式,因为 Dubbo 类型服务注册到 Nacos 中格式形如 providers:xx:xx:xx,产品上采用了约定大于配置的设计。

MSE-Higress 创建路由

SpringCloud 服务提供的是标准的 HTTP 协议,上面的路由管理测评已经覆盖,不再次测评,重点看下 HTTP2Dubbo 是如何配置路由的。这部分内容没有办法望交互生义,还是得对着文档一步步来:《配置从 HTTP 到 Dubbo 协议转换》 [ 2]


配置如下:


MSE-Higress 路由调试

测试 Dubbo 路由:



测试 SpringCloud 路由:


EDAS 微服务集成总结

该测评介绍了由 EDAS 托管的 SpringCloud 和 Dubbo 应用,可以很方便地被 MSE-Higress 集成,由 MSE-Higress 充当网关代理,将微服务暴露到集群外被访问,虽然这次测评没有涉及,但理论上还可以借助于 MSE-Higress 提供的限流、鉴权、安全防护,来为微服务体系保驾护航,有一定的想象空间。


同时记录下该测评进行时,个人觉得可以优化的地方。

改进建议 1:服务模型的优化

上文有所提及,服务在 MSE-Higress 中的存在感很弱,在我看来服务应该和路由一样,具备很强的定制属性,包括:


  • 协议类型

  • 服务发现层的唯一标识

  • 通信层的唯一标识

  • 负载均衡方式

  • 健康检查配置


目前,MSE-Higress 创建服务时,仅支持指定“服务发现层的唯一标识”,其他属性不支持在创建时指定,协议类型和负载均衡方式允许在服务详情页中进行修改,健康检查允许在服务列表页进行修改。


对于“通信层的唯一标识”稍作解释,以 Dubbo 为例,providers:moe.cnkirito.sca.provider.IHelloService:1.0.0:default 是其在 Nacos namespace 中的唯一定位符,用于服务发现,而服务名 moe.cnkirito.sca.provider.IHelloService,版本 1.0.0,分组 default 则是其在通信层的唯一标识,也应当是服务的属性,但是在 MSE-Higress 中,则是服务绑定路由时的配置,有点归属于路由模型的感觉,这点设计欠妥。

改进建议 2:Dubbo 协议转换的优化

上述的测评过程中,介绍了一个 Dubbo 协议转换的配置过程,既然已经识别到了是 Dubbo 服务的格式,可以自动解析出 Dubbo 服务的三元组进行填充。



另外,方法映射的设计让我产生了一些疑惑,不清楚是技术原因导致,还是产品设计有意为之,因为在我的认知中,方法级别可以在请求中动态指定,试想一个应用有 n 个服务,一个服务有 m 个接口,完全暴露需要配置 n x m 次。从技术侧考虑,Dubbo 提供的泛化调用可以支持动态指定方法,无需配置参数列表类型。保持这个设计,能够想到的好处是可以允许部分接口暴露,这又回到了那个永恒的话题:安全和易用性的 trade off。


再参考 MSE-Higress 对 gRPC 协议转换的支持,则是另外一个形态:,请求路径为:{包名}.{服务名}/{方法名},而 gRPC 本身则没有在 MSE-Higress 中以一个服务类型体现在产品设计中。MSE-Higress 有能力支持 Dubbo 和 gRPC 类型的协议转换,但是在产品设计上,还有统一优化的空间。


MSE-Higress 对于 gRPC 的支持可以参考:《基于云原生网关实现 gRPC 服务的路由转发》 [ 3]

改进建议 3:EDAS 注册中心类型支持优化


EDAS 微服务空间背后有两种形态,一种是共享型注册中心的形态,另一种是绑定 MSE Nacos 实例的形态,上述演示时,主要测试了第一种形态,对于第二种形态,MSE-Higress 的支持有些兼容性问题,具体表现为: EDAS 微服务空间绑定的 MSE Nacos 位于 vpc-a 中,MSE-Higress 位于 vpc-b 中,创建来源能够成功,但导入服务时,页面报错:



这背后应该是在支持 EDAS 注册中心时,未考虑其绑定的 MSE Nacos 位于其他 vpc 导致。建议在导入来源时对该 case 进行判断。

插件市场体验

插件体系功能较多,个人精力有限,我只挑选了个别插件进行了使用,表现均符合预期。我挑选了 APISIX 的插件支持情况与 MSE 进行了对比,由于 APISIX 是一款开源产品,我有意筛选的都是一些相对通用的能力,这样才具备比较价值。



除了表格展示的插件之外,两款网关产品还支持很多其他插件,可以发现基本上常见的网关场景所需要的插件,MSE-Higress 都是支持的。与 APISIX 的设计不同,MSE-Higress 并没有将所有功能都堆到插件这一概念上,例如 Mock 和重定向由路由配置控制,跨域和限流通过路由策略控制,也有相当多的功能通过插件提供,在这一点上,我比较认可 MSE-Higress 的设计,这样可以减少网关使用者的理解成本。


但同时,在策略配置灵活度上,MSE-Higress 的设计仍有优化空间,以限流为例,由于其被抽象到了路由策略这一模型中,而该模型没有支持配置到消费者级别,这就让 MSE-Higress 失去了消费者级别限流的能力。


在商业化集成上,由于 MSE-Higress 是阿里云官方提供的一款网关产品,还额外提供了诸如:waf 安全防护、edas 鉴权插件、IDaaS 认证鉴权等集成,在公共云组装式开发的模式下,可以更好地跟已有的云产品联动,这是相比开源网关提供的插件能力最大的优势。

EDAS x MSE-Higress 金丝雀发布体验

MSE-Higress 在配置路由时,允许关联到多个服务,借助于这个特性,可以完成很多灰度的实践,这个测评将验证 MSE-Higress 和 EDAS 配合完成金丝雀发布的场景。


金丝雀的意义是先引流一小部分流量到新版本服务,大部分流量仍然保持在旧版本。


仍然使用之前的 sc-dubbo-mixed-app 应用,但需要稍作改造,为 SpringCloud 和 Dubbo 服务引入版本的概念,参考《管理服务版本》 [ 4] 一节,可知在 Nacos 服务发现场景下,MSE-Higress 是通过节点标签来进行路由的,以下是我的改造。

EDAS 部署 V1 版本

SpringCloud 服务引入版本:


spring: application:  name: sc-dubbo-mixed-app cloud:  nacos:   discovery:    server-addr: edas-registry:8848 # EDAS会自行替换该连接串      metadata:      x-version: v1
复制代码


@RestControllerpublic class DemoController {  @Autowired  DemoService demoService;
@RequestMapping(value = "/echo", method = RequestMethod.GET) public String echo() { return "Hello MSE-Higress V1"; }}
复制代码


Dubbo 服务引入版本:


@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v1"})public class IHelloServiceImpl implements IHelloService {  @Override  public String sayHello() {    return "Hello MSE-Higress V1";  }}
复制代码


在 EDAS 上部署以上版本,并扩容成 2 个副本,此时两个副本内容一致。

EDAS 分批部署 V2 版本

SpringCloud 服务新版本:


@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v1"})public class IHelloServiceImpl implements IHelloService {  @Override  public String sayHello() {    return "Hello MSE-Higress V1";  }}
复制代码


@RestControllerpublic class DemoController {
@Autowired DemoService demoService;
@RequestMapping(value = "/echo", method = RequestMethod.GET) public String echo() { return "Hello MSE-Higress V2"; }}
复制代码


Dubbo 服务新版本:


@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v2"})public class IHelloServiceImpl implements IHelloService {
@Override public String sayHello() { return "Hello MSE-Higress V2"; } }
复制代码


在 EDAS 进行分批发布:



这里解释下,为什么不使用 EDAS 的金丝雀发布,因为 EDAS 金丝雀发布主要是用于微服务之间的调用,而不是入口流量,而此次测评的恰恰是 MSE-Higress 对 EDAS 应用进行的调用,在这个 case 中,EDAS 需要做的是分批发布,保证后端同时有 v1 和 v2 两个版本即可。


这样就完成了金丝雀发布的准备工作,同时存在了 v1 和 v2 两个版本的应用,剩下的就是对 MSE-Higress 进行配置,让其按照特定比例对这两个版本进行引流(试想一下,如果没有金丝雀发布,由于 v1 和 v2 都是一台机器,那流量比例应该是 1:1)。

MSE-Higress 配置服务版本和标签路由

在服务详情中,可以添加服务版本,这里 MSE-Higress 的体验做的很好,由于关联了注册中心,可以自动获取到对应的标签名和标签值,能够实时计算出对应的节点数量,不用担心配错了。



需要修改路由关联服务的方式,从单服务改成标签路由,并配置 v1 和 v2 版本流量比例为 80:20。



走到这一步,我发现标签路由怎么都选不到 Dubbo 服务,才注意到上方有提示“多服务和标签路由功能不支持添加 Dubbo 服务”!也就是说我之前的 Dubbo 服务打标签的准备工作都白费了,但我还是将测评过程记录了下来。

流量比例测试

通过调试 /sc-dubbo-mixed-app/echo 10 次,观察返回值:


Hello MSE-Higress
Hello MSE-Higress
Hello MSE-Higress
Hello MSE-Higress V2
Hello MSE-Higress
Hello MSE-Higress
Hello MSE-Higress
Hello MSE-Higress V2
Hello MSE-Higress
Hello MSE-Higress
复制代码


符合预期。

测试总结

通过上述的例子,可以发现 MSE-Higress 和 EDAS 应用在 Nacos 服务发现场景下实现金丝雀发布还是很简单的,但从中也看出了一些问题,就是产品仅告诉了用户怎么达到金丝雀发布的验证态,没有走完最后一公里,即金丝雀发布验证到什么阶段可以认为发布完毕了,发布完之后,怎么完成 EDAS 的分批发布,怎么修改标签路由,达到一个运行终态。并且,这个流程配置还是很复杂的,要结合到用户的运维系统中,有一定集成工作,至少应该在 EDAS 这样的系统中提供一个基于 MSE-Higress 金丝雀发布入口应用的最佳实践。

体验总结

大概浏览了下 MSE-Ingress 的其他功能,精力有限加上篇幅限制,没法一一罗列,简单总结下。


MSE-Higress 除了文章开头的购买流程外,还支持作为一个 ACK 集群的 Ingress 网关,这得益于其云原生的基因,并且可以对标到 Nginx Ingress,这对于愿意拥抱云原生生态的公司是一个福音,我这次就不单独评测这一功能了。


文档支持上,我本次的测评完全是参考控制台文案及文档完成,可以看的出来,文档体系相对比较完善,一些常见的疑问,也都在文档中高亮了,点赞。需要注意的是一些新功能上线之后,需要对已有的相关文档进行更新,以《从 Spring Cloud Gateway 迁移到云原生网关》 [ 5]  为例,目前已经支持了 EDAS 共享注册中心来源了,对于文档中使用 EDAS 共享注册中心这一 case 而言,就不需要先迁移了,可能会让 SpringCloud Gateway 迁移用户产生误解。


MSE-Higress 可以很好地承担安全网关和流量网关的作用,但对于是否能够很好的承担起微服务网关/业务网关的作用,我觉得有待讨论。因为业务网关很直接的诉求是将企业内部的大量 API 通过网关暴露出来,MSE-Higress 的领域模型是路由/服务这套模型,这就限制于了其对于业务能力的抽象,路由大多数时候还是一个泛接口的作用,往往用于承接一个后端应用模型。从用户形态来看,可能是偏运维侧的用户会关注目前的 MSE-Higress 形态,而不是开发。


如果深入使用 MSE-Higress,可能会有精细化管理 API 接口的诉求,目前 MSE-Higress 的产品设计似乎不能很好地满足这一诉求,具体表现为 MSE-Higress 的路由模型和 API 精细化管理的需求之间的矛盾。MSE-Higress 的路由模型如果配置为泛路由 /order/* 的前缀匹配模式,则会将应用的所有接口暴露出去;如果配置为 /order/createOrder 的精确匹配模式,可以达到精细化管理的诉求,但接口级别常见的需求 API 出入参定义、参数映射、错误码管理,跟路由的模型无法很好的适配。这可能是大多数研发用户使用 MSE-Higress 未来可能面临的问题。


整体而言,我还是很看好 MSE-Higress 这款产品的。 产品界面交互还时髦,大多数操作流程很流畅;产品集成上,从它跟 WAF、EDAS、ACK 等产品的集成来看,可以看出阿里云对它的定位不仅仅是一个网关组件,而是希望能够借助它完成一个产品生态的构建,云原生公众号上 Serverless 挺火的,MSE-Higress 还不支持 Serverless 服务,这点倒是有点意外。同时它还具备 Higress 的开源属性,也解决了一部分选型时被阿里云绑死的顾虑。




参与云原生网关 MSE-Higress 测评赢大奖


2023 年 8 月 10 日-2023 年 9 月 15 日,通过体验 MSE-Higress,围绕三大主题,进行测评创作,有机会赢取 30 元猫超卡、米家台灯 Lite、CHERRY 机械键盘 MX3.0S 等大奖。


评测活动详情:阿里云产品测评赢大奖丨云原生网关 MSE-Higress


相关链接:


[1] 《配置重写策略》


https://help.aliyun.com/zh/mse/user-guide/configure-a-rewrite-policy


[2] 《配置从 HTTP 到 Dubbo 协议转换》


https://help.aliyun.com/zh/mse/user-guide/configure-http-to-dubbo-protocol-conversion**


[3] 《基于云原生网关实现 gRPC 服务的路由转发》


https://help.aliyun.com/zh/mse/getting-started/route-the-traffic-of-grpc-applications-based-on-cloud-native-gateways


[4] 《管理服务版本》


https://help.aliyun.com/zh/mse/user-guide/manage-service-versions


[5] 《从 Spring Cloud Gateway 迁移到云原生网关》


https://help.aliyun.com/zh/mse/user-guide/migrate-services-from-spring-cloud-gateway-to-cloud-native-gateways

发布于: 刚刚阅读数: 5
用户头像

阿里云云原生 2019-05-21 加入

还未添加个人简介

评论

发布
暂无评论
说点大实话丨知名技术博主 Kirito 测评云原生网关_阿里云_阿里巴巴云原生_InfoQ写作社区