ServiceMesh是一种技术吗
本篇内容介绍了“Service Mesh是一种技术吗”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
创新互联专注于和平企业网站建设,响应式网站设计,成都做商城网站。和平网站建设公司,为和平等地区提供建站服务。全流程按需定制网站,专业设计,全程项目跟踪,创新互联专业和态度为您提供的服务
Service Mesh从何而来?
在过去几个月里,Service Mesh是行业内毋庸置疑的焦点。关于Service Mesh、关于软件架构未来的文章观点,围绕着不同的技术供应商而高度分化,不过有一点共通的事,对于如何在企业中使用API的快速转换,以及这对于我们流量的拓扑意味着什么。
服务API主要是作为将组织外部开发人员与内部系统连接起来的边缘接口,以及将这些内部系统(微服务)绑定到功能整体的“粘合剂”存在的。因此,面向微服务体系结构不可避免会出现数据中心内部通信增加的情况。tongguo的不可避免的结果之一是数据中心内的 内部通信将增加。Service Mesh作为一种潜在的解决方案出现了,它通过提供一个不同的框架来部署现有技术,从而解决了东西部流量增加带来的挑战。
Service Mesh是一种模式,而非技术
正如微服务是一种模式而不是一种特定的技术一样,Service Mesh也是一种模式。区分这两者听起来比实际要复杂得多。如果我们从面向对象编程(OOP)的角度来考虑这个问题,一个模式描述的是接口,而不是实现。
在微服务的背景下,Service Mesh部署模式能够通过sidecar代理,更好地管理东西流量。当我们拆分系统并使用微服务构建新产品时,我们流量的拓扑结构也正在从外部为主转向内部流量的持续增长。数据中心里的东西通流量增长,缘于我们用网络调用替换过去的函数调用,这意味着我们的微服务必须通过网络来相互通信。但我们都知道,网络有可能是不可靠的。
通过使用不同的部署模式,Service Mesh希望解决东西流量增加带来的挑战。虽然对于传统的南北流量来说,100ms的中间件处理延迟虽然并不理想,但也不是不能接受,不过在东西流量的微服务架构体系中,这样的延迟就不能容忍了。原因是服务之间从东到西的流量增加会增加延迟,当跨不同服务的API请求链被执行和返回时,可能会导致700ms的延迟。
为了减少这种延迟,引入了与微服务进程一起运行的sidecar代理,以删除网络中的额外跳转。Sidecar代理,对应于我们请求执行路径上的数据平面,也提供了更好的弹性,因为我们不再有单点故障。值得注意的是,sidecar代理承担了为我们的微服务的每个实例都有一个代理实例的成本,这需要一个很小的占用空间,以最小化资源损耗。
从功能的角度来看,API管理产品已经提供了多年来所提供的Service Mesh。诸如可观察性,网络错误处理,健康检查等功能是API管理的标志。这些功能本身并不构成任何新颖的功能,但作为一种模式,Service Mesh引入了在我们的体系结构中部署这些功能的新方法。
传统的API管理方案已经跟不上了
为什么大多数传统的API管理解决方案不允许这种新的部署选项?因为他们“出生在一个单一的世界”。
事实证明,Docker和Kubernetes出现之前构建的API管理解决方案本身就是一个整体,并没有被设计成在新兴的容器生态系统中有效工作。传统API管理解决方案所提供的重量级运行时和较慢的性能在传统的边缘API用例中是可以接受的,但是在微服务体系结构中,延迟会随着时间的推移而通过增加东西方向的流量活动而增加。从本质上讲,传统的API管理解决方案最终都过于重量级、难以自动化,并且太慢,无法有效地协调与微服务固有的不断增加的通信。
由于开发人员理解这一点,在容器出现之前诞生的遗留API管理解决方案引入了他们所谓的“微网关”来处理东西流量,避免重写他们现有的、臃肿的、单一的网关解决方案。问题是,这些微网关虽然更轻量,但仍然需要遗留解决方案与它们一起运行,以便执行策略强制。这不仅意味着在堆栈中保持原来的重型依赖关系,还意味着每个请求之间的延迟增加。这就不难理解,为什么Service Mesh感觉上像是一个全新的类别,因为过去的API管理方案已经无法支持需求了。
“Service Mesh是一种技术吗”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!
当前标题:ServiceMesh是一种技术吗
文章地址:http://hbruida.cn/article/gjpcgd.html