签名是Mixer Check Cache的核心操作，涉及到最重要的缓存查找，还有性能，但是，其实在理解了引用属性和absent key的概念后，也非常简单。
特别推荐
Service Mesh：重塑微服务市场
今天我们不谈技术，不谈架构，也不谈具体的产品，我们来聊一聊在未来一两年之内，Service Mesh技术会在微服务相关的市场带来什么样的变化？
NJSD,
2018
敖小剑，资深码农，十六年软件开发经验，微服务专家，Service Mesh布道师。专注于基础架构，Cloud Native 拥护者，敏捷实践者，坚守开发一线打磨匠艺的架构师。曾在亚信、爱立信、唯品会、ppmoney和数人云任职，机缘巧合下对基础架构和微服务有过深入研究和实践。
目前就职蚂蚁金服，在中间件团队从事Service Mesh产品开发。
个人理念：坚守一线，绝不脱节，上可海阔天空谈架构，下可埋头苦干码代码。
演讲/文章/分享
PDF 中生代技术群分享图文实录(推荐阅读) UPYUN Open Talk No.24图文实录 Open Talk 预告
签名是Mixer Check Cache的核心操作，涉及到最重要的缓存查找，还有性能，但是，其实在理解了引用属性和absent key的概念后，也非常简单。
Mixer check Cache设计时，由于受限于无法得知mixer adaper会使用哪些属性，因此不得不引入两层缓存的设计，而absence key的使用也增加了代码阅读上的困难。在展开代码阅读和讲解之前，我们先在本文中概括讲述mixer check cache的工作原理。
为了保证性能，避免每次请求都远程访问Mixer，Istio在Envoy中精心设计了一套Mixer Cache机制。在Mixer这个精美的花瓶下面，垫上了一块厚实的板砖。
为了架构的优雅，Istio设计了Mixer，将大量的功能从Sidecar中搬了出来。为了减少Mixer远程调用带来的性能，又精心设计了一套复杂的缓存。只是，这个Mixer Cache，有一个地方需要探讨……
苦等一年，始终不见Istio的性能有实质性提升，失望之余，开始反思Istio而至Service Mesh的架构。焦点所在：proxy到底该做哪些事情？架构的优美和性能的实际表现该如何平衡？
在前面的讨论中，我们探索了打通多个服务注册中心的思路。另外在服务治理中心的构想，也是希望能提供统一的方式对各家微服务体系进行服务治理。而要做到这两点，服务注册模型的统一势在必行。
Dream Mesh，梦想中的Service Mesh.
