如何用 Nacos 构建服务网格生态

Nacos 简介

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称。目标是构建一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 在阿里巴巴起源于 2008 年五彩石项目(该项目完成微服务拆分和业务中台建设),成长于十年的阿里双十一峰值考验,这一阶段主要帮助业务解决微服务的扩展性和高可用问题,解决了百万实例扩展性问题(10w->100w实例)。2018 年我们深刻感受到开源软件行业的影响,因此决定将 Nacos 开源,输出阿里十年关于服务发现和配管管理的沉淀,推动微服务行业发展,加速企业数字化转型。

随着近几年云原生技术的发展,服务网格技术的提出,越来越多的公司尝试将微服务架构迁移到服务网格架构,这对Nacos也提出了一个新的诉求,那就是如何更好的支持服务网格生态。 在这里插入图片描述

Nacos无缝支持服务网格

我们先看下微服务1.0下的架构,流量从Tengine进来,经过微服务网关,然后再进入微服务体系。

这里解释下为什么分了两层网关,第一层Tegine是负责流量的接入,核心具备的能力是抗大流量、安全防护和支持https证书,追求的是通用性、稳定性和高性能。第二层是微服务网关,这层网关侧重的是认证鉴权、服务治理、协议转换、动态路由等微服务相关的能力,比如开源的spring cloud gateway,zuul等都属于微服务网关。

流量进入微服务体系后,会通过微服务框架实现服务间的调用,比如hsf/dubbo、spring cloud等等,那么Nacos在这里起到的核心作用是服务发现能力,比如cousumer会先从Nacos获取provider的服务列表地址,然后再发起调用,还有微服务网关也会通过Nacos获取上游的服务列表。这些能力主要通过SDK的方式提供,同时也会在SDK上增加一些负载均衡、容载保护的策略。

在这里插入图片描述

微服务1.0架构主要存在以下几个问题:

1、Tengine不支持动态配置,包括开源的Nginx原生也是不支持的,阿里内部是定期reload配置的方式实现配置变更,这导致配置不能及时变更,影响研发效率;

2、Fat SDK模式下,服务治理、服务发现等逻辑与SDK强耦合,如果需要变更逻辑,就得修改SDK,推动业务方升级;

3、多语言下需要维护不同语言的SDK,成本高,服务治理策略难以统一; ​

随着云原生技术的发展和微服务2.0架构的提出,很多公司正在尝试通过服务网格技术去解决微服务1.0架构中的问题。在微服务架构2.0架构中,流量是通过 ingress 网关接入的,进入微服务体系,与1.0架构不同的是引入了数据面Envoy和控制面Istio,Envoy以Sidecar模式与应用部署在同一个Pod中,会劫持应用的进出流量,然后可以通过控制面Istio下发的XDS配置实现流量控制、安全、可观测能力,这一架构的优势是将服务治理能力与业务逻辑解耦,把服务框架中SDK大部分能力剥离出来,下沉到Sidecar,也实现了不同语言的统一治理。 在这里插入图片描述

服务网格技术优势非常多,但是新架构的引入也会带来新的问题,尤其是对于技术包袱比较重的公司,将面临的问题,比如:sidecar性能问题、私有协议支持问题、新旧架构体系如何平滑迁移等等。

本文主要关注新旧架构体系平滑迁移这个问题,平滑迁移必然会面对的两个关于服务发现的问题:

1、新旧架构体系如何互相发现,因为迁移过程必然存在两个体系共存的情况,应用需要互相调用;

2、注册中心如何支持微服务网格生态,因为istio目前默认支持的是k8s的service服务发现机制; ​

我们看下在Nacos服务网格生态下是如何解决这些问题,架构图如下,流量是从云原生网关(云原生网关,它具备的特点是与微服务架构保持兼容,既支持微服务网关,同时又能符合云原生架构,支持K8s标准的ingress网关)进来,然后进入微服务体系,微服务体系中1.0应用(非mesh化应用)和已经mesh化的应用共存。 在这里插入图片描述

先看下非mesh化应用是如何访问已经mesh化的应用, 从这个架构图可以看到非mesh化的应用还是通过SDK方式从Nacos进行服务注册或者服务订阅,已经mesh化的provider也会注册到Nacos上,这样非mesh化的应用也能获取到已经mesh化的应用服务信息,provider注册服务一般是通过sdk方式,因为开源envoy不支持代理注册功能,当然我们阿里内部实现的时候,其实已经把服务注册的能力下沉到sidecar。

另一个问题,mesh化的应用的服务发现是怎么做的。我们可以看架构图的下面这部分,Nacos已经支持了MCP server的能力,Istio是通过MCP协议从Nacos获取全量的服务信息列表,然后再转化成XDS配置下发到envoy,这样即支持了mesh化应用内的服务发现,也能访问非mesh化的服务,业务在mesh化过程中服务发现不需要做任何改造,就能无缝迁移。 ​

这里简单介绍下MCP协议,MCP协议是Istio社区提出的组件之间配置同步协议,这个协议在1.8之后就废弃了,替代方案是MCP over XDS协议,Nacos两个协议都兼容。

除了MCP协议同步方案外,也有其它方案实现注册中心的服务数据同步到ServiceMesh体系,我们对这些方案做了对比,如下图描述:

在这里插入图片描述

Nacos服务网格生态阿里落地实践

最后给大家介绍下阿里巴巴Nacos服务网格生态的实践,下面这张图总体概括了阿里落地的两个场景。 在这里插入图片描述

场景一: 钉钉云上和集团互通的场景,本质其实就是混合云场景下的应用互通,我们是用了网关去打通这两个环境,钉钉vpc(阿里云部署)这边用的是MSE云原生网关,集团用的是Envoy网关,他们之间使用Dubbo3.0的triple协议实现网络通讯,网关的控制面都使用的是Istio,Istio会通过MCP协议从Nacos同步服务列表数据。

使用这个架构解决了两个问题:

1、私有云和公有云网络通讯安全问题,因为网关之间使用mtls加密通讯; 2、平滑支持微服务架构,因为应用通过triple协议调用网关,不需要业务做代码改动,服务发现则是通过Nacos mcp去同步数据; 这套架构同时也用于蚂蚁集团互通的场景,就是这张图的左边,蚂蚁的网关使用的是Mosn on Envoy的架构。 ​

场景二: 集团的微服务mesh化场景,对应这张图的中下部分,内部落地与社区的差异点是,Envoy直接对接了Nacos注册中心,使用这个方案主要还是考虑到性能问题,我们有些应用会有几万的实例ip,如果通过EDS推送,因为数据量过大,会导致Istio OOM或者Envoy数据面cpu飙高等问题。

本次直播回放地址:https://yqh.aliyun.com/live/detail/26211,也可扫描看钉钉群直播回放。

在这里插入图片描述

阿里云MSE云产品已经完成Nacos服务网格生态集成,欢迎上手体验,地址: https://www.aliyun.com/product/aliware/mse

{{o.name}}


{{m.name}}

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/112224.html

(0)
上一篇 2021年8月27日
下一篇 2021年8月27日

相关推荐

发表回复

登录后才能评论