换汤不换药，Service Mesh 只是 SOA 重来一遍而已？

作者：Art Anthony

多年来，微服务在API领域一直大行其道，它为开发人员提供了诸多优势。这种服务只做一件事，因此它们通常易于管理、范围较小。微服务由此得名！

但是微服务的最大优势之一恰恰也导致了其最大的劣势之一：在大规模环境下管理大量的这种服务可能既繁琐又耗时。这时候服务网格有了用武之地。

当我们深入研究服务网格时，会发现它与SOA有着很多共同之处。正如Jeff Foster在一篇关于该主题的博文中指出：“SOA在上世纪90年代有类似的想法，但围绕它的技术很笨拙……它似乎涉及大量的XML，这从来就不是好的开端！”

服务网格仅仅是SOA背后思想的另一个迭代版本，还是它代表更多的东西？不妨一探究竟。

服务网格（MSA）与SOA的差异

服务网格与微服务的管理密切相关，其目的是更有效地帮助管理构成应用程序或服务的许多不同的微服务。

使用服务网格需要分解服务的交互方式，数据平面负责管理微服务之间的联系，而控制平面用于管理微服务（或者确切地说是与微服务关联的sidecar），并评估其性能。

乍一看，这种架构似乎与面向服务的架构（SOA）和企业服务总线有着很多共同之处，企业服务总线通常与SOA相关联，用于功能间通信。

在我们更深入地比较服务网格与SOA的使用之前，不妨先看看每种架构的一些原则：

面向服务的架构（SOA）

•“尽可能多共享”的架构

•业务功能重用的重要性

•通用的治理和标准

•用于通信的企业服务总线（ESB）

•多种消息协议

•所有服务部署到上面的通用平台

•多线程，处理I/O的开销更大

•最大的应用服务重用性

•更可能使用传统的关系数据库

•在DevOps模式中并非首选

微服务架构（MSA）

•“尽可能少共享”的架构

•重视限界上下文（bounded contexxt）这一概念

•宽松的治理，更注重人

•高效协作，可自由地选择平台和技术

•简单、不太复杂的消息系统

•HTTP/REST和AMQP等轻量级协议

•单线程，通常使用事件循环功能用于非锁定I/O处理

•容器在MSA中运行非常顺畅，被认为非常适合DevOps模式

•更专注于解耦

•使用现代的非关系型数据库

这些类型的架构确实有一些相似之处，比如可重用性对于微服务而言就跟对于SOA而言一样重要。然而，我们也可以看到上述两种方法的原则之间存在一些显著差异。有鉴于此，它们的应用也可能不一样。

服务网格（MSA）的应用vs SOA的应用

看过上述内容后，你可能开始了解每种方法可能适合哪种类型的环境。

比如说，SOA历来为大型应用程序和复杂的业务流程提供框架，而MSA可能用于开发人员希望保留更大程度的控制权这种情况。

BMC一篇关于该主题的博文表明：“随着业务发展壮大，组织可能需要复杂的请求转换和异构系统集成等功能。在这种情况下，组织常常求助于SOA模式以取代MSA。”

换句话说，无论过去还是现在，SOA在企业发展中具有一定的重要性。即使Istio、Linkerd和Consul等服务有助于实施服务网格，使用服务网格也面临着改变这种观念即SOA的巨大阻挠。

而服务网格的实施得到了积极奉行敏捷思维的开发人员的帮助，他们渴望专注于构建服务，并为业务增添价值，而不是连接服务。

像Netflix这些大牌公司采用服务网格也起到了推波助澜的作用。

服务网格从SOA的灰烬中崛起？

值得一提的是，虽然我们在本文中将两者放在一起阐述，但服务网格不一定非得是微服务架构的一部分。相反，你可以将使用服务网格视为处理MSA带来的一些问题的一种方法。

在SOA中，使用企业服务总线必不可少。但是正如IBM的博文所述：“在许多其他组织，ESB已渐渐被视为瓶颈。对一个集成进行更改或改进可能会破坏使用这同一个集成的其他组织的稳定性。”

尽管初衷出于善意，但这意味着使用ESB的SOA存在单一故障点，而微服务独立运行的MSA并非如此。这是这里的一个关键点，因为它表明了服务网格在多大程度上提升了SOA的一些概念。

使用服务网格提供了更深入的可见性，从而更容易发现和诊断问题。此外，面对失效的服务，它们可以重新路由请求，而不会导致整个服务中断。

SOA和使用服务网格之间肯定有相似之处。然而，说服务网格不如SOA功能强大得多的第二版（v2）简直有辱前者。实际上，在大多数情况下，服务网格远远胜过SOA。