第一章:服务网格之Istio初探

第一章:服务网格之Istio初探

读经味如稻梁,读史味如肴撰,读诸家百味如醯醢。

通上文讲到<<微服务架构何去何从>>,如果暂时没有理解ServiceMesh存在解决什么问题,建议先从从上文看起,微服务架构2.0 Service Mesh架构框架方面,业内陆续开源了不少的优秀框架,主流两个Service Mesh产品Istio 和 AWS App Mesh,我们将从多角度探索与实践Istio。

什么是Istio?

由官网定义如下:云平台令使用它们的公司受益匪浅。但不可否认的是,上云会给 DevOps 团队带来压力。为了可移植性,开发人员必须使用微服务来构建应用,同时运维人员也正在管理着极端庞大的混合云和多云的部署环境。 Istio 允许您连接、保护、控制和观察服务。
我们可以看到Istio主要做微服务治理,并且主要分为四个功能:
1、服务之间建立一个连接
2、连接通信之间整数等安全性
3、连接进行流量管理等控制
4、服务连接监控、日志等观察服务

K8s、Istio相辅相成

下图可以看出,Istio可以解决Kubernetes的服务治理缺陷,功能上两者进行了一个互补的结合,解决了云原生服务治理、云原生基础设施。

111

Istio的架构

网格服务,通常和一系列网络代理组成,其主要在于代码无侵入、网络代理,与应用程序部署在一起,但是应用程序却不知情。

主要架构在于数据平面(Data Plane)和控制平面(Control Plane),

  • 数据平面:由一组和业务服务(如下图ServiceA 和 ServceB)成对出现的Sidecar代理(Envoy)构成,它的主要功能是接管服务的进出流量或服务转发,并且与控制平面的 Mixer 通讯,接受调度策略。

  • 控制平面:主要包括了Pilot、Mixer、Citadel和Galley共4个组件,主要功能是通过管理和配置 Envoy 来管理流量,此外,控制平面配置 Mixers来实施路由策略并收集检测到的监控数据。

istio1

Istio核心组件

  • Envoy
    是一个用 C ++开发的高性能代理、CNCF第三个毕业项目,所以性能和可用性都是比较好的,对于Envoy有四个概念【LDS(监听器发现服务)、RDS(路由发现服务)、CDS(集群发现服务)、EDS(服务发现服务)】,每一个 pod 中都必须要部署一个 Sidecar。

ps: 之后会在代码配置中重新标志这块知识点。

  • Pilot
    主要的作用是配置和管理Envoy代理,为高级路由(例如,A / B 测试,金丝雀部署等)提供流量管理功能,以及异常控制,如:超时,重试,断路器等。
    下图是Pilot的原理图,主要的规则数据来源于用户手动配置(路由规则)以及k8s(pod等信息)、Mesos来的一些元数据,通过proxy(Envoy)进行流量转发。

pilot

  • Mixer
    是一个独立于平台的组件,负责在整个 Service Mesh 中执行访问控制和使用策略,并从 Envoy 代理和其他服务收集监控到的数据。
    提供APi服务,可以自研监控分析PAM平台对接Mixer。

mixer

  • Citadel
    通过内置身份和凭证管理,提供强大的服务到服务和最终用户身份验证。我们可以使用 Citadel 升级 Service Mesh 中的未加密流量。我们可以使用 Istio 的授权功能来控制谁可以访问服务。

c

  • Galley
    负责配置的获取、处理和分发。Gally使用了一种叫作MCP(Mesh Configuration Protocol,网格配置协议)的协议与其他组件进行通信。

Bookinfo 微服务源码分析

理解上述概念后,大家可以拿Istio官网提供的一个微服务Book项目进行上手操作,项目地址:https://istio.io/zh/docs/examples/bookinfo

bookinfo 应用一共包含四个微服务:Productpage、Details、Reviews、Ratings。

  • Productpage 使用 Python 开发,负责展示书籍的名称和书籍的简介。
  • Details 使用 Ruby 开发,负责展示书籍的详细信息。
  • Reviews 使用 Java 开发,负责显示书评。
  • Ratings 使用 Node.js 开发,负责显示书籍的评星。

Service Mesh 的应用难点

企业是在原有技术栈的基础上引入 Service Mesh,从实际的应用实践情况来看,往往会存在以下 4 种问题:
1、Service Mesh 模式在业务每次远程调用,通信链路会变长,必将增加请求的响应延迟,性能损耗会被明显放大。
2、基础设施与业务解耦带来的复杂性对运营系统的易用性和 Service Mesh 的稳定性要求极高,否则排查问题时很可能会面临根本无从下手的情况。
3、服务通信框架及治理系统技术栈往往不是云原生优先支持的 GRPC 和 HTTP,在 RPC 框架不兼容的背景下改造成本和挑战非常大。
4、增加基础设施团队的运维成本,并且遇到业务问题,定位问题涉及到业务研发团队和基础设施研发团队频繁沟通交互,自然成本也会相应增加

小结及预告

通过本文,相信读者对微服务的概念和 Istio 的架构有了一定程度的理解。在微服务领域,它最大的优势是解耦应用业务,企业能够彻底从业务角度考虑问题,同时还可以与容器编排部署平台的集成,成为企业级应用编排部署和服务治理的标准形态。

读者有兴趣可持续关注,下面将持续更新Istio应用及剖析。

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×