博主介绍：✌全网粉丝4W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌

博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦

🍅开源项目免费哦：点击这里克隆或者下载，已经发布Vue3版 🍅

🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟

Java项目案例《100套》
https://blog.csdn.net/qq_57756904/category_12173599.html

uniapp小程序《100套》

✨【微服务】Nacos为什么丢弃短连接(http)而选择拥抱长连接(gRPC)

一、服务网格明星产品 Istio

1、什么是 Istio

2、Istio 的基本架构

二、Nacos 服务网格生态演进

1、传统微服务架构下的 Nacos

2、服务网格时代的 Nacos

三、Nacos 服务网格生态在阿里大规模落地实践

💖微服务实战

一、服务网格明星产品 Istio

1、什么是 Istio

Istio 是一个由 Google，IBM 和 Lyft 团队合作开发的开源项目，它用来连接、保护、控制和观察集群中部署的服务。目前比较火热的云原生技术 ServiceMesh ，其中一套比较流行的方案就是采用 Istio + Envoy 实现的。Envoy 作为代理以 SideCar 形式和应用服务部署在一起，透明拦截应用服务所有的入口流量和出入流量，在转发流量之前执行一些额外的治理策略，这些操作都是对业务服务透明的，无感知的。这样一来，如果我们把与业务应用耦合的服务治理相关 SDK 的功能下沉到 SideCar，那么业务代码就会与服务治理代码解耦，并且可以并行迭代发展。从这个角度看，ServiceMesh 提供了应用层面上网络通信的基础设施层，对其上的流量执行用户配置的治理策略。定义并下发这些治理策略的角色就是 Istio。

我们都知道 K8s 改变了传统的应用部署发布的方式，给容器化的应用服务提供了灵活方便的容器编排、容器调度和简单的服务发现机制，但缺少了更丰富和更细粒度的服务治理能力。而 Istio 的出现正是为了弥补 K8s 在服务治理上的不足，它定义一套标准 API 来定义常见的治理策略。

从我的角度和理解来看，K8s 与 Istio 呈互补关系，共同决定了业务应用的部署、发布以及运行时的行为。

网关处于集群的边缘，控制着集群的出入流量，可以看做是 Envoy 代理的独立部署，代理的是整个集群。

2、Istio 的基本架构

Istio 项目是基于 Kubernetes 运维平台构建的云原生新一代的服务治理框架，其架构图如下，

其中主要涉及到数据面的代理服务 Proxy，集群入口网关 Ingress、集群出口网关 Egress 以及核心控制面Istiod。各个组件的功能如下：

代理服务 Proxy 采用的 Lyft 公司开源的高性能 C++ 网络代理 Envoy，拦截业务的所有出入流量。
入口网关 Ingress，作为集群的访问入口，控制着集群内部服务如何安全的暴露出去，并对所有入口流量进行统一控制和观测。
出口网关 Egress，作为集群的访问出口，控制着集群内部服务如何安全的访问外部服务。
核心控制面 Istio 负责对所有数据面的代理服务（包括 Ingress、Egress 网关）下发服务发现信息，流量治理配置，以及用于服务之间进行双向认证的TLS证书。

可以看出 Istiod 是微服务领域的集大成者，覆盖了服务发现、服务治理、认证鉴权和可观测，以无侵入的方式为微服务体系架构的业务提出了云原生时代下新的解决方案。

二、Nacos 服务网格生态演进

Nacos 为了融入服务网格生态，完成了一次从微服务1.0架构到服务网格架构的演进架构。

1、传统微服务架构下的 Nacos

我们先看下传统微服务架构下的 Nacos，其流量从 Tengine 进入，经过微服务网关，然后再进入微服务体系。

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

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

传统微服务架构下的 Nacos 存在以下几个问题：

Tengine 不支持动态配置，包括开源的 Nginx 原生也是不支持的，阿里内部是定期 reload 配置的方式实现配置变更，这导致配置不能及时变更，影响研发效率；
Fat SDK 模式下，服务治理、服务发现等逻辑与 SDK 强耦合，如果需要变更逻辑，就得修改 SDK，推动业务方升级；
多语言下需要维护不同语言的 SDK，成本高，服务治理策略难以统一;

2、服务网格时代的 Nacos

随着云原生技术的发展和微服务 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 飙高等问题。

💖微服务实战

✨【微服务】SpringCloud的OpenFeign与Ribbon配置

✨集Oauth2+Jwt实现单点登录

✨Spring Cloud Alibaba微服务第29章之Rancher

✨Spring Cloud Alibaba微服务第27章之Jenkins

✨Spring Cloud Alibaba微服务第24章之Docker部署

✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式

✨Spring Cloud Alibaba微服务第22章之Oauth2

✨Spring Cloud Alibaba微服务第21章之分布式事务

✨Spring Cloud Alibaba微服务第18章之消息服务

✨Spring Cloud Alibaba微服务第16章之服务容错

✨Spring Cloud Alibaba微服务第14章之分库分表

✨Spring Cloud Alibaba微服务第11章之MyBatis-plus

✨Spring Cloud Alibaba微服务第8章之OpenFeign

✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon

✨SpringCloud Alibaba微服务第6章之Gateway

✨SpringCloud Alibaba微服务第4章之Nacos

✨SpringCloud Alibaba微服务开篇