服务网格重蹈ESB的覆辙?为什么需要SMI服务网格接口? - samnewman

19-05-23 banq
                   

SMI(Service Mesh Interface)是一组API,允许不同的服务网格(Service Mesh)相互操作。

微软的这篇文章概述了SMI背后的一点,摘录部分内容如下:

今天,我们很高兴推出Service Mesh Interface(SMI),它定义了一组通用的可移植API,为开发人员提供跨不同服务网格技术的互操作性,包括Istio,Linkerd和Consul Connect。SMI是一个与微软,Linkerd,HashiCorp,Solo.io,Kinvolk和Weaveworks合作开展的开放项目,受到Aspen Mesh,Canonical,Docker,Pivotal,Rancher,Red Hat和VMware的支持。

多年来,网络架构的流行做法是让管道尽可能愚蠢,在应用程序端点中构建智能(banq注:哑管与智能端点)。网络的工作只是转发数据包,而加密,压缩或标识身份的任何逻辑都必须存在于端点内。互联网是以这种习惯为前提的,所以你可以说它运作得相当好。

但是,随着像Kubernetes这样的微服务,容器和编排系统的爆炸式增长,工程团队面临着越来越多的网络端点的安全,管理和监控。服务网格技术是通过让网络管道更智能,从而更智能地提供安全管理监控等问题的解决方案。(banq注:与哑管与智能端点的习惯正好相反

服务网格技术不是让所有端点服务来进行加密会话,授权客户端,发出合理的遥测,并在应用程序版本之间无缝转换流量,而是将此逻辑推入网络,由一组单独的管理API控制,这是云原生态系统中的流行模式。

我们看到服务网格技术激增,许多供应商为应用程序开发人员提供了新的令人兴奋的选择。问题是转向网格技术的开发人员必须选择提供者并直接写入这些API。它们被锁定在服务网格实现中。如果没有通用接口,开发人员就会失去可移植性,灵活性,并限制从广泛的生态系统中获益的能力。

Service Mesh Interface提供:

  • Kubernetes网格的标准界面
  • 最常见的网格用例的基本功能集
  • 随着时间的推移灵活地支持新的网格功能
  • 生态系统利用网格技术进行创新的空间

思考

“保持端点智能,管道愚蠢”这是通用原则和想法,上面微软这篇文章直接指出Service Meshes正在逐渐远离这个想法,这是一件好事。

当初企业总线ESB就也是违背这套原则,今天在服务网格上再次出现,说明这个概念很难让人理解!

我第一次听到@jimwebber@iansrobinson所说的 “保持你的端点聪明,管道愚蠢”这句话。这是对生活在中间件中的应用程序智能的反应,需要对中间件进行更改以推出新功能。

这句话“并不”意味着管道本身不应该是一个好的管道。如果您使用消息代理,则希望它执行保证传递等操作。关键是把你的聪明才智放在管道还是端点的问题。

人们过去会在消息代理层中进行业务流程编排,现在看到人们在API网关中也在做同样的事情,这变得很常见了,这些网关很快将成为微服务基础上的企业服务总线(banq注:ESB最初是SOA基础上,由于加入了很多业务,变成泥球和混乱的根源)。

将业务逻辑放入中间件是有问题的,因为您需要协调部署,但也需要协调控制,因为构建应用程序的人通常与管理中间件更改的人不同。

所以,回到原来的概念。保持端点智能和管道愚蠢就是要保持业务功能不受中间件影响,确保您可以更快地发布软件。

服务网格可以帮助我们解决使用微服务架构中出现的一些问题。但作为一种中间件形式,它们容易受到与ESB一样的滥用,只不过现在是表现为API网关。

API网关将和ESB一样形成生产力的泥潭,这些公司可能会在服务网格中犯同样的错误。但我们不能直接责怪这个工具。

但布道推广服务网格的人必须确保他们至少清楚如何使用该工具,因此值得确保我们谈论相同的事情。

如果您想在服务网格中使用与路由,跟踪,流量整形,服务发现等相关的“智能”,那就直接使用吧,但是保持与您的服务,业务功能相关的逻辑在您的控制范围内,如果您开始让这些东西渗透到您的中间件中,您将重复90年代所犯的相同错误

顺便说一句,这种在业务功能路由/传输之间分离关注点的想法绝不是新的。我和其他许多人都将@TotherAlistair的端口和适配器/六角形架构思想作为微服务中的现有技术架构。

请记住,微服务架构的核心概念是实现独立可部署性,因此我们需要找到构建架构的方法,以便针对此目标进行优化。

因此,如果您发现自己经常需要更改中间件,无论是ESB,API网关还是服务网格,请暂停一下,问问自己,您的架构是否适合您,或者您是否在为您的架构工作?

                   

1