博主介绍：✌全网粉丝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套》
目录
一、背景
在传统的基于虚拟机的部署方式中，运维人员需要手动上传应用程序压缩包到虚拟机上，经过解压、安装和运行等⼀系列操作之后才能完成应用发布。除了需要手动部署之外，运维人员还要时刻关注虚拟机资源分布和容量情况，不同的业务应用需要人工分配并部署在资源充足的虚拟机上。在如今云原生时代，基础设施平台 Kubernetes 对底层资源 （计算、储存、网络）进行了统⼀抽象，为应用容器化部署奠定了坚实的基础。通过 Kubernetes 提供的声明式 API 资源，运维人员只需声明业务应用所期望的资源状态即可，由 Kubernetes 调度器自动分配节点。这种自动化运维方式不仅可以减轻运维部署的负担，而且增加了业务运行时的弹性。
Kubernetes 在应用打包、部署、调度和弹性领域是绝对的王者，吸引了无数互联网公司开启了应用容器化改造之旅。在这迁移过程中，人们渐渐发现虽然服务运行时的底层依赖可以切换到 Kubernetes 平台，但整个业务系统依赖的配置中心、注册中心、网关、消息队列、认证鉴权、可观测等服务治理组件并不能被 Kubernetes 生态完全替代。⼀方面，这些传统的中间件经历了时间和历史的重重考验，沉淀出高性能、高可用和高扩展的经验是毋容置疑的；另⼀方面，Kubernetes 对于应用依赖平台之上的能力的支持度是不够的，比如服务治理、网关、认证鉴权，可观测，等等。⼀时间，围绕 Kubernetes 平台构建的覆盖各个领域的产品层出不穷，它们都是从 Kubernetes 其中⼀个薄弱点切入，进行深度集成。传统的中间件也不甘示弱，打着拥抱云原生、拥抱 Kubernetes 生态的旗号，纷纷开启并进入下⼀代的改革，捍卫自身在擅长领域的王者地位。
在服务治理领域，服务网格的概念呼声非常高，声称是下⼀代微服务治理。服务网格思想是为业务服务的应用层之上再构建⼀层网络基础设施层，负责服务之间的网络通信、动态路由、负载均衡、访问控制等治理策略。将服务治理从与业务紧耦合的 SDK 中剥离出来，将其下沉到基础设施层，以通用的治理能力应对异构的业务系统。这⼀思想，与将底层硬件资源抽象化的 Kubernetes 不谋而和。因此，随着 Kubernetes 平台的不断发展和完善，服务网格概念也逐渐从理论向实践转变。借助于 Kubernetes 提供的先进的容器编排技术，服务网格产品开始进入开发者的视野，并得到了广泛的关注，其中不乏有头部互联网公司已经将服务网格应用在生产环境中。在这些产品当中，由Google，IBM 和 Lyft 团队合作开发的服务网格项目 Istio 最为流行，它提出了⼀整套标准的、声明式的服务治理 API，效仿 Kubernetes 对底层基础设施的抽象做法来解决服务治理层面的疑难杂症。
Nacos 作为众多注册中心产品中最受欢迎之⼀的项目，从开源之初，就紧跟技术时代的潮流，当然不会错过云原生带来的技术红利。Nacos 已深度集成明星产品 Spring Boot、Spring Cloud、Dubbo 等等，到现在积极融入服务网格 Istio 的生态，都在为开发者可以在各种业务场景中使用Nacos 而演进。
二、什么是服务网格
要深入理解服务网格的概念，明确服务网格要解决的问题，以及认识服务网格带来的业务价值，需要从应用架构的演进发展从头开始讲起。
1、单体架构向微服务体系架构的演进
近年来，随着业务体系不断发展和扩大，单体应用已经完成了向微服务架构的转变。应用按照功能维度、业务领域进行了服务拆分，各个不同的业务团队专注于自身负责的服务，每个微服务独立迭代且互相不影响。这种拆分业务域的思想，不仅加快了业务发展速度，而且带来了更敏捷的开发体验。
凡事都有两面性，微服务在提升业务应用的迭代速度和敏捷性的同时，也给服务治理带来了更多的挑战。原先是单体应用，所有的服务都在⼀个进程中，服务之间的调用就是方法调用，整条请求的处理流程就在当前线程中，调试、排查问题非常方便。
改造成微服务架构之后，原先单体中的服务变成⼀个个独立部署运行的服务，方法调用变成了远程调用。首先要解决的问题就是服务发现问题，Consumer 服务如何在运行时发现 Provider 服务，并且独立部署的服务节点的 ip 地址是不固定的，意味着需要⼀种动态发现的能力。注册中心的出现就是来解决微服务架构中服务发现问题，每个微服务在部署发布时会向注册中心登记自己的节点网络 ip，在下线时也会及时向注册中心进行注销操作。同时，每个微服务也会向注册中心订阅自己依赖的其他微服务的节点信息，当订阅的微服务的节点信息发生变化时能够实时收到并更新本地连接池。解决了服务之间如何发现的问题之后，Consumer 服务在处理请求时就可以从注册中心获取的节点信息列表中选择⼀个 ip 地址对 Provider 服务发起网络调用。为了最大化资源利用率，最小化请求RT，需要从节点池中选择出⼀个最佳的节点，这就是负载均衡。如果微服务的副本所占的硬件资源不同时，需要给予硬件资源充足的节点更多的流量。如果微服务的副本所处的地域不同时，需要优先访问与调用端所处地域相同的节点。如果业务有 Session 粘性的诉求，需要同⼀用户的请求始终访问同⼀个节点。如果微服务在启动之后需要预热，需要将流量逐步引流到该节点。
单体应用中的整个调用链在当前进程中，面对突发的流量洪峰，我们只需对应用入口处进行熔断、限流即可。而在微服务架构中，每个微服务独立部署，副本数量根据其功能的重要性会有所不同。在面对高并发的流量请求时，各个服务的熔断限流的阈值应该是不⼀样的。另外，微服务架构增加了整个请求处理链的网络跳数，其中任意⼀个上游服务都可以拖垮下游服务，甚至导致系统整体不可用。在可观测方面，首先是 Tracing，单体架构中服务之间调用不存在网络调用，请求始终在当前节点上处理完毕，任何时候出现故障时都会导致整个应用出故障，因此我们只需排查代码 Bug 即可；而在微服务这种分布式架构中，每条请求的调用链路是不同的、不可预期的，当请求耗时较长、出错时，我们必须通过某种手段来获知整条请求的访问链路，才能知道具体在哪个服务哪个节点上出错，这就是常说的分布式链路追踪。然后是 Logging ，日志能力可以确保请求经过每个服务时将请求的部分元数据信息记录下来，通常与 Tracing ⼀起来排查故障原因。Tracing 定位具体的故障发生节点，Logging 定位具体的故障发生原因。最后，还有⼀个比较重要的可观测技术-- Metrics。单体应用架构中所有服务都共用节点底层资源，⼀般来说只需关注这些节点的状态指标即可；相反在微服务场景中，服务分布在各处，我们不仅要关注节点的资源使用状况，而且对各个服务的连接数、请求数、成功率设置告警规则，以便在服务不可用之前能够及时发现问题，增强整个系统的稳定性建设。
在业务系统中必然存在⼀些敏感的服务，这些服务通常会涉及到交易以及用户敏感数据的变化，因此会严格限制调用方。这个问题在单体架构中几乎不用考虑，因为服务之间的调用是开发者代码控制的，只有有严格的 Code review 和发布流程，就可以规避服务错调用。但是在微服务架构中就会被无限放大，因为服务已经发布到注册中心上，理论上任何能从注册中心获取该服务节点信息的客户端，都可以随意访问这些敏感服务。这时，为了保护敏感服务的安全，通常会利用认证鉴权机制来限制只有特定的客户端才能访问敏感服务。引入⼀个中心化授权系统，由各个敏感服务来授权哪些客户端可以访问，客户端在真正发起请求调用时，需要先从授权系统获取凭证信息，在访问敏感服务时按照规定在特定位置上携带该凭证信息，敏感服务对收到的所有请求进行凭证信息和权限操作校验。只有在身份认证成功以及接口授权列表中含有该身份，敏感服务才会真正开始处理请求，否则拒绝请求。
上面通过⼀些真实的业务场景来详细讨论了微服务架构带来的挑战以及应对方案，基本涵盖了服务治理几大领域，服务发现、负载均衡、熔断限流、监控告警以及认证鉴权。由于篇幅限制，对服务发布、通信安全、动态路由没有详细讨论，但也是最常见的问题。
我们可以用下图来囊括微服务架构所涉及的几大领域。
2、微服务体系架构的传统解决方案
我们在上⼀小节详细介绍了在单体架构向微服务体系架构演进过程中产生的问题与挑战。这时，你可能会疑惑，既然有这么多问题需要解决，为什么业务仍然愿意对应用系统进行拆分改造呢？随着业务规模的增长，产品的功能和技术架构需要不断迭代，单体应用中各子业务之间紧耦合的特点严重阻碍了产品的迭代速度，也带了诸多不稳定因素。而微服务架构下各个服务由不同的业务团队独立负责，这种开发、部署模式上的隔离性大大降低了团队之间的协作门槛，也深度吻合业务高速发展带来的频繁发布问题。
随着互联网的高速发展，各大互联网公司的业务产品日新月异，服务拆分迫在眉睫。开发者⼀边对原单体业务进行拆分，⼀边解决着拆分之后带来的治理问题，期间涌现出⼀大批开箱即用的面向微服务架构的开发框架，如 Java 体系下的 Spring Cloud 和 Dubbo，Golang 体系下的 Gin 等等，这些框架实现了分布式系统通信需要的各种通用的治理功能：如负载均衡、服务发现、熔断、限流、配置管理和认证鉴权，为传统单体应用的改造提供了巨大的便捷。此外，⼀些新业务在项目初期就选择微服务架构体系，借助于各种优秀开源的微服务框架，实现了业务的敏捷开发。
这些开箱即用的框架普遍对业务开发者非常友好，在⼀定程度上屏蔽了大量的底层通信细节和服务治理细节，使得开发人员可以专注于业务开发，同时仅使用较少的框架代码就能开发出健壮的分布式系统。
下图展示了微服务场景中服务之间的调用，业务开发者只需在服务 A 的业务代码中发起对服务 B 的调用，不必关心请求调用的底层是如何实现，比如如何发现服务 B 的地址，如何对服务 B 的负载均衡，如何进行流量控制，协议层的编解码以及底层网络的可靠通信。
这种微服务模式架构看似完美，但也存在⼀些本质问题：
- 框架本身的高学习成本。虽然框架本身屏蔽了分布式系统通信的⼀些通用功能实现细节，但开发者却要花更多精力去掌握和管理复杂的框架本身，在实际应用中，去追踪和解决框架出现的问题也绝非易事。
- 业务与服务治理 SDK 紧耦合。框架以 lib 库的形式和服务联编，复杂项目依赖时的库版本兼容问题非常棘手，同时，框架库的升级也无法对服务透明，服务会因为和业务无关的 lib 库升级而被迫升级，框架频繁的升级会给业务带来不稳定因素。
- 限制业务单⼀的技术栈。开发框架通常只支持⼀种或几种特定的语言，导致新业务在技术选型时不得不选择与公司现有的开发框架有关的语言或中间件，其次，对于那些没有框架支持的语言编写的服务，很难融入面向微服务的架构体系中，想因地制宜的用多种语言实现架构体系中的不同模块也很难做到。
3、下⼀代微服务架构——服务网格
为了解决传统微服务体系架构的上述三种局限性，以 Istio，NginxMesh 为代表的代理模式（边车模式）应运而生，这就是当前微服务架构领域比较火热的服务网格技术——Service Mesh，它将分布式服务的通信层抽象为单独的⼀层，在这⼀层中实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。
从宏观上看，其实现方式为引入⼀个代理服务，以 Sidecar 的方式（边车模式）与每⼀个业务服务部署在⼀起，由代理服务接管服务的所有出入流量。控制面作为核心控制大脑，对所有业务的代理服务（Sidecar）进行统⼀的流量控制和管理。
从微观上看，这个代理服务是通过代理业务服务之间的流量通信间接完成服务之间的通信请求，分布式系统中涉及到的所有服务治理都在代理服务中完成。通过这样⼀个与业务解耦的服务治理层可以轻松解决上边所说的三个问题。
💖微服务实战
✨【微服务】SpringCloud的OpenFeign与Ribbon配置
✨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
💖 Spring家族及微服务系列文章
✨【微服务】SpringCloud中OpenFeign请求处理及负载均衡流程
✨【微服务】SpringCloud中Ribbon的WeightedResponseTimeRule策略
✨【微服务】SpringCloud中Ribbon的轮询(RoundRobinRule)与重试(RetryRule)策略
✨【微服务】SpringCloud中Ribbon集成Eureka实现负载均衡
✨【微服务】SpringCloud轮询拉取注册表及服务发现源码解析
✨【微服务】Nacos2.x服务发现？RPC调用？重试机制？
✨【微服务】SpringBoot监听器机制以及在Nacos中的应用
✨【微服务】SpringCloud中使用Ribbon实现负载均衡的原理
✨【微服务】SpringBoot启动流程注册FeignClient
扫一扫
2288
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
