idou老师教你学Istio 28：istio-proxy check 的缓存

istio-proxy主要的功能是连接istio的控制面组件和envoy之间的交互，其中check的功能是将envoy收集的attributes信息上报给mixer，在istio中有几十种attributes（官方文档中有Attribute Vocabulary的具体介绍）, mixer根据自身的adapter给envoy 反馈。为了避免每次对mixer都进行远程调用，保证运行时的性能，在istio-proxy这里配置了本地缓存。

在proxy这里配置了两层缓存，分别是referenced map和LRUcache，定义在check_cache.h中:

Referenced map是用来存储envoy check之后mixer的返回的属性，也就是mixer的adapter所使用到的所有属性。

LRUCache是用来储存每次对mixer请求之后所得到的check的结果。

缓存检查

     cache->Check(attributes, result);

     if (result->IsCacheHit()) return result->Status();

未命中缓存，发起远程连接并且接受mixer回复.

     result->SetReponse(status, response);

     return result->Status();

代码解读：

1.缓存命中

检查的入口在request_handler_impl.cc中，首先检查enable_mixer_check开关是否打开：

返回的值是SendCheck:

SendCheck的定义在client_context_base.cc中，这里通过check跳转到client_impl.cc中

在client_impl.cc中，首先先初始化，重置新的检查选项，将检查的计数都归为0

这些选项的options定义在options.h中，这里是设置了缓存的大小num_entries和network_fail_open这个开关。

前文提到的Check的实现是CancelFunc MixerClientImpl::Check()这个函数。

这里主要是调用了checkcache::check这个函数来进行检查。

在没有超时的情况下，如果匹配到了map的签名（signature），并且在cache中命中。那么这一条cache的elem的status会返回result.status。在client_impl.cc中，判断缓存命中，完成check。

CheckResponseInfo在check_response.h中定义，保存了check的结果回复。其中is_check_cache_hit是来判断这个response是否是在缓存中的，当命中时应该为true。

2. 缓存没有命中

如果在之前的check本地缓存的状态中返回的是Status(Code::NOT_FOUND, "")，就需要向mixer发起请求：

这里是先将属性进行compress，并且将这些属性进行复制，给raw_check_result一个指针。

向mixer发起异步的transport check请求，这个transport的定义在environment.h中。

将从mixer得到的response传入到SetResponse中,得到result。

缓存mixer的返回值：

在前文中提到的check NOT_FOUND时候，会像mixer发起请求，这里的network_fail_open开关如果是true的话，那么对mixer请求不成功也会返回OK,如果返回状态为ok()时，证明已经得到了mixer的response,利用CacheResponse进行缓存（check_cache.cc）：

需要先进行前置检查，确认response的合法性。

然后检查response得到的的map和cache中是否有重复，如果没有重复，则插入新的map和缓存元素cache_elem，返回cache_elem的状态。

3. 签名计算

在referenced.h定义了2种key, 一种是exact_key，是请求时实际存在的key;一种是absence key，是mixer 的adapter用到envoy却没有request的key,也就是缺省的key:

计算签名的实现在referenced.cc中，这里首先在attributes map里检查absentkeys和exactkeys;是否都存在。

用函数CalculateSignature计算签名，只对实际请求使用到的exactkeys的属性进行签名。

计算得到的哈希值就可以用于的查找reference map。