简介： 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 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飙高等问题。

原文链接

本文为阿里云原创内容，未经允许不得转载。