容器编排无法解决微服务的所有问题,你还需要服务网格
容器编排是一个很好的基础设施,但企业组织需要的不仅仅是一个良好的基础设施。他们需要能够与堆栈上层的服务进行交互的能力,这需要使用Service Mesh指标和现代架构去实现。
容器编排是一个很好的基础设施,但企业组织需要的不仅仅是一个良好的基础设施。他们需要能够与堆栈上层的服务进行交互的能力,这需要使用Service Mesh指标和现代架构去实现。
技术预览计划将为现有的OpenShift Container Platform客户提供在其OpenShift集群上部署和使用Istio平台的能力。红帽正在提供此计划,旨在收集反馈和经验,同时Red Hat期望在2019自然年提供OpenShift上Istio的全面支持和全面可用性。
Linkerd 2.0版本为Linkerd带来了性能、资源消耗和易用性方面的显着改进。它还将项目从集群范围的service mesh转换为可组合的service sidecar,旨在为开发人员和服务所有者提供在云原生环境中成功所需的关键工具。
Istio能否成为Kubernetes之上的事实的服务网络标准呢? 我们采访了Red Hat的Istio产品经理“红胡子”Brian Harrington,他的答案是肯定的。
在Docker提供的免费的Kubernetes试玩平台上,使用好奇心驱动的方式部署一个Istio Service Mesh。本方式适合没有测试资源又不想自己整环境的,只是想上去爽一把的人士。
在Kubernetes诞生的前几年微服务还是分布式系统最流行的架构风格。但Kubernetes和云原生运动已经改变了应用程序设计和开发的方方面面。在本文中,我要质疑微服务的一些理念,指明它们在后Kubernetes时代不会再像以前那样强大。
本文分享了Lyft对于Envoy的在服务网格领域的实践,主要为了解决级联故障的问题,以及Lyft对于Envoy的未来规划。
本文作者是蚂蚁金服中间件团队的高级技术专家邵俊雄(熊啸),主要负责 SOFAMesh 的开发工作。本文是基于作者在 Service Mesh Meetup #3 深圳的主题分享《SOFAMesh的通用协议扩展》部分内容所整理,完整内容见文末的直播回放。
Copyright ©️ 2018 - 2020, ServiceMesher all rights reserved.
模板来自 Bootstrapious. 移植到 Hugo 来自 DevCows