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

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网关还是服务网格，请暂停一下，问问自己，您的架构是否适合您，或者您是否在为您的架构工作？