Istio Mixer Cache工作原理与源码分析Part1-基本概念

Posted ServiceMesher

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Istio Mixer Cache工作原理与源码分析Part1-基本概念相关的知识,希望对你有一定的参考价值。

这里是 Service Mesh 爱好者社区,我们的使命是:传播 Service Mesh 技术、加强行业内部交流、推动 Service Mesh 在企业落地。

本次给大家带来的是Istio中的Mixer Cache源码分析系列中的首篇,作者敖小剑(https://skyao.io),资深码农,十六年软件开发经验,微服务专家,Service Mesh布道师。专注于基础架构,Cloud Native 拥护者,敏捷实践者,坚守开发一线打磨匠艺的架构师。曾在亚信、爱立信、唯品会、ppmoney和数人云任职,机缘巧合下对基础架构和微服务有过深入研究和实践。好了我们正文吧!


本系列文章将详细介绍Istio中Mixer Cache的工作原理,为了避免空谈,将引入广大程序员同学喜闻乐见的源码分析环节,并结合Mixer的接口API,详细展现Mixer Cache的各种细节。

预警:Mixer Cache系列文章除了本文讲述概念比较简单外,其它文章会包含大量复杂和繁琐的细节,包括设计/实现/API等,适合追求深度的同学。

阅读本系列文章前,请确保对Service Mesh和Istio有基本的认知,临时上车的同学请自觉补课:

  • Service Mesh:下一代微服务: Service Mesh介绍

  • 服务网格新生代-Istio:Istio介绍

此外如果对Mixer职责和设计不熟悉的同学,请先阅读下文(本文可以理解为是此文的番外篇):

  • Service Mesh架构反思:数据平面和控制平面的界线该如何划定?

在这篇文章中,出于对Istio性能的担忧和疑虑,我们探讨了Mixer的架构设计,工作原理,并猜测了Mixer的设计初衷。期间,我们介绍到,为了保证运行时性能,避免每次请求都远程访问Mixer,Istio特意为Mixer增加了缓存。当时出于篇幅考虑,我们没有深入到缓存的细节,现在将在这个系列文章中就这一点深入展开。

在展开代码实现细节之前,我们先介绍和Mixer Cache相关的基本概念。

属性

属性(attribute)是Istio中非常一个关键设计,对于Mixer更是特别重要,可以说Mixer的所有功能都是建立在属性这个核心概念之上。

搬运一段官方文档的介绍:

属性的形式如下:

1request.path: xyz/abc
2request.size: 234
3request.time: 12:34:56.789 04/17/2017
4source.ip: 192.168.0.1
5target.service: example

属性词汇

需要特别强调的是:Istio中可以使用的属性是固定的,而不是随意设定的,在这一点上,和一般系统中的类似设计有根本性的差异。

每个给定的Istio部署有固定的能够理解的属性词汇。这个特定的词汇由当前部署中正在使用的属性生产者集合决定。Istio中首要的属性生产者是Envoy,然后特定的Mixer适配器和服务也会产生属性。

这些将被Istio使用的属性集合,被称为属性词汇,总数大概是50个,详细列表可以参看文档:

  • Attribute Vocabulary:来自Istio官方文档中的Reference

  • 属性词汇:此文档的中文文档翻译,来自http://istio.doczh.cn

引用属性

引用属性(Referenced Attributes)是在Mixer Cache的设计和实现中引入的一个非常特别的概念。

特别提醒:要理解Mixer Cache,必须深刻理解Referenced Attritutes。

什么是引用属性?

这个需要从Envoy和Mixer之间的Check方法说起:

1rpc Check(CheckRequest) returns (CheckResponse)

在CheckRequest中,Envoy会提交所有的Attribute,而在CheckResponse的应答中,PreconditionResult 表示前置条件检查的结果:

Istio Mixer Cache工作原理与源码分析Part1-基本概念

“在匹配条件并生成结果的过程中使用到的全部属性集合”是什么意思呢?我们给个例子:

  • 假定envoy提交的请求中有5个属性,”a=1,b=2,c=3,e=0,f=0”

  • 假定mixer中有三个adapter,每个adapter只使用提交属性中的一个属性a/b/c

如下图所示,mixer会在CheckResponse中返回referencedAttributes字段,内容为”a,b,c”,以此表明这三个属性是mixer的adapter在实际的处理过程中使用到的属性:

Istio Mixer Cache工作原理与源码分析Part1-基本概念

Envoy在收到CheckResponse时,就可以从referencedAttributes字段的值中得知: 原来提交上去的”a=1,b=2,c=3,e=0,f=0”这样一个5个属性的集合,实际adapter使用到的只有”a,b,c”。

引用属性的作用

为什么envoy要这么关心哪些属性被adapter使用了?以至于需要在交互的过程中,特意让mixer收集这些使用过的属性并明确在CheckResponse中返回给Envoy?

这是因为Mixer Cache的需要。为了缓存Mixer的结果,避免每次请求都发起一次envoy对mixer的调用,istio在envoy中增加了mixer cache。而要让缓存工作,则必须在每次请求中想办法得到一个有效的key,将调用结果作为value存放起来。

现在关键点就来了:key要如何设计?

最简单的方式,自然是将请求中所有的属性都作为key的组成部分,直接做一个简单的hash,得到的值作为key。但是这个方案不可行的地方在于,请求中可能提交的属性大概有二十个上下,有些属性的值变化非常频繁,取值范围也很大,典型如request.id这样每次请求都会给出一个全局唯一值。如果直接将所有属性都作为key的组成部分,那么很可能每次算出来的key都是一个唯一值,这样缓存也就失去意义了。

因此,不能将全部属性都作为key,那么,挑选部分属性如何?只计算部分我们判断为有必要被adapter使用的属性来计算key。但是,等等,我们会立马反应出来:这违背了mixer adapter的设计原则。

  • adapter是独立于envoy

  • envoy不应该知道有哪些adapter的存在

  • 更不应该知道这些adapter使用了哪些属性

因此,在envoy试图计算key时,就面临两难的境地:

  1. envoy无法预计哪些属性是adapter需要的

  2. envoy也不能将所有的属性都作为key

那怎么办,mixer cache可是必须要加的。只能见招拆招了,思路倒是直白,容易理解:

  1. 谁可以切确的知道哪些属性被adapter使用过?

    当然是被调用过的adapter自己了,每个adapter在执行完成后,都可以给出自己使用属性集合,mixer只要做一个简单收集就可以拿到这个信息。

  2. mixer知道了,怎么告之envoy?

    不是有个现成的response嘛,将前面收集到的属性集合通过response传递回envoy就是了。

搞定!现在再重新看回前面给出的这个图片,就很容易理解了。

下一步

在介绍完基本概念之后,我们将在下一篇文章中开始讲解mixer cache的工作原理,然后在更后面的章节中深入实现细节。


同时我们社区的第一次线下活动也会在6月30号在杭州举办,详情请访问下面的链接:




以上是关于Istio Mixer Cache工作原理与源码分析Part1-基本概念的主要内容,如果未能解决你的问题,请参考以下文章

idou老师教你学Istio 20 : Istio全景监控与拓扑

Istio的架构设计

必读!Istio Service Mesh中的策略与遥测概念详解

Istio组件Mixer介绍

每周一书《云原生服务网格Istio:原理实践架构与源码解析》分享!

Kube:Istio:在Mixer中上报metrics数据