多年来，微服务在API领域一直大行其道，它为开发人员提供了诸多优势。这种服务只做一件事，因此它们通常易于管理、范围较小。微服务由此得名！但是微服务的更大优势之一恰恰也导致了其更大的劣势之一：在大规模环境下管理大量的这种服务可能既繁琐又耗时。这时候服务网格有了用武之地。当我们深入研究服务网格时，会发现它与SOA有着很多共同之处。正如Jeff Foster在一篇关于该主题的博文中指出：“SOA在上世纪90年代有类似的想法，但围绕它的技术很笨拙……它似乎涉及大量的XML，这从来就不是好的开端！”服务网格仅仅是SOA背后思想的另一个迭代版本，还是它代表更多的东西？不妨一探究竟。服务网格与微服务的管理密切相关，其目的是更有效地帮助管理构成应用程序或服务的许多不同的微服务。使用服务网格需要分解服务的交互方式，数据平面负责管理微服务之间的联系，而控制平面用于管理微服务（或者确切地说是与微服务关联的sidecar），并评估其性能。乍一看，这种架构似乎与面向服务的架构（SOA）和企业服务总线有着很多共同之处，企业服务总线通常与SOA相关联，用于功能间通信。在我们更深入地比较服务网格与SOA的使用之前，不妨先看看每种架构的一些原则：•重视限界上下文（bounded contexxt）这一概念•单线程，通常使用事件循环功能用于非锁定I/O处理•容器在MSA中运行非常顺畅，被认为非常适合DevOps模式这些类型的架构确实有一些相似之处，比如可重用性对于微服务而言就跟对于SOA而言一样重要。然而，我们也可以看到上述两种方法的原则之间存在一些显著差异。有鉴于此，它们的应用也可能不一样。看过上述内容后，你可能开始了解每种方法可能适合哪种类型的环境。比如说，SOA历来为大型应用程序和复杂的业务流程提供框架，而MSA可能用于开发人员希望保留更大程度的控制权这种情况。BMC一篇关于该主题的博文表明：“随着业务发展壮大，组织可能需要复杂的请求转换和异构系统集成等功能。在这种情况下，组织常常求助于SOA模式以取代MSA。”换句话说，无论过去还是现在，SOA在企业发展中具有一定的重要性。即使Istio、Linkerd和Consul等服务有助于实施服务网格，使用服务网格也面临着改变这种观念即SOA的巨大阻挠。而服务网格的实施得到了积极奉行敏捷思维的开发人员的帮助，他们渴望专注于构建服务，并为业务增添价值，而不是连接服务。像Netflix这些公司采用服务网格也起到了推波助澜的作用。值得一提的是，虽然我们在本文中将两者放在一起阐述，但服务网格不一定非得是微服务架构的一部分。相反，你可以将使用服务网格视为处理MSA带来的一些问题的一种方法。
wendy 