我们是谁 网站运营,云南建设投资控股集团有限公司网站,网站域名没有实名认证,适合当手机主页的网站服务网络基础 目录 前言
从今天开始我们将进入服务网格的学习#xff0c;服务网格是微服务架构中的一种重要的技术#xff0c;它可以解决微服务架构中的一些问题#xff0c;比如服务发现、服务治理、服务监控等等#xff0c;我们将从服务网格的基础开始#xff0c;逐步深…服务网络基础 目录 前言
从今天开始我们将进入服务网格的学习服务网格是微服务架构中的一种重要的技术它可以解决微服务架构中的一些问题比如服务发现、服务治理、服务监控等等我们将从服务网格的基础开始逐步深入希望能够帮助大家理解服务网格。
1、应用架构的演进
要了解服务网格我们需要从应用架构的演进说起。应用架构的演进过程就需要从单体应用开始说起单体应用的优缺点以及为什么需要拆分应用拆分应用的优缺点以及拆分应用的方式最后引出服务网格的概念。
1.单体应用
在软件开发早期阶段大家都在一个应用系统上开发。各个业务模块之间耦合也比较紧密。软件发布也是整体发布或者对软件进行打包发布和部署比如 java 可以打包成 war 部署。测试也很容易因为代码都在一起基本不需要引用外部的关联服务。
在软件开发早期这种软件开发模式能适应业务的发展软件应用也可以正常运行。如果你的业务发展良好客户需求会变得越来越多软件功能数也会随着客户的需求变多而变多。为了实现这些功能你必须添加很多代码。而随着业务进一步发展代码量势必也会越增越多。有可能 2 到 3 年后软件代码量会变得非常巨大。那时软件就会变成一个非常庞大且复杂的单体应用。软件里面的功能多代码错综复杂。 此时可能出现的问题
打包编译会耗时很久导致发布也很耗时。代码可维护性变差因为代码量大逻辑复杂只有少数老员工能全部理解。代码质量难以保证复用性差等代码腐化严重。修改 BUG 和增加新功能会变得困难可能牵一发而动全身。软件扩展变得困难软件可用性风险增加。可能一个 BUG 导致整个软件不可用。
那么应该如何解决上面的这些问题呢俗话说大事化小 - 拆字诀。 第一步可能想到的就是拆分应用。把一个大型的单体应用按照业务功能进行拆分。比如电商应用可能拆分为商品应用、订单应用、用户应用、商铺应用等等相对比较小的应用功能。
当随着业务规模进一步的发展我们可能还要继续把上面的应用做进一步拆分变成更小的应用以服务的形式对外提供应用服务。应用慢慢的拆分为了比较小的服务 - 微服务。
2.微服务应用
这样应用就变成了微服务应用每个微服务都是一个独立的应用它们之间通过**网络(restful api或者grpc)**进行通信。那么微服务的具体定义是什么呢 grpc进程间通信协议。 维基百科定义微服务 (Microservices) 是一种软件架构风格它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础利用模块化的方式组合出复杂的大型应用程序各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。AWS 的定义微服务是一种开发软件的架构和组织方法其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发从而加速创新并缩短新功能的上市时间。Thoughtworks 首席科学家的定义微服务架构是一种架构模式它提倡将单一应用程序划分为一组小的服务服务之间互相协调、互相配合为用户提供最终价值。每个服务运行在其独立进程中服务与服务之间通常采用轻量级的通信机制相互沟通。每个服务都围绕具体的业务进行构建并且能独立部署到生产环境中。 resilience n.回弹性恢复力 可观测性也是微服务里一个很重要的方面。 虽然不同的组织对微服务的定义不是完全一致的但是它们的核心能力是一致的即将单体应用拆分为多个小型服务每个服务都是一个独立的应用它们之间通过网络进行通信每个微服务都有自己的代码库、数据库和运行环境。 那么在具体的实践中使用微服务架构有哪些优势和劣势呢
优势
应用小可快速编译部署单个微服务维护性变高修改容易因为每个团队独立负责一块功能。新功能交付变快可以快速开发交付扩展性变高根据业务规模可以随时缩减/增加服务器规模可靠性变强可以部署很多独立的服务业务解耦按照业务边界拆分为多个独立的服务模块提升研发效率业务拆分后服务模块变小在一个团队内就可以独立编写、测试、发布加快研发效率。
拆分后单个微服务比较小它只专注于做好一件事情。拆分的指导原则高内聚低耦合。
单一微服务有点像软件设计中的单一职责原则Martin 对单一职责有一个论述把因相同原因而变化的东西聚合到一起而把因不同原因而变化的东西分离开来。
虽然微服务有这么多的好处但是也需要注意的是微服务架构并不是银弹它同样也带来了很多的劣势问题。
劣势
整体复杂度变高从哪些方面来管理这种复杂度运维变得复杂微服务变多怎么监控所有微服务保证服务稳定出了问题怎么定位问题服务管理微服务变多管理复杂度变高治理变得复杂测试方面的挑战你需要结合其他的微服务来进行集成测试分布式问题分布式数据一致性、分布式事务 (尤其在做支付领域这方面更加重要。)服务可用性保障一个服务出了问题如何才能不影响其他服务
根据上面微服务定义这些服务都是由小型独立团队负责那团队怎么划分公司组织架构如何调整才能适应微服务的架构发展这也给组织管理带来了变革的挑战。 例如ddd做微服务的划分。 还有微服务的微多微才是好的微也就是微服务怎么划分如何确定边界等等这些都是微服务面临的问题和挑战。
所以我们在使用微服务架构时需要权衡微服务的优势和劣势任何事物都有正反面就像一枚硬币一样所以思考问题要多样化不能只思考一点。当我们享受微服务给开发和产品带来好处的同时本身也会带来一系列的问题如何克服这些问题才是实施好微服务的关键所在。
随着技术的发展软件架构的不断升级调整上面我们遇到的这些问题大部分是可以解决的。比如需要建立运维开发基础设施来加以保障才能让微服务顺利运行比如需要建设以 CI/CD 为基础的自动化交付流水线到最后建设成从开发、测试、预发布、上线、运维等整个研发流程自动化的 DevOps 为目标。因为随着微服务的逐步建设服务数量增多上线服务次数必然增多交付频繁会带来故障次数增多所以我们必须建设自动化的工具链来帮助我们快速无误的交付服务实施好微服务项目。
而为了解决其他方面的问题比如微服务的服务发现、熔断、降级、限流等等服务治理方面的问题也有专门的技术栈来解决比如 Spring Cloud、Dubbo(阿里的) 等。 Spring Cloud 是在 Spring 基础上构建的Spring 是一个全家桶Spring Cloud 也是一个全家桶它由很多技术框架组合而成包括
Circuit Breakers 断路器。 服务治理 服务注册和发现Netflix Eureka 当然我们也有其他的选择比如 consul、etcd、zookeeper 等 断路器Hystrix 调用端负载均衡Ribbon REST 客户端Feign 网关 API 网关Zuul 当然我们也可以选择其他的比如 Spring Cloud Gateway、kong、nginxlua、apisix 等 分布式链路监控 Spring Cloud Sleuth埋点和发送数据 当然还有其他的比如 zipkin、pinpoint、skywalking(java里面最流行的)、jaeger(golang开发的) 等 消息组件 Spring Cloud Stream Spirng Cloud Bus 消息中间件的其他软件RocketMQ、Kafka、RabbitMQ 配置中心 Spring Cloud Config 配置中心可以有其他的替代比如 Apollo、Nacos 国内比较流行的2种方式 等 安全控制 Spring Cloud Security Spring Cloud 是一整套微服务体系它是一个完整的微服务解决方案Spring Cloud 社区强大也很活跃这也是现在比较主流的微服务技术栈。 但是 Spring Cloud 也有一些缺点比如它是基于 Spring 的所以它的技术栈都是基于 Java 的如果你的团队不是 Java 的那么你可能需要考虑其他的技术栈。另外Spring Cloud 的技术栈比较多学习成本也比较高所以你需要考虑你的团队是否有能力学习和使用 Spring Cloud。Spring Cloud 微服务体系具体还有哪些缺点呢
代码侵入性强 - 业务层中需要加入治理层代码与治理层混淆在一起 很多都是通过注释的方式加入组件多 - 组件多学习成本就变高治理功能不全 - 比如协议转换、动态请求路由、灰度发布等功能 如果想做的话可以把spring cloud部署到k8s里k8s来做灰度等功能无法实现语言无关性 - 只能是一种语言或几种语言实现无法做到与编程语言无关这和微服务架构的初衷是相违背的
针对以上的一些问题就出现了 服务网格(Service Mesh) 这种架构它作为一个基础设施层真正做到与业务解耦与语言无关解决复杂架构下微服务应用与微服务应用之间通信网络相关问题做到与业务解耦让开发者专注于业务开发而不是服务治理相关的问题。
3.服务网格
服务网格是一种基础设施层它由一组网络代理组成这些代理负责管理和协调服务之间的通信。服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能从而简化了微服务架构中的一些问题。 服务网格的代理通常是以 sidecar 的形式部署在每个服务实例旁边。这些 sidecar 代理可以拦截服务之间的通信并提供一些额外的功能例如负载均衡、故障恢复、流量控制等。服务网格还可以提供一些高级功能例如 A/B 测试、金丝雀发 布、蓝绿部署等。
服务网格的一个重要特点是透明性。服务网格的代理可以自动处理服务之间的通信而不需要服务本身进行任何修改。这意味着我们可以在不影响服务本身的情况下对服务之间的通信进行管理和控制。 这里最重要的是一种思维转变不再将代理看成孤立的组件而是将其组成的网络视为一种有价值的实体。
TCP 协议催生了分布式系统分布式系统催生了微服务Service Mesh 就是下一代微服务技术的代名词是微服务时代的 TCP 协议。Service Mesh 以 Sidecar 形式将服务治理从业务逻辑中剥离并拆解为独立进程实现异构系统的统一治理和网络安全。
为了能够对这些代理进行管理和控制服务网格演进出了统一的控制平面control plane和数据面板data plane即边车代理。 控制平面
控制和管理数据平面中的 Sidecar 代理完成配置分发、服务发现、流量路由、授权鉴权等功能以达到对数据平面的统一管理。控制平面不会直接解析请求数据包通常提供 API 或者命令行工具可用于配置版本化管理便于持续集成和部署。
数据平面
由整个网格内的 Sidecar 代理组成这些代理以 Sidecar 的形式和应用服务一起部署。 这些代理负责协调和控制应用服务之间的所有网络通信。每一个 Sidecar 会接管进入和离开服务的流量并配合控制平面完成流量控制等方面的功能。
总结一下Service Mesh 具有如下优点
屏蔽分布式系统通信的复杂性负载均衡、服务发现、认证授权、监控追踪、流量控制等等服务只用关注业务逻辑真正的语言无关服务可以用任何语言编写只需和 Service Mesh 通信即可对应用透明Service Mesh 组件可以单独升级
当然Service Mesh 目前也面临一些挑战
Service Mesh 组件以代理模式计算并转发请求一定程度上会降低通信系统性能并增加系统资源开销Service Mesh 组件接管了网络流量因此服务的整体稳定性依赖于 Service Mesh同时额外引入的大量 Service Mesh 服务实例的运维和管理也是一个挑战
最后我们简单对比下 Spring Cloud 与服务网格的区别
能力Spring Cloud 生态系统Service Mesh 生态系统服务注册与发现开发简单方便仅需一个简单的注解支持多种注册中心。对开发人员来说很容易在本地环境下完成编码和调试。**基于 K8s 的服务机制并提供自己的注册中心。**开发人员需要理解 Kubernetes而开发环境的设置并不容易。故障容忍性Resilience4j 的官方整合提供了完整的故障容忍机制。但服务需要与 SDK 整合。通过使用 sidecar 架构它是一个非侵入式的故障容忍机制对服务完全透明。可观察性Spring Cloud 内置例如 spring micro-meter、Zipkin 等。所有服务内部的指标、追踪和日志都可以轻松收集对开发者完全透明。通过 sidecar 机制它可以监控进出通信。没有可观察的服务内部服务追踪可能是不完整的。流量调度Spring Cloud 仅有非常基础的流量调度例如它基于 Ribbon 的负载均衡从上一版本中删除。更多的流量调度方案如金丝雀部署、蓝绿部署都可以轻松完成。 k8s里pod里多个容器是共享网络命名空间的。 2、微服务、Kubernetes 与服务网格
随着现在云原生技术的发展Kubernetes 已经成为了云原生的标准它是一个开源的容器编排平台它可以自动化地部署、扩展和管理容器化的应用程序。Kubernetes 可以帮助我们管理微服务架构中的服务例如自动化部署、负载均衡、故障恢复等。同样服务网格和 K8s 的结合可以提供更强大的功能服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能而 K8s 可以自动化地部署、扩展和管理容器化的应用程序。通过将服务网格和 K8s 结合起来我们可以更轻松地管理和控制微服务架构中的服务。 虽然 K8s 可以帮助我们管理微服务架构中的服务但是它并不能解决所有的问题。K8s 主要关注的是容器编排和管理例如自动化部署、扩展和管理容器化的应用程序。而服务网格则关注于服务之间的通信例如服务发现、负载均衡、故障恢复、流量控制、安全等。 微服务、云原生、Kubernetes 和服务网格是现代应用开发和部署的关键概念它们之间有着密切的关系。微服务和云原生强调应用程序的可扩展性、可维护性和可部署性Kubernetes 可以帮助我们自动化地部署、扩展和管理容器化的应用程序服务网格可以提供服务发现、负载均衡、故障恢复、流量控制、安全等功能从而简化了微服务架构中的一些问题。
3、服务网格主流对比
在 servicemesh.es 网站中详细的列出了主流服务网格的详细对比。 那么我们应该如何选择服务网格呢
尽管服务网格对代码没有影响但它们改变了操作流程并需要熟悉新的概念和技术。因此采用服务网格实现是一个长期决策特别是在广泛支持服务网格之前。因此应提前仔细比较和测试这些实现。
评估的目标是弄清楚哪些功能对你更重要由于服务网格会影响延迟和资源消耗这些不利因素也必须进行衡量。我们建议在决策过程中包括以下步骤
作为团队确定由服务网格解决的最重要的问题。讨论你对简单性/易用性、性能和兼容性的要求。根据你的功能和非功能要求确定你的前两个或三个实现。测试你的个别应用程序的延迟和资源开销。针对每个服务网格候选者设置相同的测试环境并安装服务网格。设置一个额外的无网格环境。在所有环境中安装您的应用程序。使用 Locust 或 Fortio 等工具在所有环境中进行负载测试并测量请求延迟、CPU 和内存消耗。
如果你没有对这些服务网格技术做详细的评估了解那么你可以从 Istio 开始它是一个开源的服务网格它提供了一些强大的功能例如流量管理、策略执行、服务间通信、可观察性等。Istio 是一个非常活跃的开源项目它有一个非常活跃的社区它的文档也非常丰富可以帮助你快速上手 Istio目前 Istio 是最好的选择。
4、Istio 基础架构
isio官网
https://istio.io/ 中文官网
https://istio.io/latest/zh/ 凭借 Kubernetes 良好的架构设计及其强大的扩展性Google 围绕 Kubernetes 打造一个生态系统。Kubernetes 用于微服务的编排描述一组微服务之间的关联关系并负责微服务的部署、终止、升级、缩扩容等。Istio 补充了 Kubernetes 生态圈的重要一环是 Google 的微服务版图里一个里程碑式的扩张。
Istio 是一个开源服务网格可以透明地分层到现有的分布式应用程序上。 Istio 的强大功能提供了一种统一且更有效的方式来保护、连接和监控服务。 Istio 是实现负载均衡、服务间身份验证和监控的途径 - 只需很少或无需更改服务代码。其强大的控制平面带来了重要的功能包括
通过 TLS 加密、基于身份的强大身份验证和授权确保集群中服务间通信的安全HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制支持访问控制、速率限制和配额的可插入策略层和配置 API集群内所有流量的自动指标、日志和跟踪包括集群入口和出口Istio 专为可扩展性而设计可以满足各种部署需求。
Istio 的控制平面在 Kubernetes 上运行您可以将部署在该集群中的应用程序添加到网格中将网格扩展到其他集群甚至连接在 Kubernetes 外部运行的虚拟机或其他端点。 但 Istio 在 1.5 版本之后架构发生了较大的变化控制平面将之前版本中的多个组件整合为了一个单体结构的 istiod 组件同时废弃了被诟病已久的 Mixer 组件但是我们在理解架构的时候还是可以按照微服务的模式去理解现在最新的版本已经是 1.19.x 版本了所以这里我们直接为大家介绍最新的架构图下图是 1.5 版本之后的架构图 从图上可以看出整体上 Istio 同样也是包括数据面和控制面两个部分。
数据面由一组 Envoy 代理代理部署为 sidecar控制微服务之间所有的网络通信。控制面负责管理和配置代理来路由流量以及在运行时执行策略。
1.Envoy
数据平面核心的组件是 Envoy它是一个用 C 开发的高性能代理用于协调服务网格中所有服务的所有入站和出站流量。Envoy 代理是唯一与数据平面流量交互的 Istio 组件。
Envoy 代理作为服务的 sidecar 进行部署从逻辑上通过 Envoy 的许多内置功能增强服务例如
动态服务发现负载均衡TLS 终止HTTP/2 和 gRPC 代理断路器健康检查基于百分比的分阶段部署故障注入丰富的指标
这种 sidecar 部署允许 Istio 执行策略决策并提取丰富的遥测数据这些遥测数据可以发送到监控系统以提供有关整个网格行为的信息。 遥测数据一般是指链路追踪里的tracingmetrics日志。 sidecar 代理模型还允许您将 Istio 功能添加到现有部署服务中而无需重新架构或重写代码。
Envoy 代理启用的一些 Istio 功能和任务包括
流量控制功能通过丰富的 HTTP、gRPC、WebSocket 和 TCP 流量路由规则实施细粒度的流量控制。网络弹性功能设置重试、故障转移、断路器和故障注入。安全和身份验证功能强制执行安全策略并强制执行通过配置 API 定义的访问控制和速率限制。基于 WebAssembly 的可插拔扩展模型允许针对网格流量执行自定义策略和遥测生成。
2.istiod
控制平面由一个核心的 istiod 组件提供服务用于 Istiod 提供服务发现、配置和证书管理。我们可以将 istiod 做进一步的细分包括了 Pilot、Citadel 和 Galley它们在 1.5 版本之前是属于独立的微服务组件它们的各自功能如下
Pilot为 Envoy 提供了服务发现流量管理和智能路由比如 A/B 测试、金丝雀发布等以及错误处理超时、重试、熔断功能。Citadel为服务之间提供认证和证书管理可以让服务自动升级成 TLS 协议。GalleyGalley 是 Istio 的配置验证、提取、处理和分发组件。它负责将其余的 Istio 组件与从底层平台例如 Kubernetes获取用户配置的细节隔离开来。
整体上 Istiod 将控制流量行为的高级路由规则转换为特定的 Envoy 配置并在运行时将它们传播到 sidecar。Pilot 抽象了特定于平台的服务发现机制并将其合成为任何符合 Envoy API 的 sidecar 都可以使用的标准格式。因为 Istio 可以支持多种环境例如 Kubernetes 或 VM的发现。
我们可以使用 Istio 的流量管理 API 来指示 Istiod 优化 Envoy 配置以对服务网格中的流量进行更精细的控制。
Istiod 安全性通过内置身份和凭证管理实现强大的服务到服务和最终用户身份验证。你可以使用 Istio 升级服务网格中的未加密流量。使用 Istio运维人员可以根据服务身份而不是相对不稳定的第 3 层或第 4 层网络标识符来实施策略。此外还可以使用 Istio 的授权功能来控制谁可以访问你的服务。
此外 Istiod 还充当证书颁发机构 (CA) 并生成证书以允许数据平面中的安全 mTLS 通信(双向通信)。
所以在正式开始学习 Istio 之前我们非常有必要学习下 Envoy 的相关知识Envoy 代理是唯一的数据面组件当我们遇到相关问题的时候可以通过分析 Envoy 来定位问题所以我们需要学习下 Envoy 的相关知识。
文章来源
【优点知识】istio实战训练营
https://youdianzhishi.com/web/course/1047 关于我
我的博客主旨
排版美观语言精炼文档即手册步骤明细拒绝埋坑提供源码本人实战文档都是亲测成功的各位小伙伴在实际操作过程中如有什么疑问可随时联系本人帮您解决问题让我们一起进步 微信二维码 x2675263825 舍得 qq2675263825。 微信公众号 《云原生架构师实战》 个人博客站点
http://onedayxyy.cn/ csdn
https://blog.csdn.net/weixin_39246554?spm1010.2135.3001.5421 知乎
https://www.zhihu.com/people/foryouone 最后
好了关于本次就到这里了感谢大家阅读最后祝大家生活快乐每天都过的有意义哦我们下期见
