|
软件行业走了很长一段路，在整个过程中，软件体系结构也已经发展了很多。经历了1层（单节点），2层（客户端/服务器），3层和分布式，我们在此过程中看到了一些不同的软件架构模式。 微服务面临的挑战大多数软件公司，正从单体架构(Monolithic)过渡到微服务架构(Microservices)，而微服务架构(Microservices)也正在逐步接管软件行业。单体架构虽然有很多好处，但在满足现代软件开发需求时也有很多缺点。 微服务架构使我们能够更频繁，更独立地部署应用程序，并可靠地满足现代软件应用程序开发要求。 将单体应用分解为微服务应用 微服务架构几乎解决了单体架构的所有缺点。微服务提供了故障隔离，满足应用更小，更快的部署，具备应用的可伸缩性，使得不同服务可以采用不同的开发技术，提高了开发效率，满足了以业务为中心的需求。 尽管微服务架构相对于其他架构具有许多优势，但它也面临着一系列挑战。在微服务体系结构中，它必须处理与设计分布式系统时遇到的问题。 微服务架构背后的思想是，我们将拥有多个独立的较小服务集，每个服务提供单独的业务功能，而不是拥有一个大型的单个代码库。通过这种方法，现代软件应用程序将需要几十个、甚至数百个单独服务的协同工作。 通过微服务架构，引入了网络依赖，并引发了可靠性问题。网络可靠性，延迟，带宽和网络安全性，是我们必须处理的一些与网络相关的挑战。 在服务之间实现通信也将是一项艰巨的任务。随着服务数量的增加，我们必须处理它们之间的交互。除了服务之间的通信外，我们还必须处理整个系统运行状况的监视，容错，日志记录和遥测功能，处理多点故障等等。使用微服务架构，由于我们必须处理许多服务间通信和基础网络，因此调试问题可能会更加棘手。
开发人员使用第三方类库和组件（例如Eureka，Ribbon，Hystrix）来提供这些通用功能，例如服务发现，负载均衡，断路器，日志记录和度量，遥测等。 结合了业务功能和网络相关功能的微服务 但是，使用第三方库和组件会带来一系列不同的挑战，例如：
没有服务网格体系结构的微服务 尽管微服务架构提供了很多好处，但是开发人员在面对上述挑战时也面临很多困难。这些挑战促使开发人员找到了更好的替代方案–Service Mesh(服务网格)。 微服务的解决方案服务网格可以定义为处理微服务架构中服务间通信的专用基础结构层，从而降低了上述挑战带来的复杂性。Service Mesh使我们能够成功，高效地运行分布式微服务架构，并提供保护，连接和监视微服务的统一方法。
通常，Service Mesh提供以下功能：
有了Service Mesh，我们不必使用任何第三方库/组件，就可以在每个微服务中提供与网络相关的通用功能，例如配置，路由，遥测，记录，断路等。Service Mesh将把那些与网络相关的通用功能抽象/外部化为一个单独的组件/层，称为“服务代理”。 服务网格将应用程序中使用第三方库/组件的复杂性解耦。 现在，开发人员可以根据与应用程序或网络相关的问题轻松排查任何问题的根本原因，从而使他们的生活变得异常便捷。借助Service Mesh架构，业务功能和与网络相关的功能之间的职责分工清晰。 具有服务代理(Sidecar)的微服务
具有服务网格架构的基于微服务的解决方案 总而言之，采用基于服务网格架构的微服务，开发人员：
结论微服务架构由于其优于其他架构模式的优势，正在积极地控制软件工程行业。随着越来越多的组织从单体架构过渡到微服务架构，作为开发人员，我们需要了解微服务架构中的挑战并找到解决方法。Service Mesh架构解决了微服务架构引入遇到的一些挑战。 现在我们知道了服务网格在微服务架构中的作用和重要性，下面让我们看一下可以在下一次开发活动中使用的服务网格产品/平台。Linkerd， Envoy Proxy， Istio， Consul， Kuma和 Open Service Mesh（OSM）是我们可以使用的一些领先的开源的Service Mesh平台。它们中的大多数经过了大量测试，可以投入生产使用。 译者：王延飞 译文链接：https:///articles/the-service-mesh-in-the-microservices-world |
|
|
