虽然大多数的服务都不会要求极致性能，但是系统中总是有可能出现个别服务的确对性能要求很高，为了满足这些特例而不至于因此整体否决Servicemesh方案，我们需要在Servicemesh的大框架下提供一个折中方案。
为了更方便的支持通讯协议扩展，为了更灵活的性能与功能的平衡，为了兼容现有SOA体系，我们在SOFAMesh项目中引入了名为x-protocol的解决方案，在Istio之上进行补充，让我们从DNS通用寻址方案开始。
在Service Mesh技术社区的微信群中，针对Istio Mixer Cache设计中缓存存放和逻辑分离的潜在分险，进行了深入探讨，截屏实录，原汁原味。
签名是Mixer Check Cache的核心操作，涉及到最重要的缓存查找，还有性能，但是，其实在理解了引用属性和absent key的概念后，也非常简单。
Mixer Check Cache的主流程代码解析。
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时代的网络通讯方案？
