美文网首页
微服务架构下 Service Mesh 会是闪亮的明天吗?

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

作者: Tenxcloud | 来源:发表于2018-07-12 11:32 被阅读0次

    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。

    相关文章

      网友评论

          本文标题:微服务架构下 Service Mesh 会是闪亮的明天吗?

          本文链接:https://www.haomeiwen.com/subject/fnblpftx.html