【编者的话】本文是微服务网格系列的第一篇,通过阐述微服务网格的概念、优势及其核心思想,让读者对网格先有个基础了解,方便进一步熟悉网格的原理及其带来的实际好处。
如果你在过去几年中一直关注分布式和云架构的发展趋势,那么你可能已经听过很多关于微服务的消息。 自几年前微服务概念推出以后,它就逐渐变成企业云部署的热点。 越来越多的公司宣布他们转向微服务,并发布博客文章和新闻稿来庆祝它。
尽管转向微服务是值得庆祝的,但许多公司却并不知道幕后发生了什么。如果实施得当,微服务能解决单体架构中许多令人头疼的问题:它们易于迭代,团队清晰,代码分解为可管理的组件。 然而,许多庆祝文章都没讲清楚要获得微服务优势所需要做的后续工作。
今天,我们将深入幕后看一看。 我们将了解一种特殊的技术,微服务网格,它可以平滑微服务的粗糙边缘,并使开发人员更容易在微服务框架中工作。 希望看完本文以后,你可以更全面地了解网格如何适应你的微服务部署。
微服务网格(有时也称为服务网格)是一个抽象层,用于定义应用程序中不同微服务之间的交互。 网格使用不同容器之间的网络来控制应用程序不同组件的交互方式。 虽然这听起来很抽象,但它实际上是一个非常实用的概念。 容器通过网络进行交互,因此更改网络拓扑允许你重新定义容器的交互方式。
因为组件之间的网络在微服务中是非常基础的,所以通过微服务网格操纵网络可以让你完成一些非常有用的事情。例如,在部署组件的新版本时,你可以立即将网络设备从旧实例指向新实例,而无需任何配置。或者,如果你在扩展方面遇到困难,可以使用网格指向不同服务的不同负载均衡器,并增加应用程序不同组件的容器数量。
在开始使用微服务时,一个常见的建议是将应用程序中的不同组件视为来自完全不同的提供商的API。微服务网格通过精确定义哪些网络位置有哪些可用的服务,从而使你能够在网络级别实现此功能。你无需在服务移动或重新定义时更改配置,而是进行网络更改。
微服务因其扩展能力以及将大型应用程序分解为可消化组件的能力而受到称赞。 相比之下,单体应用程序闪耀的地方是集中化很重要的领域。单体应用记录日志更容易,因为它们在一个地方运行。 版本控制也更容易,因为你只要覆盖单个实例。 当开发人员从单块设备切换到微服务时,它们经常会迷失。 没有一个中心位置可以登录,或者确认他们所需要的服务版本。
网格思想的关键思路是,在许多情况下,某些信息来自一个真实的中心来源,即网络层。考虑我们上面提到过的部署新版本组件的情况。使用基于网格的应用程序,你可以控制其他容器可通过网络查看哪些容器,而不是破坏托管旧版本的所有容器并使用新版本启动新容器(并对依赖于新服务的组件重复此过程)。
这意味着如果你想部署新版本,你可以根据需要使用DNS指向新容器。或者指向新的负载均衡器。或者更改现有负载均衡器指向的容器。
通过关注应用程序组件(它们运行的网格)背后的网络,你可以保留一些集中化,使它们像在单体世界中的管理一样变得更加容易。想要更深入地了解流量如何通过你的应用流量?在组件之间向网络添加一些监视即可。需要加强安全性?添加更严格的加密并在组件之间强制执行HTTPS即可。 服务网格使这一切成为可能。
在接下来的几周内,我们将深入探讨微服务网格如何运行以及它在实际例子中用于某些微服务部署的用途。 我们将专注于网格为微服务带来的实际好处:控制,可管理性以及洞察大型应用程序中正在发生的事情。
原文链接: Microservices Mesh — Part I (翻译:池剑锋)