微服务的服务网格

文章译者:suren

在过去几年内,微服务架构已经发展了很多,而且有很多新的概念和模式融合进来。”服务网格”的概念变得流行起来。在本文中,我计划介绍服务网格相关的概念,以及如何用在真实的微服务中。

为什么要有“服务网格”?

正如很多融合技术,微服务架构周围有很多是炒作。大多数人认为微服务是所有问题的答案,之前的架构包括:SOA/ESB。

然而,当我们观察真实世界中的微服务实现,我们可以看到大多数功能的支持现在已经在微服务层面实现,例如:总线(ESB)。所以,我们或多或少都在解决相似的基础问题,但是,我们是在微服务的不同方面来解决的。

图1:从集中集成/ESB到微服务

例如:让我们来看一个场景,你需要以弹性的方式来调用多个下游服务,并作为一个组合服务把这个功能暴露。

如图1所示,通过ESB架构,你可以轻松地发挥ESB内在的能力,对于构建虚拟、组合服务和功能,例如断路器、超时和服务发现等等,在内部服务通信中是很有用的。

当你用微服务实现相同的场景时,你不再需要一个集中集成、ESB,而是一套组合、原子微服务。因此,你不得不在微服务层面实现所有的这些功能。

图2:微服务组件和服务间通信

因此,一个给定的微服务与其他服务(图2),包括:

  • 业务逻辑 实现业务功能,计算和服务组合、集成逻辑。
  • 网络功能 处理内部服务通信机制(通过给定的协议启用基本服务,实现弹性、稳定、服务发现等)。这些网络功能是基于操作系统层面的网络。
  • 现在想一下要实现这样的一个微服务需要付出的工作。从头开始实现面向服务通信这样的功能简直就是个噩梦。你将会不得不话大量的时间来维护面向服务通信功能,而不是关注在业务逻辑上。
  • 而且,如果你使用了多种技术(例如图1中显示的多种语言)来构建微服务的话,甚至会更糟糕。 因为,你需要在不同语言上付出相同的精力(例如:熔断器不得用Java、Node、Python等语言来实现)。

实现微服务架构过程中最复杂的挑战不是构建服务本身,而是服务之间的通信。

由于大部分内部服务之间的通信需要是通用的,我们可以考虑把这种任务抽离到一个层上,我们就可以保证这个服务代码的独立性。这就是“服务网格”的由来。

什么是“服务网格”?

简单来说,服务网格也就是内部服务通信框架。在服务网格中,

  • 在微服务中,不会直接和其他服务通信。
  • 所有服务间的通信将会取代软件组件之间的调用成为服务网格(或 side-car 代理)。
  • 服务网格默认提供部分网络功能,例如:弹性、服务发现等。
  • 因此,服务开发者可以更多地关注业务逻辑,而大部分网络通信相关的工作交给来服务网格。
  • 例如:当你的微服务调用其他的服务时,不用再担心断路器问题。那已经是服务网格的一部分了。
  • 服务网格是语言无关的:服务网格代理通信对微服务来说建立在标准的协议之上,例如:HTTP1.x/2.x, gRPC等,你可以用任何技术来写你的微服务,都是可以兼容服务网格。

图3:通过服务网格实现服务间通信

让我们进一步了解图3所展示的服务交互和责任。

业务逻辑

服务的实现应该包含业务功能。这包括:业务相关的逻辑,计算,和其他服务、系统或者服务的集成,复杂的路由逻辑,不同消息类型间的映射逻辑等。

原始网络功能

尽管我们把大部分网络功能都交给了服务网格,但服务还是必须包含和服务网格或者 side-car 代理之间基本的高级网络交互。

因此,服务的实现必须使用特定的网络库来初始化网络(只是对服务网格的)调用。大多数情况下,微服务开发框架都嵌入了必要的网络库。

应用网络功能

还有一些应用功能和网络紧耦合,例如:断路器、超时、服务发现等。那些已经明确地从服务代码、业务逻辑中分离,并且服务网格使得这些功能开箱即用。

大多数初期的微服务实现简单地忽略了从中央 ESB 层提供的网络功能,他们从服务层面粗糙地实现了这些功能。现在他们已经开始意识到有一个类似网格这种分享功能的重要性。

服务网格控制层面

所有服务网格代理都是由控制面板集中管理。当需要支持访问控制、服务发现等能力时,这就是很有用的。

正如我们之前看到的,服务网格提供了一套应用网络功能,一些(原始的)网络功能依然是作为微服务本身实现的。

没有固定和快速的规则来说明哪些功能应该由服务网格提供。大多数通用的特性是由服务网格提供的。

  • 内部服务间的弹性通信:断路器、重试和超时、故障注入、故障处理、负载均衡和故障切换。
  • 服务发现:通过服务注册表发现服务断点。
  • 路由:原始的路由功能,没有业务相关的路由逻辑。
  • 可观测性:指标、监控、分布式日志、分布式跟踪。
  • 安全:传输层安全(TLS)和 key 管理。
  • 访问控制:基于访问控制的简单的黑名单和白名单。
  • 部署:原生支持容器。Docker 和 Kubernetes。
  • 服务间通信协议:HTTP1.x,HTTP2,gRPC

服务网格实现

Linkerd 和 Istio 是两个流行的开源服务网格实现。它们的架构相似,但实现机制不同。你可以在这两个服务网格的实现上做个比较。

服务网格 - 赞成和反对

让我们快速地对比下对服务网格的两个观点。

赞成

  • 特点是在微服务代码之外实现,具有可重用性。
  • 解决了我们过去在微服务架构中的点对点方案:分布式跟踪、日志、安全、访问控制等等。
  • 在选择微服务实现语言上有了更多的自由:你不用担心是否选择的语言是否支持或者是否有构建网络应用功能的库。

反对

  • 复杂:在微服务实现中,如果有服务网格的话会增加很多运行实例。
  • 增加了额外的跳跃点:每个服务调用不得不通过一个额外的跳跃点(通过服务网格 sidecar 代理)。
  • 服务网格解决了一部分问题:服务网格仅仅解决了内部服务通信的一部分问题,但要解决你的微服务中的业务逻辑,还有很多复杂的问题,例如:复杂路由、类型转换映射、于其他服务和系统的集成。
  • 不成熟:要作为产品进行大规模部署的话,服务网格技术相对较新。

总结

总体来说,服务网格在微服务架构中解决了一些关键的挑战。它让你在选择微服务实现技术上有了更多的自由,让你可以更多地关注在业务逻辑上,而不是服务间的网络通信上。然而,服务网格解决不了任何业务逻辑相关的问题,或服务集成、组合的相关的问题。

原文发布于微信公众号 - DevOps时代(DevOpsTimes)

原文发表时间:2018-05-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

世上没有完美的架构

微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架...

1287
来自专栏逸鹏说道

80.8亿个微信红包技术难点在哪里?

摘要:今年除夕当日微信红包的参与人数达到4.2亿人,收发总量达80.8亿个,是羊年除夕10.1亿个的8倍。最高峰发生在00:06:09,每秒钟收发40.9万个红...

40518
来自专栏SDNLAB

容器和云给网络带来巨大的压力

鉴于开发人员已经开始采用敏捷、方便的可编排技术,因此会越来越多地采用基于容器的应用程序。但是当这些应用程序进入生产阶段时,他们的编排解决方案对操作复杂性产生了相...

3279
来自专栏织云平台团队的专栏

日进斗金的银行业务保障,靠这样的运维服务!

金融行业作为国家命脉行业,对其业务运维管理方式和平台的侧重型都有特殊的考量。那么,在为金融机构做 DevOps 方案时,该如何帮助这些机构管理私有云 IaaS ...

3123
来自专栏Linyb极客之路

SpringCloud和微服务

马丁福勒微服务论文:https://martinfowler.com/articles/microservices.html

613
来自专栏逸鹏说道

解析微服务架构(一):什么是微服务

解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容,并以IBM技术为例介绍如何实现微服务架...

2714
来自专栏云计算D1net

混合云计算部署的三个要求

如今,许多IT专业人员倾向于采用混合云方法,让企业的不同工作负载在内部部署数据中心或在公共云中这样彼此独立的情况下运行。然而,对于大多数企业来说,采用更多的是混...

3226
来自专栏程序你好

微服务Microservices——应用架构的未来

能够构建、演变和扩展大型应用程序对于组织来说是至关重要的,但是所涉及的挑战使其成为一项困难的任务。正因为如此,微服务已经成为构建现代云应用的主导模式,它将单个组...

972
来自专栏服务端思维

「图解后端」服务扩展的三维模型

水平扩展通过增加更多的服务器来分散负载,从而提高性能。例如,上面提到的集群优化就属于水平扩展。通过更多的服务器部署集群来提供相同的服务,并进行负载均衡来提高读性...

713
来自专栏织云平台团队的专栏

腾讯云运维干货沙龙-海量运维实践大曝光 (三)

12月16日,首期沙龙“海量运维实践大曝光”在腾讯大厦圆满举行。沙龙出品人腾讯运维技术总监、复旦大学客座讲师、DevOps专家梁定安,讲师腾讯手机QQ运维负责人...

5161

扫码关注云+社区