5 个微服务误解

关于微服务的许多误解仍然存在，这通常不利于希望将其作为解决所有问题的灵丹妙药的公司。

渴望被认为是酷和时髦的，不仅仅是尴尬的青少年。这种动机也会导致完全成熟的商业主管追逐最新的、闪亮的新技术，仅仅因为那些很酷（和成功）的公司正在使用它。

这并不是说任何给定的技术都缺乏价值。然而，有时新事物——例如微服务、Kubernetes、Lambda 函数或 [插入你自己的酷、新的热门技术]——被采纳或拒绝的原因完全错误。太多时候，采纳来自于仅仅将这些术语视为流行语的人，而不是因为该技术作为一个真正有用的解决方案，适用于一个真正令人恼火的问题。这可能不是他们的问题。这会导致夸张，这对所使用的技术是不公平的。

微服务是当今企业神话的受害者，软件假设创造了合理采用和使用的障碍。现在是时候借助具有实践经验的技术专家来澄清事实了。以下是他们最常遇到的微服务误解。

误解：微服务解决你所有的问题

微服务很棒——只要它们能解决贵公司实际存在的问题。古老的格言在这里适用：“当你拥有的只是一把锤子时，一切看起来都像钉子。”

Redis 的合作伙伴解决方案架构师 Lars Rosenquist 说：“许多公司认为，‘我们有这个应用程序环境，而微服务是答案。’” “但首先你需要了解微服务是什么；其次，你需要了解你自己的应用程序架构的问题；然后两者之间需要匹配。而这种情况很少发生。”

许多技术在特定的规模上解决特定的问题。“如果你是一家像 Netflix 这样的公司，并且你的应用程序消耗了三分之一的互联网流量，你将不得不使用你的架构来解决这个问题，” Rosenquist 解释说。 “但如果你是一家规模较小的公司，例如一家本地银行，你就不会以这种规模运营——因此你不需要解决这个问题。人们经常针对他们想要解决的问题进行优化，而不一定是针对他们已经存在的问题进行优化。”

人们经常针对他们想要解决的问题进行优化，而不一定是针对他们已经存在的问题进行优化。

Lars Rosenquist

Redis 合作伙伴解决方案架构师

大多数用例不需要微服务。一些编程专家建议，避免“单体应用不好，单体应用是过时的做事方式”的心态。相反，在采用微服务方法之前，尝试证明自己关于该前提的看法是错误的。

误解：微服务降低复杂性

事实上，微服务架构几乎总是会增加复杂性。更糟糕的是：如果放任不管，它会变成一个分布式单体——那样会变得一团糟。

微服务无法解决系统设计问题。“如果你无法创建一个具有高内聚和低耦合的单体设计，那么使用微服务可能会更糟，” iDIA Computing 的软件开发顾问兼教练 George Dinwiddie 说。

从一个单体开始，然后在你添加团队时从中提取服务，一些开发人员建议。康威定律适用。

Rosenquist 说：“使用单体应用程序，你将所有逻辑、通信和复杂性都放在一个应用程序中。使用微服务，你会将此反过来。” 结果：所有这些通信模式等现在都是你基础设施的一部分。

Rosenquist 认为，许多公司并不真正了解这个问题。他们认为他们可以通过微服务来消除复杂性。但你并没有真正消除它；你只是将其移动到不同的抽象层。

“假设你有两个应用程序组件相互通信。它们位于同一个应用程序中，在同一个进程中，在同一个 CPU 中。该应用程序非常快，并且不太可能失败，” Rosenquist 说。但是使用微服务，你将这些应用程序组件放在不同的机器上，并在它们之间放置一个网络、整套基础设施，甚至可能放置不同的云。 “这变成了一个完全不同的挑战——不仅仅是在通信和故障模式方面，而且在性能方面也是如此。”

借助现在可用的工具，管理复杂性变得更容易，但不要忽视复杂性仍然存在。首先，复杂性使得调试应用程序变得更加困难。为了使管理复杂性变得更容易，请确保你的监控和可观察性工作到位。

Rosenquist 指出，虽然微服务方法确实使你的代码不那么复杂，但在部署或管理它时并不总是更容易。 “你不再需要调试一个应用程序，而是需要调试六个或十个。这些应用程序也在多个实例上运行，这些实例也在整个架构中进行负载平衡。” 为了组装所有这些，请注意诸如日志聚合和可观察性之类的事情。所有这些通常都比拥有单个应用程序更复杂。

不太复杂的代码并不一定转化为不太复杂的系统。“从代码的角度来看，单个服务可能更容易在孤岛中理解，” Redis 的开发人员增长负责人 William Johnston 指出。 “但是你使用微服务创建的系统的复杂性变得比单体应用复杂得多。”

这也意味着更多的开发时间，尤其是在已经超负荷的小团队中。这并不总是坏事，因为它迫使开发人员学习应用程序领域和整个系统。从长远来看，这可以使重构更容易，因为它使整个系统的耦合性降低。但是，这会带来高昂的代价，并且开发人员的生产力可能会显着下降。

这也会影响质量保证。通常，微服务有太多的依赖项，这使得测试更加困难。

对于需要赶上紧迫期限或可能缺乏快速采用该技术背景的团队来说，慢慢来并不总是可行的。“[微服务] 对于规模较小的工程师团队或不熟悉它的团队来说，可能是一项压倒性的技术。这是一种截然不同的运营方式，” 波士顿地区初创公司的软件工程师 John Obelenus 说。

误解：一种架构适用于所有事物

不要想象你可以采用一种架构并将其应用于你的整个环境。你也不应该假设你可以立即开始重构你的旧应用程序。 Rosenquist 说，你的旧应用程序可能不支持这些类型的模式。

区分单体应用、微服务和函数。函数只做一件事。 Rosenquist 说，它们实际上是用于特定架构的，因为它们更受事件驱动。企业流程尤其如此。如果你分解所有系统，最终会得到一千件事，并且你所有的优势都会丧失。

最好的方法实际上取决于具体的用例。 Rosenquist 说，例如，银行很可能有很多单体应用。 “但是如果你看看为你的移动银行应用程序提供支持的最普通的应用程序，那将是微服务——大约 50% 到 60%。函数占其余部分。因此，一个典型的企业最终会拥有架构方面多样化的环境，而不是单一的环境。”

归根结底，这实际上取决于构建你的软件的人。“无论你使用什么软件架构或模式，一个伟大的工程团队都会找到一种有效的方法，” Johnston 说，“而一个功能失调的团队会找到一种方法来搞砸一些事情，无论是微服务、单体应用还是其他任何东西。”

说到团队……

误解：微服务主要是一种技术

“关于微服务最常见的误解之一是，它们解决了技术问题，” Johnston 说。 “但实际上它们解决了业务或组织可扩展性问题。” 如果微服务没有实现该目标，那就是浪费时间——而不是技术的问题。

Johnston 指出：“我看到很多人正在启动一个新的应用程序，即使是作为大型企业的一部分，他们也认为他们需要从分离领域并从微服务开始。但是，如果你没有明确定义的业务领域，你就不想从微服务开始。”

再次引用康威定律，您的软件环境中的沟通模式反映了您整个组织的沟通模式。 Rosenquist 说：“假设您想从单体架构过渡到微服务架构，那么看看您的组织是如何组织的。例如，拆分团队以确保一个微服务属于一个团队。” 这与其说是技术挑战，不如说是管理问题。

确保每个人都了解什么是微服务，以及如何设想该技术来解决业务问题。不同的部门通常对微服务的性质有不同的看法。采用微服务架构的优势将取决于问题空间和采用该技术的组织。

误解：微服务允许团队使用他们喜欢的技术

根据 Johnston 和 Rosenquist 的说法，这并非完全是误解，因为这种看法有一定的道理。只是团队使用不同的平台并不总是一个好主意。

微服务的一个常见的认知优势是每个人都可以使用他们喜欢的语言、工具和平台。 Johnston 说，这在某些方面确实有道理。 “如果您有一个非常庞大的组织，其中有多个团队分布在世界各地，那么一些团队可能擅长 .NET，而另一些团队可能擅长 Java。然后，根据他们特定服务的业务领域，使用一种技术可能比另一种技术更有利。” 但是，他警告说，对其他开发环境的支持会增加系统的复杂性。 “这就是企业架构师存在的原因，” Johnston 说。 “他们需要了解系统的复杂性。”

Rosenquist 建议说：“是的，您可以为每个微服务选择不同的技术，但我真的建议您不要这样做。如果您有 500 个微服务，您不应该有 500 种不同的技术。大约五种左右会更好。” 当然，这些都是例子；没有一刀切的方法。运用常识，在可管理性和阻碍开发人员之间找到一个中间地带。

关于微服务的误解比比皆是

虽然我们在本文中分享的误解绝对是一些比较普遍的误解，但它们绝不是唯一的误解。我们的专家提出的其他一些微服务误区包括

微服务使事情变得更快：“由于网络跃点增加，微服务可能会导致速度减慢。您必须接受最终一致性，而在其他类型的应用程序中，您不一定需要这样做，” Johnston 解释说。

微服务实际上很小：技术咨询公司 Archium 的联合创始人 Graham Lea 说，不要迷失在微服务中的“微”字上。 “微服务应该比单体服务小，但理想情况下，一个服务应该封装一个中等大小的领域。” 小是一个相对术语；但努力使它们非常小不是重点，他补充说。

每个客户端类型都需要一个微服务：咨询公司 Blue Herring 的 DevOps 架构师 Mark W. Schumann 说：“没有人认为他们会这么想，但他们一直在这样做！” “相反，考虑每个资源一个微服务。”

如果您没有抱有任何这些误解，那么恭喜您，您自己就是专家。但如果你有，不要难过。你并不孤单。我们希望您现在能够以更高的信心前进，在您的公司中更有权威地谈论这个话题，并拥抱微服务可以提供的好处。