博客文章

为了保证性能,避免每次请求都远程访问Mixer,Istio在Envoy中精心设计了一套Mixer Cache机制。在Mixer这个精美的花瓶下面,垫上了一块厚实的板砖。

CONTINUE READING

为了架构的优雅,Istio设计了Mixer,将大量的功能从Sidecar中搬了出来。为了减少Mixer远程调用带来的性能,又精心设计了一套复杂的缓存。只是,这个Mixer Cache,有一个地方需要探讨……

CONTINUE READING

苦等一年,始终不见Istio的性能有实质性提升,失望之余,开始反思Istio而至Service Mesh的架构。焦点所在:proxy到底该做哪些事情?架构的优美和性能的实际表现该如何平衡?

CONTINUE READING

在前面的讨论中,我们探索了打通多个服务注册中心的思路。另外在服务治理中心的构想,也是希望能提供统一的方式对各家微服务体系进行服务治理。而要做到这两点,服务注册模型的统一势在必行。

CONTINUE READING

列出规划中的Dream Mesh主要功能模块,定好优先级和开发顺序。

CONTINUE READING

在展开详细的架构设计之前,先罗列一下Dream Mesh将在之后遵循的一些基本原则,以及这些原则背后的原因和期望的目标。

CONTINUE READING

一个微服务系统,无论是传统的侵入式,还是新兴的Service Mesh,其核心骨干,主要是三大模块:服务注册,配置,SDK。

CONTINUE READING

如果有多集群/多机房的支持需求,该如何解决?这个问题和前面列出的service mesh体系和非service mesh的并存问题,可能叠加:如何在多集群/多机房要求下实现service mesh体系和非service mesh的并存。

CONTINUE READING

service mesh解决的是东西向服务间通讯的问题,我们来审视一下API gateway到微服务之间的南北向通讯: 服务发现,负载均衡,路由,灰度,安全,认证,加密,限流,熔断……几乎所有主要功能,在这两个方向上都高度重叠。因此,是否该考虑提供一个统一的解决方案来处理?

CONTINUE READING

Spring Cloud在未来很长一段时间之内都会是市场主流和很多公司的第一选择。如何在迁移到service mesh之前加强Spring Cloud,并为将来转入Service Mesh铺路,是一个艰难而极具价值的话题。

CONTINUE READING