2018 疯狂微服务之死

发表时间:2018-02-28

近期微服务的话题非常火爆,有时可谓非常“疯狂”:

Netflix 在 devops 上做得很棒,同时 Netfix 也采用微服务。因此:如果我也用微服务,那么我也可以在 devops 方面做得很好。

很多情况下,为了解决手头的问题,我们付出了巨大的努力采用微服务模式,但是并不清楚它的成本和收益。

接下来我将详细介绍什么是微服务,这种模式吸引人的原因,以及它所面临的主要挑战。

如果你正在考虑微服务是否适合你的模式,我会在文章的最后用一系列简单的问题来帮你做出选择。

什么是微服务,它为什么如此受欢迎?

首先从最基本的开始了解。下图是一个假想的视频共享平台的实现方式,左侧是传统的整体式架构(单个巨型单元),右侧则是微服务:

两种模式的区别在于第一种是整体式架构,只有一个大单元。第二种则由多个小单元构成,每个小单元都是独立的服务。

上图已足够细致,从中很容易找到微服务模式的吸引力所在。以下是微服务架构的具体好处:

独立开发:小型的独立组件可由小型的独立团队构建。一个小组可以专门负责开发“Upload”服务,不用去管其他服务。每个组件的功能变得简单,这样一来,开发人员了解组件的时间大大减少,更容易开发新功能。

独立部署:每个单独的组件都可以独立部署。这样一来发布新功能的速度就更快,风险也更小。假设“Streaming”组件修复了 bug 或者新增了功能,那么部署时并不会影响其他组件。

独立扩展:每个组件可以独立地进行扩展。在新节目刚发布的繁忙时期,可以扩展“Download”组件,以支持增加的负载,而不必扩展所有组件,这样一来扩展更具弹性并且降低了成本。

可重用性:每个组件各自实现一个小的、特定的功能。这意味着它们可以很容易地适用于其他系统、服务或者产品。“Transcode”组件可以被其他业务单元使用,甚至可以改写成一个新的业务,从而为其他组提供转码服务。

从以上细节层面可见,微服务模式相比整体式架构的好处显而易见。如果确实是这样的话——那为什么这种模式最近才开始流行呢?

既然微服务好处多多,为什么没有很早就开始流行呢?

原因有二。第一个原因是它提升了我们的技术能力,另一个是最近的技术进步让我们能够把它带到一个新的水平。

当我开始写这个问题的答案时,发现一两句话无法解释清楚,所以实际上我把它分成了另外一篇文章,稍后再发表。因此在本文中,我将跳过从单个程序到多个程序的过程,忽略 ESBs 和面向服务的体系结构、组件设计以及有限的上下文等内容。

在很多方面我们已经开始使用微服务,随着近期容器技术(特别是 Docker)和集群技术(如 Kubernetes、Mesos、Consul 等等)的普及,从技术的角度来看,微服务模式变得更加可行。

如果我们打算实施微服务,那么在开始之前需要想清楚。从理论的角度我们看到了它的优点,那么它有没有弊端呢?

微服务有什么问题?

微服务模式优点多多,那么它的缺点是什么呢?据我所知它主要有下列问题。

开发的复杂性增加

对于开发者来说事情会变得更加困难。当开发人员开发一个新功能时,如果该功能依赖其他服务的话,那么开发人员不得不在他们的机器上运行所有服务,或者连接到这些服务。这通常比简单地运行单个程序更加复杂。

这个问题可以通过一些工具得到部分缓解,但随着构成系统的服务数量的增加,开发人员在整个系统运行时面临的挑战也越来越多。

运营的复杂性增加

对于维护服务的团队来说,潜在的复杂性是一个巨大的挑战。他们管理的服务不是简单的几个,而是数十、数百甚至数千个正在运行的服务。服务数量越多,通信链路就越多,那么出错的可能性就会变大。

devops 的复杂性增加

以上两点表示开发和运营是分开进行的,随着 devops 的普及(我是 devops 的忠实粉丝),devops 能够缓解这个问题吗?

如今有许多组织仍然依靠独立的开发和运营团队来工作,而也有一些组织更倾向于采用微服务。

对于已经采用了devops 的组织来说,这仍然很难。既是开发者又是运营者已经非常艰难(但是要建立好的软件却很关键)了,还得了解集群容器系统的细微差别,特别是快速发展的系统,那就更困难了。

它需要资深专家

如果开发团队成员都是专家级别,那么结果可能会很好。但想象一下,一个使用单一的整体式系统运行的不是很顺畅。如果增加系统的数量,就会增加运行的复杂性。

通过有效的自动化、监控和集群等技术可以做到。但瓶颈很少在于技术本身,而在于找到能够有效使用这些技术的人。目前这些技能需求非常高,可能很难找到。

真实世界的系统往往界限不清

当我们描述微服务的好处时,经常谈到独立的组件。但是在很多情况下,组件并不是独立的。在论文中,某些领域可能看起来有限,但是当你深入细节时,你会发现他们比你预期的更具挑战性。

事情变得非常复杂。如果你的界限没有明确的定义,那么即使理论上的服务可以单独部署,你也会发现,由于服务之间的相互依存关系,你必须部署一组服务。

这意味着你需要一系列管理协同工作的服务版本,这些服务版本之间的协作需要通过验证和测试,你实际上没有可独立部署的系统,为了部署新功能,你需要仔细编排并同时部署许多服务。

状态的复杂性往往被忽略

在前面的例子中,我提到一个功能的部署可能需要同时部署多个版本的多个服务。假设合理的部署技术可以缓解这种情况,例如 blue/green 部署(大多数服务编排平台可轻松应对),或者并行运行的多个服务版本,以及决定使用哪个版本的通道。

如果服务是无状态的,这些技术可以缓解大量的挑战。但是无状态服务非常容易处理。事实上,如果你有无状态的服务,那么我会倾向于考虑跳过微服务,而考虑使用无服务器模型。

实际上,大多数服务都需要状态。比如我们的视频共享平台例子中的订阅服务。新版的订阅服务可以用新的形式将数据存储在订阅数据库中。如果你并行运行两个服务,则一次运行了两个模式的系统。如果你进行了 blue green 部署,而其他服务依赖于新的数据,那么必须同时更新这些服务,如果订阅服务部署失败并回滚,则需要层级回滚。

你可能会认为在 NoSQL 数据库中这些问题不存在,但事实并非如此。不强制执行模式的数据库并不意味着它是无模式系统 - 它仅仅意味着模式在应用级而不是数据库级进行管理。理解数据的形状及其演变过程的挑战依然存在。

通信的复杂性往往被忽略

当你建立一个相互依赖的大型网络服务时,可能会涉及到很多服务间的通信,挑战随之而来。首先,潜在的失败无处不在。假设网络调用失败了,那么当一个服务调用另一个服务失败时,它至少应当重试几次。服务之间的调用关系越多,那么情况将变得愈加复杂。

假设用户上传视频到共享服务中。那么我们需要运行上传服务,然后将数据传递到转码服务,此外,还得更新订阅和推荐服务。所有这些调用都需要一定程度的协调,如果失败,就得重试。

而重试逻辑可能很难管理。同步运行往往不是很稳定,很容易失败。在这种情况下,更可靠的解决方案是使用异步模式来处理通信。此处面临的挑战是异步模式会使系统具有状态性。如前所述,分布式系统和状态系统很难处理。

当一个微服务系统使用消息队列进行服务内通信时,基本上会有一个大的数据库(消息队列或代理)将这些服务粘合在一起。虽然起初看起来似乎没什么问题,但模式始终是一个隐患。新版本的服务可能会写入新的格式的消息,当发送服务更改发送消息的详细信息时,依赖于该消息的服务也需要更新。

当然可以拥有多个不同格式的消息处理服务,但数量一多就很难管理。当部署一个新版本的服务时,两个不同版本的服务可能会处理来自同一队列的消息,尽管消息来自不同版本的发送服务。这可能会导致复杂的边缘情况。为了避免这些边缘情况的产生,最好是只允许特定版本的消息存在,这意味着你需要将一组服务的版本作为一个整体来部署,以确保先前版本的消息被适当地排除。

这再次表明,当你深入细节时会发现独立部署的想法可能与预期的有所差异。

版本控制变难

为了缓解前面提到的问题,我们需要谨慎管理版本。遵循像 semver 这样的标准能够解决这个问题吗?答案是否定的。Semver 是一个利器,但是你仍然需要跟踪协同工作的服务和 API 的版本。

这件事颇具挑战,你可能自己都搞混,不知道哪个版本的服务可以一起正常工作。

在软件系统中管理依赖关系是非常困难的,无论是节点模块、Java 模块、C 库还是其他东西。独立组件和单一整体之间的冲突很难处理。

当依赖关系是静态,并且能够进行修补、更新、编辑的时候,挑战在所难免。但是如果依赖关系本身是实时服务,那么你可能无法仅仅更新它们 - 你可能需要运行许多版本,或者直到整个系统得到修复。

分布式事务

在需要跨操作交易完整性的情况下,微服务可能会非常痛苦。分布式状态很难处理,很多小的失败单元可能会很难进行集群操作。

可以通过操作幂等性、重试机制等方法来避免这个问题,这些手段在许多情况下能够起作用。但有些情况你需要保证操作的事务性,要么成功,要么失败,而不能处于失败和成功的中间状态。在微服务模型中想要解决这个问题或者实现事务难度是很大的。

微服务可能是一种变相的整体式模型

单独的服务和组件可以独立部署,但是在大多数情况下,你将不得不运行某种集群平台,比如 Kubernetes。如果你使用谷歌的 GKE 或者亚马逊的 EKS 这样的托管服务,它们会帮你完成复杂的集群管理。

但是,如果你自己管理集群的话,那么面对的是一个庞大而复杂的系统。虽然单个服务拥有前文提到的大量优点,但是你依然需要非常小心。这个系统的部署、更新、故障转移等等操作起来都不是那么简单。

在大多数情况下,优点能够得到体现,但是任然不要轻视或低估管理一个庞大而复杂的系统的难度。托管服务可能会有所帮助,但这些服务大都刚刚新起(例如,亚马逊的 EKS 在2017年底才发布)。

微服务的狂热将开始降温

仔细考虑避免加入对微服务的狂热追捧。为了帮助解决这个问题,我已经注意到了一些你可能想问自己的问题,并列举了问题的答案:

点击下载 PDF 版本:microservice-questions.pdf(https://github.com/dwmkerr/blog/raw/master/2018/microservice-madness/images/microservice-questions.pdf)。

不要把微服务和架构混淆

没有微服务架构一说。微服务只是组件的另一种模式或实现。不论微服务是否在系统中使用,它都与架构无关。

微服务在许多方面与打包和操作的技术过程有关,而与系统设计无关。组件边界仍然是工程系统中最重要的挑战之一。

无论你的服务体量有多大,是否在 Docker 容器中,你都需要仔细考虑如何将系统放在一起。这里没有标准答案,只是多一个选择而已。

原文:The Death of Microservice Madness in 2018

链接:http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/

作者:dwmkerr

译者:安翔