文章速览：

• 误解一：微服务可以解决你的所有问题
• 误解二：微服务降低了复杂性
• 误解三：一种架构适用一切
• 误解四：微服务主要是一种技术
• 误解五：微服务允许团队使用他们喜欢的技术
• 对微服务的误解不止于此

一、误解一：微服务可以解决你的所有问题

很多公司认为：“我们拥有这样的应用程序架构，而微服务就是答案，”Redis的合作伙伴解决方案架构师Lars Rosenquist说道：“但首先，你需要了解什么是微服务；接下来，你需要了解你自己应用程序架构的问题；然后两者之间需要有一个匹配，而这种匹配并不常见。”

许多技术解决的是特定规模的特定问题。“如果你像Netflix这样的公司，你的应用程序消耗了互联网流量的三分之一，你必须对你的架构进行一些调整才能使其正常运行，”Rosenquist解释说：“但如果你是一个规模较小的公司，比如一家地方银行，你的运营规模并不大，所以你不需要解决那个问题。人们经常会对他们期望解决的问题进行优化，而不一定是针对他们真正面临的问题。”

人们经常针对他们想象的问题进行优化，而不一定针对他们遇到的问题。

——拉尔斯·罗森奎斯特

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

大多数情况下不需要使用微服务。几位编程专家建议，应避免“单体应用是过时的做法”的观念。

二、误解二：微服务降低了复杂性

事实上，微服务架构几乎总是会增加复杂性。更糟糕得是，如果不加以控制，它就会变成一个分布式的独立结构——甚至混乱不堪。

1.微服务不能解决系统设计问题。

“如果您无法创建具有高内聚和低耦合的整体设计，那么您在微服务方面的表现可能会更差，”iDIA 计算公司的软件开发顾问George Dinwiddie 说道。

从一个单体应用开始，然后随着团队的增加，应逐渐将服务从中分离出来，这是一些建议的做法。康威法则适用于这种情况。

“通过单一应用程序，您可以将所有逻辑、通信和复杂性集中在一个应用中”Rosenquist 表示，“通过微服务，你可以彻底改变这一点。” 结果就是：所有这些通信模式现在都成为您的基础设施的一部分。

罗森奎斯特认为，许多公司并没有真正理解这个问题。他们认为可以通过微服务消除复杂性。但实际上你并没有消除复杂性，您只需将它移到了不同的抽象层。

“比如说，你有两个应用组件相互通信。它们存在于同一个应用程序、同一个进程、同一个CPU中。这个应用程序相当快，而且不太容易出现故障,” 罗森奎斯特表示。但是，使用微服务后，你将这些应用组件放在不同的机器上，它们之间有网络，一整套基础架构，甚至可能位于不同的云上。”这将成为一个完全不同的挑战，不仅涉及通信和故障模式，还涉及性能方面的问题。”

2.复杂性使应用程序的调试变得更加困难。

虽然微服务方法确实使你的代码更简单，但罗森奎斯特指出，当涉及部署或管理时，它并不总是更容易。”现在你不仅需要调试一个应用程序，还需要调试六个或十个应用程序。这些应用程序还在多个实例上运行，它们也在整个架构上进行负载均衡。” 为了整合所有这些，要注意诸如日志聚合和可观察性之类的事项，所有这些通常比拥有单个应用程序更复杂。

3.代码更简单并不一定意味着系统更简单。

“从代码的角度来看，在孤岛中更容易理解单独的服务，” Redis 开发人员增长负责人William Johnston指出。“但是使用微服务创建的系统的复杂性比独立系统要复杂得多。”

这也意味着需要更多的开发时间，尤其是对于已经超负荷的小团队。但这并不总是坏事，因为它迫使开发人员了解应用程序领域和整个系统。从长远来看，这可以使重构变得更加容易，因为它使整个系统的耦合度降低。不过，这会带来高昂的成本，并且开发人员的生产力可能会大幅下降。

3.影响质量保障。

通常，一个微服务牵连着很多的依赖关系，以至于更难测试。对于需要在紧迫的期限内完成任务或不能快速采用该技术的团队来说，很难总是慢慢来。“对于一小部分工程师或不熟悉它的团队来说，这是一种完全不同的运营方式，令人无从下手”波士顿地区初创公司的软件工程师 John Obelenus 表示。

三、误解三：一种架构适用于一切

不要误以为你可以采用一种架构并将其应用到整个应用程序中。也不要认为你可以立即开始重构旧应用程序。正如罗森奎斯特说，您的旧应用程序可能不支持这些模式。 

要区分单体应用、微服务和函数。一个函数只做一件事。Rosenquist 表示，它们确实适用于特定架构，因为它们受事件驱动。情况就是如此，尤其是企业流程。如果你分解你所有的系统，最终将产生大量组件，这样您将失去所有的优势。

最佳方法实际上取决于特定的用例。例如，银行很可能会有相当多的单体应用，Rosenquist说。“但是，如果您查看为移动银行应用程序提供支持的最普通的应用程序，您会发现这是微服务——大约 50% 到 60%。其余部分由函数组成。因此，一个典型的企业最终会在架构方面出现多样化的情况，而不是单一的。”

归根结底，这实际上取决于构建软件的人。约翰斯顿说：“无论您使用什么软件架构或模式，优秀的工程团队都会找到一种有效的方法，而不称职的团队会找到一种方法把事情搞砸，无论是微服务、单体应用还是其他任何东西”。

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

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

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

再次引用康威定律，软件架构中的通信模式模仿整个组织的通信模式。Rosenquist 说：“假设您想从单体架构转向微服务架构，看看你的组织架构是怎样的。例如，拆分团队以确保一个微服务属于一个团队。” 这是一个管理问题，而不是技术挑战。

确保每个人都了解微服务是什么，以及如何使用这项技术来解决业务问题。不同部门通常对微服务的性质有不同的观点。采用微服务架构的优势将取决于问题领域和采用该技术的团队。

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

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

“是的，你可以为每个微服务选择不同的技术，但我真的建议你不要这么做，”Rosenquist 建议。“如果你有 500 个微服务，那么你不应该有 500 种不同的技术。大约5个会是更好的数字。” 当然，这些只是例子；没有一种通用的方法。要理性思考，找到可管理和不会阻碍开发人员的平衡点。

六、对微服务的误解不止于此

以上是一些较为普遍的对微服务的误解，但不止于此，我们的专家还提出了其他一些关于微服务的误解：

• 微服务可以加快速度： “由于网络跳数的增加，微服务可能会导致速度变慢。您必须接受最终一致性，而在其他类型的应用程序中则不一定需要这样做，”Johnston 解释道。
• 微服务实际上很小：技术咨询公司 Archium 的联合创始人 Graham Lea 表示，不要迷失于微服务中的“微”。“微服务应该比整体更小，但理想情况下，服务封装了一个中等规模的领域。” 小是一个相对术语，但努力让它们变得很小并不是重点。
• 每种客户端类型都需要一个微服务： “没有人自觉如此，但他们一直这样做！” Blue Herring 咨询公司的 DevOps 架构师 Mark W. Schumann 说道。“相反，考虑根据不同的业务资源类型创建微服务。。”

你是否有这样的误解呢，如果没有，那么恭喜您，你自己也是一位专家。但如果你有，也不要感到难过，你并不孤独。我们希望您现在能够更加自信地前进，在公司中以更权威的方式谈论这个话题，并享受微服务可以提供的好处。