2018 疯狂微服务之死

会员服务 ·

2018 疯狂微服务之死

2018 年 2 月 9 日 CSDN云计算 dwmkerr

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

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 这样的托管服务，它们会帮你完成复杂的集群管理。

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