第八章 跨语言服务治理方案 Service Mesh

8.1 Service Mesh 概述

  新兴的下一代微服务架构,被称为下一代微服务,同时也是云原生技术栈的代表技术之一。

  8.1.1 Service Mesh的由来

    从2016年到2018年,service mesh经历了从无到有的过程

  8.1.2 Service Mesh的定义

    服务网格是一个基础设施层,用于处理服务间通信。现代云原生应用有着复杂的服务拓扑结构,服务网格负责在这些拓扑结构中实现请求的可靠传递。实践中,服务网格通常被实现为一组轻量级网络代理,它们与应用程序部署在一起,对应用程序透明。

  8.1.3 Service Mesh详解

  • 单个服务调用:应用实例和Service mesh 代理实例是两个独立的进程,它们之间的通信时远程调用,而不是代码层面的方法调用。客户端的请求会先到Service Mesh代理实例,代理实例表现为Sidecar,完成服务发现、负载均衡等基本功能,熔断、限流、重试等容错功能,路由功能,以及认证、授权、加密等,最后将请求发送给应用服务。
  • 多个服务调用:Service mesh负责所有服务间请求转发,服务只负责发送和处理请求,不必再负责传递请求的具体逻辑。
  • 大量服务调用:当系统存在大量服务时,服务间调用关系表现为网状。Sidecar之间的服务调用关系形成一个网络,这就是Service Mesh(服务网格)名字的由来。
  • Service Mesh定义回顾:抽象:Service mesh是一个抽象层,负责王完成服务间通信。并且将这些功能从应用中剥离出来,形成一个单独的通信层,并将其下沉到基础设施层。    功能:请求的可靠传递。        部署:轻量级网络代理,以sidecar的模式和应用程序一对一部署,两者之间的通信时远程调用。    透明:Service mesh对应用程序是透明的。Service Mesh可以独立部署升级、扩展功能、修复缺陷,而不必改动应用程序。                                    

8.2 Service Mesh演进历程

  下面讲述Service Mesh技术的起源、发展、以及一步一步的演进历程。

  8.2.1 远古时代的案例

    在应用代码中处理网络通信细节,比如数据包顺序、流量控制等。后来TCP/IP协议栈负责这些功能。

  8.2.2 微服务时代的现状

    服务发现、负载均衡、熔断、重试。

  8.2.3 侵入式框架的痛点

    Spring Cloud和Dubbo这些传统的微服务治理框架都是侵入式的微服务框架。

    痛点1:门槛高。

    痛点2:功能不全。  Istio的路由功能比Spring Cloud强大。

    痛点3: 无法跨语言。微服务有跨语言的优点。

    痛点4:升级困难。

  8.2.4 解决问题的思路

  8.2.5 Proxy模式的探索

    为了解决客户端和服务端直接耦合的问题,尝试使用Proxy模式来隔离客户端和服务端,典型的如Nginx、HAProxy、Apache等HTTP反向代理。Proxy转发所有流量,而Proxy需要为代理的流量实现基本功能,如负载均衡。

  8.2.6 Sidecar模式的出现

    SiderCar在Proxy上发展起来,功能更加全面。

  8.2.7 第一代的service Mesh

    Linkerd、Envoy

  8.2.8 第二代的Service Mesh

  Istio

  Istio最大的创新在于,它为Service Mesh带来了前所未有的控制力:

  • 以Sidecar方式部署的Service Mesh控制了服务间所有的流量
  • Istio增加了控制面板来控制系统中所有的Sidecar
  • Istio能够控制所有的流量,即控制系统中所有请求的发送。

8.3 Service Mesh市场竞争

  8.3.1 Service Mesh的萌芽期

  8.3.2 急转直下的Linkerd

  8.3.3 波澜不惊的Envoy

  8.3.4 背负使命的Istio

  8.3.5 背水一战的Buoyant

  8.3.6 其他参与者

  8.3.7 Service  Mesh的国内发展情况

8.4 Istio

  8.4.1 Istio概述

    一个连接,管理和保护微服务的开放平台。

    功能:

      连接:智能控制服务之间的流量和API调用。

      保护:身份验证、授权和服务之间通信加密,保护服务。

      控制:

      观测:自动跟踪、监控和记录所有服务。

        Istio设计目标:

      最大化透明度:

      增量

      可移植性

      策略一致性     

  8.4.2 架构和核心组件

    Istio分为数据平面控制平面两个部分:

    数据平面:是以Sidecar方式部署的智能代理,Istio默认集成的是Envoy,控制微服务之间的网络通信,已经和Mixer模块的通信。

    控制平面:管理和配置数据平面,控制数据平面的行为,如代理路由流量、实施策略、收集遥测数据、加密认证等。控制平面包含Pilot、Mixer、Citadel三个主要组件。

    Envoy: 用于调节服务网格中所有的服务的入站、出站流量。具体如下HTTP、gRPC、TCP Proxy、Thrift

      另外,Enovy还提供了和网络通信直接相关的各种功能:

           服务发现: 从Pilot得到服务发现信息。

      负载均衡

         健康检查:

       熔断:

       高级路由:

       基于百分比的流量拆分:

       加密和认证:

       故障注入: 

      此外,Envoy还要完成对请求属性的提取,这些属性可以通过Istio Proxy的Mixer Filter发送给Mixer,用于执行策略决策、配额检查等行为。

      Mixer:负责提供策略控制和遥测收集的组件,在istio中的职责如下三点:

        Check: 前置条件检查。认证、黑白名单、ACL检查。

        Quota: 比如限速。

        Report: 遥测报告。

      Citadel: 加密、访问控制、审计。

    

原文地址:https://www.cnblogs.com/liufei1983/p/11519027.html

时间: 2024-10-01 04:15:43

第八章 跨语言服务治理方案 Service Mesh的相关文章

Apache Thrift 跨语言服务开发框架

Apache Thrift 是一种支持多种编程语言的远程服务调用框架,由 Facebook 于 2007 年开发,并于 2008 年进入 Apache 开源项目管理.Apache Thrift 通过 IDL 来定义 RPC 的接口和数据类型,然后通过代码生成工具来生成针对不同编程语言的代码,目前支持 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCa

thrift框架总结,可伸缩的跨语言服务开发框架

thrift框架总结,可伸缩的跨语言服务开发框架 前言: 目前流行的服务调用方式有很多种,例如基于 SOAP 消息格式的 Web Service,基于 JSON 消息格式的 RESTful 服务等.其中所用到的数据传输方式包括 XML,JSON 等,然而 XML 相对体积太大,传输效率低,JSON 体积较小,新颖,但还不够完善.本文将介绍由 Facebook 开发的远程服务调用框架 Apache Thrift,它采用接口描述语言定义并创建服务,支持可扩展的跨语言服务开发,所包含的代码生成引擎可以

【转】Apache Thrift - 可伸缩的跨语言服务开发框架

Apache Thrift - 可伸缩的跨语言服务开发框架 Apache Thrift 是 Facebook 实现的一种高效的.支持多种编程语言的远程服务调用的框架.本文将从 Java 开发人员角度详细介绍 Apache Thrift 的架构.开发和部署,并且针对不同的传输协议和服务类型给出相应的 Java 实例,同时详细介绍 Thrift 异步客户端的实现,最后提出使用 Thrift 需要注意的事项. 12 评论 黄 晓军, 实习生, IBM 张 静, 软件工程师, IBM 张 凯, 高级软件

CAT跨语言服务加拿大28平台搭建链监控(七)消息分析器与报表

CrossAnalyzer-调用链加拿大28平台搭建论坛:haozbbs.com Q1446595067分析 在分布式环境中,应用是运行在独立的进程中的,有可能是不同的机器,或者不同的服务器进程.那么他们如果想要彼此联系在一起,形成一个调用链,在Cat中,CrossAnalyzer会统计不同服务之间调用的情况,包括服务的访问量,错误量,响应时间,QPS等,这里的服务主要指的是 RPC 服务,在微服务监控中,这是核心. 在讲 CrossAnalyzer 的处理逻辑之前,我们先看下客户端的埋点的一个

第六章 嵌入式服务治理方案

6.1 Dubbo 6.1.1 Dubbo概述 服务间基于RPC的方式调用. 6.1.2 核心流程 Dubbo中必有的核心概念只有服务提供者.服务消费者和注册中心这三个,治理中心以及监控中心并非必需品. 服务提供者初始化后会向注册中心注册服务:服务消费者启动时向注册中心订阅服务.注册中心在服务提供者列表发生变化时将变化的内容主动通知给服务消费者.服务提供者和服务消费者在初次连通后,持有长连接,通过透明化的远程调用进行通信. 6.1.3 注册中心 大多数情况,Dubbo都是配合Zookeeper注

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

7月7日,时速云企业级容器 PaaS 技术沙龙第 10 期在上海成功举办,时速云容器架构负责人魏巍为大家详细讲解了 Service Mesh 中代表性的实践方案.并以 Istio 为例详细讲解了 Service Mesh 中的技术关键点,包括 Istio 控制平面.Istio 数据平面等.以下内容根据魏巍分享整编,希望对大家了解 Service Mesh 有所帮助. 魏巍:大家下午好,刚才几位讲师讲了 K8S 的存储.PaaS 在企业的落地实践等,我们接下来要讲的是企业有了 PaaS 平台.并且

深入详解美团点评CAT跨语言服务监控(一) CAT简介与部署

前言: CAT是一个实时和接近全量的监控系统,它侧重于对Java应用的监控,除了与点评RPC组件融合的很好之外,他将会能与Spring.MyBatis.Dubbo 等框架以及Log4j 等结合,支持PHP.C++.Go等多语言应用,基本接入了美团点评上海侧所有核心应用.目前在中间件(MVC.RPC.数据库.缓存等)框架中得到广泛应用,为美团点评各业务线提供系统的性能指标.健康状况.监控告警等,在微服务监控领域也是非常有用的一套组件.支撑这美团每天450亿的消息,50TB的数据监控,应用于 700

企业应用架构演化探讨:从微服务到Service Mesh

作者:李宁 来源:博云技术社区 / 博云研究院 当下微服务的实践方案中,Spring Cloud,Dubbo作为主流的落地方案,在企业应用架构中发挥越来越重要的作用.本文探讨企业应用架构如何从微服务架构向Service Mesh架构演化,并形成落地方案.需要特别说明:本文讨论的架构目前适用于普通的企业级应用,其他行业(例如互联网)需要进一步扩展. 在讨论之前,我们需要明确一个事实:企业应用一定是围绕业务进行的. 无论采用什么的架构落地,都是为了更好的为应用业务进行服务.从企业应用的特性考虑,主要

面试都在问的微服务、RPC、服务治理...一文帮你彻底搞懂!

单体式应用程序 与微服务相对的另一个概念是传统的「单体式应用程序」( Monolithic application ),单体式应用内部包含了所有需要的服务.而且各个服务功能模块有很强的耦合性,也就是相互依赖彼此,很难拆分和扩容. 说在做的各位都写过单体程序,大家都没意见吧?给大家举个栗子,刚开始写代码你写的helloworld程序就是单体程序,一个程序包含所有功能,虽然helloworld功能很简单. 单体应用程序的优点 开发简洁,功能都在单个程序内部,便于软件设计和开发规划. 容易部署,程序单