功能概述
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。
相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019