微服务架构下 Service Mesh 会是闪亮的明天吗?

7月7日,时速云企业级容器 PaaS 技术沙龙第 10 期在上海成功举办,时速云容器架构负责人魏巍为大家详细讲解了 Service Mesh 中代表性的实践方案、并以 Istio 为例详细讲解了 Service Mesh 中的技术关键点,包括 Istio 控制平面、Istio 数据平面等。以下内容根据魏巍分享整编,希望对大家了解 Service Mesh 有所帮助。

魏巍:大家下午好,刚才几位讲师讲了 K8S 的存储、PaaS 在企业的落地实践等,我们接下来要讲的是企业有了 PaaS 平台、并且在平台上部署了各种各样的服务之后,这些服务该如何治理、服务与服务之间的关系,以及该以何种方式去维护等问题,而最近两年兴起的 Service Mesh,能够更加便捷的管理这些服务。

Service Mesh 是一个专用的基础设施层,目的是解决系统架构微服务化后的服务间通信和治理问题。Service Mesh 从实践上来说有很多方案,但这些方案都有共同的特点,比如说像这里提到的宏观架构抽象,它都会划分为 Control Plane 和 Data Plane,这种整体架构设计。

第二个特点,Service Mesh 基本来说是一组轻量级的与应用逻辑服务部署在一起的服务代理,它会用代理的方式去实现路由、断路器、服务发现等,并且这些对应用服务都是透明的,当然这是在 K8S 上。如果说不是基于 Service Mesh 做的微服务架构,还可以基于 SpringCloud 做微服务架构,但是SpringCloud有自身的局限性,它主要用于以 java 为主的领域。

Istio、Conduit、Nginmesh 都是 Service Mesh 中比较火的实践方案。Istio 是 Google 和 IBM 联合 Lyft 的合作开源项目,是当前最主流的 Service Mesh 方案;Conduit 各方面的设计理念与 Istio 非常类似,其使用 Rust 重新编写了 sidecar,控制面由 Go 编写的 Conduit Control Plane 接管;NginMesh 并没有自己独立实现一整套 Service Mesh,只是用 nginx替代了 Istio 中 Envoy。

Istio

在 Istio、Conduit、 Nginmesh 这几个实践方案中,Istio 的影响最大,所以我们今天主要讲解一下 Istio。

Istio 逻辑上分为控制平面(Control Plane)和数据平面(Data Plane)。

控制平面由 Pilot 、Mixer 、Citadel 组成,控制平面的每一个组件都负责一些特定的功能。数据平面由一组智能代理(Envoy)组成,代理部署为 sidecar,其控制微服务之间所有的网络通信。

Istio 控制平面

Istio 控制平面包括以下组件:

Pilot:Pilot 负责 Envoy 配置、全生命周期管理。可以为 Envoy sidecar 提供服务发现,为流量管理功能实现了灵活的路由(如 A/B 测试、金丝雀发布)和弹性(如:超时、重试、熔断等),它还可以将高级别的路由规则转换为 Envoy 特定的配置并在运行时将配置传播到 sidecar 中。

Mixer:Mixer 是一个平台独立的组件,其主要负责对后端系统的抽象、对接、策略配置等,并从 Envoy 代理和其它服务中收集测量数据。

抽象一点说,Mixer 提供:

后端抽象:Mixer 把 Istio 组件和 Mesh 中的服务从基础设施细节中隔离开来。
中间媒介:Mixer 让运维人员能够对所有 Mesh 和基础设施后端之间的交互进行控制。

Mixer 在某种程度上起到一种桥梁的作用。Envoy 提供 request 级别的属性数据,这些数据交由 Mixer 进行评估和处理,Mixer 中的各种适配器 (adapter)基于这些属性数据,来实现日志记录、监控指标采集展示、配额管理、ACL 检查等功能。

Citadel:提供服务间认证和终端用户认证功能,内置身份和证书管理,并且在网络策略之外,提供服务级别的策略控制。

Istio数据平面

Envoy 是 Istio 的数据平面。Envoy 是一个高性能轻量级代理,用于控制服务网格中服务的所有入站和出站流量。Envoy 提供了很多内置功能,如动态服务发现、负载均衡、TLS 会话终结、HTTP/2& gRPC 流量代理、熔断器、健康检查等功能。

Envoy 被部署为 sidecar,与对应的微服务一起部署在一个 Kubernetes Pod 中。每个微服务实例通过各自的 sidecar 来实现发送和接受请求;微服务和微服务之间不直接通信,而是通过 sidecar 的代理转发来实现通信。 sidecar 直接形成调用网络,就像一个“网格”一样。使用 sidecar 代理模型代码无需重新构建或重写代码。

注:关注时速云微信订阅号,回复:7.7上海PPT,即可下载讲师分享PPT。

原文地址:http://blog.51cto.com/13743772/2141891

时间: 2024-10-12 05:01:39

微服务架构下 Service Mesh 会是闪亮的明天吗?的相关文章

微服务架构下,解决数据一致性问题的实践

随着业务的快速发展,应用单体架构暴露出代码可维护性差.容错率低.测试难度大和敏捷交付能力差等诸多问题,微服务应运而生.微服务的诞生一方面解决了上述问题,但是另一方面却引入新的问题,其中主要问题之一就是:如何保证微服务间的业务数据一致性.本文将通过一个商品采购的业务,来看看在Dubbo的微服务架构下,如何通过Fescar来保障业务的数据一致性.本文所述的例子中,Dubbo 和 Fescar 的注册配置服务中心均使用 Nacos.Fescar 0.2.1+ 开始支持 Nacos 注册配置服务中心.业

微服务架构下的数据一致性:可靠事件模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:可靠事件模式 在<微服务架构下的数据一致性:概念及相关模式>中介绍了在微服务中实现数据一致性的三种方式,包括可靠事件模式.业务补偿模式.TCC模式.本文重点说一下可靠事件投递. 1. 可靠事件模式 可靠事件模式属于事件驱动架构,微服务完成操作后向消息代理发布事件,关联的微服务从消息代理订阅到该事件从而完成相应的业务操作,关键在于可靠事件投递和避免事件重复消费. 可靠事件投递有两个特性:1)每个服务原子性的完

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

微服务架构下的数据一致性:概念及相关模式

主页:http://www.howardliu.cn/ 博客:微服务架构下的数据一致性:概念及相关模式 从2014年开始,微服务逐渐进入大家的实现,被认为是下一代实现信息化的有效手段.设计到系统,其中绕不开的就是数据一致性,从本地事务,到后来的分布式事务,都能够有效的保证数据一致性.但是在微服务架构中,这两种方式都不是最好的选择. 1. 使用本地事务和分布式事务保证一致性 在传统的单击应用中,最简单.最直接.最普遍的会使用一个关系型数据库,通过关系型数据库的事务保证数据的一致性.这种事务有四个基

从 0 开始的微服务架构:(四)如何保障微服务架构下的数据一致性

虽然已经红了很久,但是"微服务架构"正变得越来越重要,也将继续火下去.各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构.就是没有一个做到成熟地将技术传播出来,同时完美地照顾"初入微服务领域人员",从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列.所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题"Re:从 0 开始

如何保障微服务架构下的数据一致性

1.微服务架构的数据一致性问题 以电商平台为例,当用户下单并支付后,系统需要修改订单的状态并且增加用户积分.由于系统采用的是微服务架构,分离出了支付服务.订单服务和积分服务,每个服务都有独立数据库做数据存储.当用户支付成功后,无论是修改订单状态失败还是增加积分失败,都会造成数据的不一致. 为了解决例子中的数据一致性问题,一个最直接的办法就是考虑数据的强一致性.那么如何保证数据的强一致性呢?我们从关系型数据库的 ACID 理论说起. 关系型数据库具有解决复杂事务场景的能力,关系型数据库的事务满足

微服务架构下分布式事务解决方案——阿里云GTS

https://blog.csdn.net/jiangyu_gts/article/details/79470240 1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开

微服务架构下分布式事务方案

1 微服务的发展 微服务倡导将复杂的单体应用拆分为若干个功能简单.松耦合的服务,这样可以降低开发难度.增强扩展性.便于敏捷开发.当前被越来越多的开发者推崇,很多互联网行业巨头.开源社区等都开始了微服务的讨论和实践.Hailo有160个不同服务构成,NetFlix有大约600个服务.国内方面,阿里巴巴.腾讯.360.京东.58同城等很多互联网公司都进行了微服务化实践.当前微服务的开发框架也非常多,比较著名的有Dubbo.SpringCloud.thrift .grpc等. 2 微服务落地存在的问题

微服务架构下的身份认证

从单体应用架构到分布式应用架构再到微服务架构,应用的安全访问在不断的经受考验.为了适应架构的变化.需求的变化,身份认证与鉴权方案也在不断的变革.面对数十个甚至上百个微服务之间的调用,如何保证高效安全的身份认证?面对外部的服务访问,该如何提供细粒度的鉴权方案?本文将会为大家阐述微服务架构下的安全认证与鉴权方案. 单体应用 VS 微服务 随着微服务架构的兴起,传统的单体应用场景下的身份认证和鉴权面临的挑战越来越大.单体应用体系下,应用是一个整体,一般针对所有的请求都会进行权限校验.请求一般会通过一个