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到底该做哪些事情？架构的优美和性能的实际表现该如何平衡？
要调用服务，自然需要知道服务在哪里，这涉及到服务注册与服务发现。本集群内只需要知道目标服务实例的ip地址和端口即可，而要跨集群调用服务，事情要变的复杂的多。我们来罗列一下实现中的难点所在。
在前面的讨论中，我们探索了打通多个服务注册中心的思路。另外在服务治理中心的构想，也是希望能提供统一的方式对各家微服务体系进行服务治理。而要做到这两点，服务注册模型的统一势在必行。
列出规划中的Dream Mesh主要功能模块，定好优先级和开发顺序。
在展开详细的架构设计之前，先罗列一下Dream Mesh将在之后遵循的一些基本原则，以及这些原则背后的原因和期望的目标。
一个微服务系统，无论是传统的侵入式，还是新兴的Service Mesh，其核心骨干，主要是三大模块：服务注册，配置，SDK。
如果有多集群/多机房的支持需求，该如何解决？这个问题和前面列出的service mesh体系和非service mesh的并存问题，可能叠加：如何在多集群/多机房要求下实现service mesh体系和非service mesh的并存。
service mesh解决的是东西向服务间通讯的问题，我们来审视一下API gateway到微服务之间的南北向通讯： 服务发现，负载均衡，路由，灰度，安全，认证，加密，限流，熔断……几乎所有主要功能，在这两个方向上都高度重叠。因此，是否该考虑提供一个统一的解决方案来处理？
Spring Cloud在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到service mesh之前加强Spring Cloud，并为将来转入Service Mesh铺路，是一个艰难而极具价值的话题。
对于Java企业应用，Spring是无论如何绕不开的。但是如何以正确的姿势在Service Mesh时代使用Spring，需要自己探索。Spring Boot + Service Mesh是我所推崇的一对清爽搭配。
Service Mesh的核心在于将原有以类库方式提供的功能拆分到独立的sidecar进程中，以远程调用的方式来强行解耦服务间通讯的业务语义和服务间通讯的具体实现。我们来看看这对性能会有什么影响。
Service Mesh并不限制序列化方案和远程通讯机制，在拥有极大选择自由度的同时，烦恼依旧存在：到底什么是适合service mesh时代的网络通讯方案？
Service Mesh的一个突出优点就是对应用的侵入度非常低，低到可以零侵入。然而，没有任何事情是可以十全十美的，零侵入带来的弊端又在哪里？
一部分应用开始搬迁到Service Mesh，大部分还停留在原有体系。那么，在过渡阶段，Service Mesh内的服务和Service Mesh外的服务在通讯时会遇到哪些问题？
理想很丰满，现实很骨感。Cloud Native虽然令人向往，然而现实中，有多少企业是真的做好了Cloud Native的准备？
近期在Service Mesh如何落地上，有些想法和思路，真诚的邀请朋友们参与讨论，希望能引出更多更好的内容。
今天重启个人博客，借此机会回顾一下过去十三年间的个人技术博客的历程。
