免费网站营销计划,西安凡高网络,榆林网站建设公司,wordpress自适应汉化主题简介#xff1a; Nacos 在阿里巴巴起源于 2008 年五彩石项目#xff08;该项目完成微服务拆分和业务中台建设#xff09;#xff0c;成长于十年的阿里双十一峰值考验#xff0c;这一阶段主要帮助业务解决微服务的扩展性和高可用问题#xff0c;解决了百万实例扩展性问题 Nacos 在阿里巴巴起源于 2008 年五彩石项目该项目完成微服务拆分和业务中台建设成长于十年的阿里双十一峰值考验这一阶段主要帮助业务解决微服务的扩展性和高可用问题解决了百万实例扩展性问题10w-100w实例。2018 年我们深刻感受到开源软件行业的影响因此决定将 Nacos 开源输出阿里十年关于服务发现和配管管理的沉淀推动微服务行业发展加速企业数字化转型。
作者怀成 Nacos committer
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 gatewayzuul等都属于微服务网关。
流量进入微服务体系后会通过微服务框架实现服务间的调用比如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和控制面IstioEnvoy以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协议实现网络通讯网关的控制面都使用的是IstioIstio会通过MCP协议从Nacos同步服务列表数据。
使用这个架构解决了两个问题
1、私有云和公有云网络通讯安全问题因为网关之间使用mtls加密通讯
2、平滑支持微服务架构因为应用通过triple协议调用网关不需要业务做代码改动服务发现则是通过Nacos mcp去同步数据
这套架构同时也用于蚂蚁集团互通的场景就是这张图的左边蚂蚁的网关使用的是Mosn on Envoy的架构。
场景二
集团的微服务mesh化场景对应这张图的中下部分内部落地与社区的差异点是Envoy直接对接了Nacos注册中心使用这个方案主要还是考虑到性能问题我们有些应用会有几万的实例ip如果通过EDS推送因为数据量过大会导致Istio OOM或者Envoy数据面cpu飙高等问题。
原文链接
本文为阿里云原创内容未经允许不得转载。
