收录了 网格服务 频道下的 50 篇内容
这篇文章介绍并讨论了三种技术:虚拟化,面向服务和网格计算。接着描述了它们是如何结合在一起的,从而提供新的设计和部署的选择——“虚拟面向服务网格”。此外,文中还讨论了使用该新兴模型的商业案例。
应用集成的挑战几乎没有什么变化,但是我们解决它们的方式却发生了变化。
在生产环境中采用服务网等新技术将会对你和你的同事产生影响,注意这些影响,可以为利益相关者提供更好的支持。明确你要解决的问题,并确定适当的验收标准。通过实验向各个利益相关者展示服务网格将如何让他们的生活变得更美好。
聊聊为什么自研Flomesh,以及对于服务网格的新思考
云上 Serverless Microservice 实践标准探索
2017 年,Google 联合 IBM、Lyft 推出了 Istio,因为有 K8s 的成功经验在先,Istio 一出生就引人注目,其受到的关注度甚至远超最早提出服务网格概念的 Linkerd。只要有关注度,就有溢价存在,业界为 Istio 买账更像是买一种预期,认为 Istio 能像 K8s 一样,快速成为服务网格领域的事实标准。
随着越来越多的公司采用微服务架构,Istio、Linkerd和Cilium等服务网格也越来越受关注。服务网格提供了非常有吸引力的特性:全堆栈可观测性、透明的安全性、系统弹性等。但是,服务网格真的是云原生应用程序的正确解决方案吗?本文将讨论服务网格在什么情况下是有意义的,以及什么时候不应该使用服务网格。
在分布式体系下,微服务技术在经历多年发展之后渐趋成熟。进入云原生时代,微服务技术在云原生理念的驱动下被赋予了新的使命。
网格技术可提升SOA实现的可伸缩性、高可用性和吞吐量。在这篇文章中,Boris Lublinsky解释了网格计算是如何被运用于SOA整体架构中的,并介绍了在服务实现中利用网格的编程模型。他同时还介绍了一种支持该建议架构的实验性网格实现。
我们建议使用一个简化的、工作流友好的API来保护组织平台代码不受特定服务网格实现细节的影响。
本次分享介绍通过自研服务网格平台,提升业务稳定性与快速变化能力的经验。
本篇探讨微服务架构中服务交互的重要性,分布式系统的典型挑战,以及像服务编排和服务网格这样的先进架构模式如何帮助我们克服这些挑战。
在大规模分布式系统的负载均衡中,子集是一种常用的技术。数以千计的关键微服务提供了支持。接下来,我们将会探讨尝试在网格架构中扩大任务的数目所面临的挑战,并会探讨最初的子集方法的问题。
该文章简要介绍了服务网络的定义及其在网络中的作用,包括负载均衡和服务发现,并介绍了在服务网格管理中的两个重要工具Linkerd和Istio,最后介绍和网络安全相关的工具Project Calico
AWS App Mesh 帮助您大规模运行和监控 HTTP 和 TCP 服务。
2021 年的服务网格正从当年那个狂奔的“少年”、“流量明星”,成长为真正的“实力派”
经过两年的架构演进,Snap从单体迁移到了云托管的微服务,计算成本降低了65%,同时减少了冗余并提升了客户的可靠性,所有的这些迁移都满足了安全性和隐私合规性的需求。
服务网格是如何出现的?为什么我们需要服务网格?我们又能对服务网格作何期待?
采用服务网格具有巨大的价值,但它必须以轻量级的方式进行,以避免不必要的复杂性。
许多客户正在将其应用程序从旧系统迁移到云中。网格扩展在其中扮演着重要的⻆色,它将 Kubernetes 服务和其他在虚拟机或物理机上运行的服务集成到服务网格中。