微服务的服务网格

文章译者: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 条评论
登录 后参与评论

相关文章

来自专栏小白课代表

matlab 2014a

MATLAB是matrix&laboratory两个词的组合,意为矩阵工厂(矩阵实验室)。是由美国mathworks公司发布的主要面对科学计算、可视化以及交互式...

982
来自专栏数据和云

问诊白求恩之性能分析:把握趋势比你更了解你的库

如果问你,你的数据库性能如何,你会怎么回答呢? DBA 甲: db file sequential read等待事件经常出现,不知道什么原因。 DBA 乙:平常...

3255
来自专栏Crossin的编程教室

爬虫万金油,一鹅在手,抓遍全球

第一点没什么捷径可走,套路见得多了,也就有经验了。关于第二点,今天咱们就来介绍一个小工具,在某些需求场景下,或许可以给你省不少事。

802
来自专栏高性能服务器开发

2 网络游戏服务器开发框架设计介绍

在开发过程中,会先有一份开发大纲或是一份策划案,但是这些在我的开发中可能不会有,或者即使有,也很有可能是我随性写下来的,但是我会尽可能写好它。

1602
来自专栏CSDN技术头条

eBay:如何用HDFS分层策略优化数千节点、数百PB的数据存储

目前在eBay的Hadoop集群有数千个节点,支持成千上万的用户使用。他们的Hadoop集群存储数百PB的数据。这篇文章中将探讨eBay如何基于数据使用频率优化...

2006
来自专栏有趣的Python和你

简书非官方大数据新思路专题URL专题管理员URL粉丝和关注URL优点和缺点

1005
来自专栏跟着阿笨一起玩NET

数据库水平切分的原理探讨、设计思路--数据库分库,分表,集群,负载均衡器

数据量巨大时,首先把多表分算到不同的DB中,然后把数据根据关键列,分布到不同的数据库中。库分布以后,系统的查询,io等操作都可以有多个机器组成的群组共同完成了。...

762
来自专栏DevOps时代的专栏

如何在主干开发模式中使用 Pull Request 做代码评审

而拉式请求(Pull Request)的模式,在 GitHub 网站作为分布式代码协作的一种模式被成功运用之后,也很快成被很多团队引用到 Git Flow 中的...

763
来自专栏机器人网

工业机器人控制系统的组成

(1)控制计算机:控制系统的调度指挥机构。一般为微型机、微处理器有32位、64位等,如奔腾系列CPU以及其他类型CPU。

1013
来自专栏java、Spring、技术分享

从零开始学架构读书笔记

  软件架构的出现是为了解决系统规模增加后出现了系统耦合严重,开发效率低,逻辑复杂,扩展困难等问题。所以架构设计是为了解决软件复杂度而存在的,所以架构设计的目地...

3414

扫码关注云+社区