简介：Nacos 在阿里巴巴起源于 2008 年五彩石我的项目（该我的项目实现微服务拆分和业务中台建设），成长于十年的阿里双十一峰值考验，这一阶段次要帮忙业务解决微服务的扩展性和高可用问题，解决了百万实例扩展性问题（10w->100w 实例）。2018 年咱们粗浅感触到开源软件行业的影响，因而决定将 Nacos 开源，输入阿里十年对于服务发现和配管治理的积淀，推动微服务行业倒退，减速企业数字化转型。随着近几年云原生技术的倒退，服务网格技术的提出，越来越多的公司尝试将微服务架构迁徙到服务网格架构，这对 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 架构次要存在以下几个问题：
- Tengine 不反对动静配置，包含开源的 Nginx 原生也是不反对的，阿里外部是定期 reload 配置的形式实现配置变更，这导致配置不能及时变更，影响研发效率；
- Fat SDK 模式下，服务治理、服务发现等逻辑与 SDK 强耦合，如果须要变更逻辑，就得批改 SDK，推动业务方降级；
- 多语言下须要保护不同语言的 SDK，老本高，服务治理策略难以对立。
随着云原生技术的倒退和微服务 2.0 架构的提出，很多公司正在尝试通过服务网格技术去解决微服务 1.0 架构中的问题。在微服务架构 2.0 架构中，流量是通过 ingress 网关接入的，进入微服务体系，与 1.0 架构不同的是引入了数据面 Envoy 和管制面 Istio。
Envoy 以 Sidecar 模式与利用部署在同一个 Pod 中，会劫持利用的进出流量，而后能够通过管制面 Istio 下发的 XDS 配置实现流量管制、平安、可观测能力，这一架构的劣势是将服务治理能力与业务逻辑解耦，把服务框架中 SDK 大部分能力剥离进去，下沉到 Sidecar，也实现了不同语言的对立治理。
服务网格技术劣势十分多，然而新架构的引入也会带来新的问题，尤其是对于技术包袱比拟重的公司，将面临的问题，比方：sidecar 性能问题、公有协定反对问题、新旧架构体系如何平滑迁徙等等。
本文次要关注新旧架构体系平滑迁徙这个问题，平滑迁徙必然会面对的两个对于服务发现的问题：
- 新旧架构体系如何相互发现，因为迁徙过程必然存在两个体系共存的状况，利用须要相互调用；
- 注册核心如何反对微服务网格生态，因为 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 飙低等问题。
本文是 Nacos 服务网格生态直播的文本整顿，残缺直播内容能够参看：https://yqh.aliyun.com/live/detail/26211
Nacos 源代码仓库：https://github.com/alibaba/nacos
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。