戳破微服务的七大谎言 _微服务

文章插图

作者 | Scott Rogowski
策划 | 万佳
转发链接：https://mp.weixin.qq.com/s/QtYw0xdC3KN2gNAqHubIOg
前言在现代技术公司（无论大小）的架构中，微服务已经无处不在。但是，它们真的比以前的开发模型更优秀吗？在这篇文章中，我将揭穿工程师们关于微服务所讲述的七大谎言，以及为什么它可能是一种反模式。
免责声明 1：我不是架构师，也没假装自己是架构师。本文内容只是我多年来作为软件开发人员 / 经理所做的观察总结。我曾见证两家公司在微服务架构的压力下陷入泥潭。由于很少有人深度质疑这种新生范式，因此我想表达自己的声音。不过，我经验有限，所以也欢迎反馈意见。
免责声明 2：互联网上也有其他标题相似的演讲 / 文章，这里就不纠结这种相似度了。
单体架构和微服务之间有何区别？开始研究谎言前，我们先来定义一下术语。后端软件架构可以分为单体和微服务两种。单体架构指的是由一台或多台服务器运行单个应用程序，其通常从单个存储库中部署。使用多台服务器时，这些服务器将运行相同的代码。从 90 年代到 2000 年代，多数情况下这都是默认的架构。
随着互联网的发展，大型公司开始面临单体架构的局限。为解决这一问题，公司开始将其代码分割成在不同服务器上运行的多个组件。例如，一家公司可能会有运行日志记录的服务、调用外部 API 的服务以及管理数据库的服务。亚马逊 AWS 在这一风潮中扮演了重要角色，因为它让部署服务器和管理基础设施的工作变得非常容易。

文章插图

随着时间流逝，中小型公司也开始接受这种新的发展范式。很快，一个围绕微服务的产业发展壮大起来，它逐渐成为寻求扩展的企业默认架构。不幸的是，现在有许多公司由于这种选择而掉进了各种之前想不到的坑里。
1谎言一：跨服务的关注点分离降低了复杂度“[关注点分离]”指的是在不相关的代码间应存在隔离墙。当不相关的代码需要协同工作时，应该使用抽象良好的接口并尽量减少状态共享。很多入门编程课程都将其视为标准的软件开发公理。你的代码对其他代码的了解，越少越好。同样，一个函数执行的功能越多，你就越需要考虑运动部件之间的复杂关系（即复杂度）。而且，我们作为合格的工程师就应该努力降低复杂度。
我坚信这一公理。从逻辑上讲，分离关注点的最佳方法是否就是让你的无关代码运行在不同的服务（服务之间以 API 沟通）中呢？
不，并非如此。
经典的单进程关注点分离之所以有效，是因为它可以最小化并简化不相关代码之间的接口。在设计良好的程序中，此接口可以只有带 return 语句的单个函数调用。不相关代码之间的边界本质上是复杂的，而简单的接口有助于管理这种复杂性。
相比之下，在微服务中，函数调用被替换为网络请求。这种新的服务间障碍严格来说更加复杂且更不可靠。首先，每个网络调用都需要一定数量的样板。其次，工程师现在需要默认任何服务随时会失效。相反，在单体中，当代码失败时整个服务都会失败。尽管这听起来很糟糕，但由于现在只有一种故障情况，因此它更易于管理。
在实践中更糟
左下方的图表是几年前 Uber 的微服务架构。它很简单，很容易理解。右边是 Uber 的实际服务地图。

文章插图

我敢说 Uber 的任何人都不知道这个架构是如何工作的。曾在使用微服务架构的大型公司工作过的人都知道，Uber 的经验并不是特例。
模型与现实之间存在这种差异的原因有两个。首先，这些图表通常过于简化。架构师设计这些图表是为了交流，而非完美反映现实。但因为它们隐藏了复杂性，也就容易误导决策。如果 Uber 的技术领导者知道自己的架构会变成什么样，他们还会走这条路吗？
其次，一旦你投身于微服务，随后的所有技术决策都将受其影响。因此，开发新功能时总要启动新的服务。架构图很快就会变得非常复杂，膨胀成上图那种密密麻麻的网状结构。
2谎言二：微服务提高开发速度当你采用“关注点分离”公理并将其应用在开发人员头上时会发生什么？你会得到一些孤立的团队，他们之间各自独立。从表面上看这似乎是有益的。如果团队只需要操心自己的服务，那将减轻他们的认知负担，并提高他们的生产力。现在，工程师无需担心基础架构中其他部分的复杂性了。