技术博客

微服务领域的著名专家 Chris Richardson 在其博客上发表了微服务反模式序列文章，描述他在与全球众多客户合作时，观察到多种微服务采用的反模式。

在 re:Invent 2018，AWS宣布了AWS App Mesh 的公开预览版，App Mesh是一个服务网格，可以轻松监视和控制跨应用的通信。而现在，AWS App Mesh 正式GA了。

Istio1.1版本加强了对HTTP Retry条件的控制，同时修改了原有的HTTP retry的默认行为，去除了5xx的重试条件，但是没有文档上体现，所以使用时请留意：如果遇到重试不生效，请检查retryOn配置。

为了尽可能的提升往Mixer批量上报数据的性能，提供了Delta Encoding的特性。但是最近发现存在属性删除的bug，因此Istio1.1之后废弃了这个特性。

Istio支持在多个cluster之间设置权重，通过设置不同的subset和weight，可以实现很多丰富的功能。但是之前只能为HTTP提供，TLS和TCP只能设置一个Destination，直到Istio1.1版本。

蚂蚁金服容器与服务创新组招聘优秀毕业生啦，欢迎致力于云原生微服务研发的同学投递简历。

对于服务的可见性，在 Istio 设计之初，是没有特别考虑的，或者说，Istio 一开始的设计就是建立在如下前提下的：Istio中的任何服务都可以访问其他任意服务。直到Istio1.1版本才开始正视这个问题 :)

SOFAMesh需要增加多个通讯协议的支持，在开发中我们发现按照Istio标准的开发方式，会有大量重复的工作和代码。通过x-protocol我们在SOFAMesh中实现简单快捷的协议扩展，可以方便的支持新的TCP通讯协议。

虽然大多数的服务都不会要求极致性能，但是系统中总是有可能出现个别服务的确对性能要求很高，为了满足这些特例而不至于因此整体否决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主要功能模块，定好优先级和开发顺序。