视频
使用实时数据库在金融服务中创建即时客户体验
了解更多
快速的未来正在您的城市举行活动。
加入我们在 Redis 发布会
分享
关于微服务有很多误解，这些误解经常会损害那些希望将其作为解决所有问题的灵丹妙药的公司。
想要被认为很酷和时髦的冲动并不仅仅局限于笨拙的青少年。这种动机也会导致成年企业高管追逐最新的闪亮的新技术，仅仅因为那些很酷（也很成功）的公司正在使用它。
这并不是说任何给定的技术都没有价值。然而，有时新事物——比如微服务、Kubernetes、Lambda 函数，或者[插入你自己的很酷的新技术]——会被接受或拒绝，都是因为错误的原因。太多时候，采用这种技术的原因是来自那些只知道这些术语是流行语的人，而不是作为一种真正有用的解决方案的技术优势，这种解决方案适用于一个真正令人讨厌的问题。而这可能不是他们自己的问题。这会导致夸大其词，这对当前的技术来说是不公平的。
微服务是当今企业神话的牺牲品，软件假设阻碍了明智的采用和使用。现在是时候在有实践经验的技术人员的帮助下澄清事实了。这些是他们最常遇到的微服务误解。
微服务很棒——只要它们能解决你公司真正存在的问题。老话在这里很有用：“当你的工具只有锤子时，所有东西看起来都像钉子。”
“许多公司认为，‘我们有这个应用程序景观，微服务是答案，’”Redis 的合作伙伴解决方案架构师 Lars Rosenquist 说。“但首先你需要了解微服务是什么；接下来你需要了解你自己的应用程序架构的问题；然后两者之间需要匹配。而这种情况很少发生。”
许多技术在特定规模上解决特定问题。“如果你是一家像 Netflix 这样的公司，而且你的应用程序消耗了互联网流量的三分之一，那么你必须对你的架构做一些事情才能让它工作，”Rosenquist 解释说。“但如果你是一家规模较小的公司，比如一家地方银行，你没有在那个规模上运营——所以你不需要解决那个问题。人们经常为了他们想要解决的问题而优化，而不一定是他们已经遇到的问题。”
大多数用例不需要微服务。避免“单体不好，单体是老旧的方式”的心态，建议一些编程专家。相反，在采用微服务方法之前，尝试证明自己对该前提的错误。
事实上，微服务架构几乎总是会增加复杂性。更糟糕的是：如果放任不管，它会变成分布式单体——而这会变得很乱。
微服务不能解决系统设计问题。“如果你不能创建具有高凝聚力和低耦合的单体设计，那么你使用微服务的可能性会更低，”软件开发顾问兼 iDIA Computing 的教练 George Dinwiddie 说。
从单体开始，然后在添加团队时从中提取服务，建议几个开发人员。 康威定律适用。
“对于单体应用程序，你所有的逻辑、通信和复杂性都在同一个应用程序中，”Rosenquist 说。“使用微服务，你将此反转。”结果是：所有这些通信模式等现在都成为你基础架构的一部分。
Rosenquist 认为，许多公司并没有真正理解这个问题。他们认为他们可以用微服务来消除复杂性。但你并没有真正消除它；你只是将其转移到一个不同的抽象层。
“假设你有两个相互通信的应用程序组件。它们存在于同一个应用程序中，同一个进程中，同一个 CPU 中。该应用程序速度很快，不太可能出现故障，”Rosenquist 说。但使用微服务，你将这些应用程序组件放在不同的机器上，并在它们之间使用网络、一系列基础设施，甚至可能使用不同的云。“这将成为一个完全不同的挑战——不仅仅是在通信和故障模式方面，而且是在性能方面。”
现在可用的工具使管理复杂性变得更容易，但不要低估复杂性仍然存在。一方面，复杂性使得调试应用程序变得更加困难。为了使管理复杂性变得稍微容易一些，请确保你的监控和可观察性工作已经到位。
虽然微服务方法肯定会使你的代码变得不那么复杂，但 Rosenquist 指出，在部署或管理方面，它并不总是更容易。“你不再只有一个应用程序需要调试，而是有六个或十个。这些应用程序还在多个实例上运行，这些实例也在整个架构中进行负载均衡。”为了组装所有这些，请注意日志聚合和可观察性等方面。所有这些通常比拥有一个单体应用程序更复杂。
代码不那么复杂并不一定意味着系统不那么复杂。“从代码的角度来看，单个服务可能在一个孤岛中更容易理解，”Redis 的开发人员增长主管William Johnston指出。“但使用微服务创建的系统的复杂性比单体系统要复杂得多。”
这也意味着更多的开发时间，特别是在已经超负荷的较小团队中。这并不总是坏事，因为它迫使开发人员学习应用程序领域和整个系统。从长远来看，这可以使重构变得更容易，因为它使整个系统耦合度更低。但是，这需要付出高昂的代价，开发人员的生产力可能会大幅下降。
这也影响了质量保证。通常，一个微服务有如此多的依赖关系，以至于它很难测试。
对于需要满足严格期限或可能缺乏快速采用该技术的背景的团队来说，放慢速度并不总是可能的。“[微服务]对于规模较小的工程师团队或不熟悉它的团队来说，可能是一种令人生畏的技术。这是一种非常不同的运营方式，”波士顿地区初创公司的软件工程师 John Obelenus 说。
不要以为你可以采用一种架构并将它应用于你的整个环境。也不要假设你可以立即开始重构你的旧应用程序。Rosenquist 说，你的旧应用程序可能不支持这些模式。
区分单体、微服务和函数。函数只做一件事。Rosenquist 说，它们实际上是针对特定架构的，因为它们更侧重于事件驱动。情况尤其如此，特别是对于企业流程而言。如果你分解所有系统，最终会得到一千件事，而所有优势都会消失。
最佳方法实际上取决于具体的用例。例如，银行可能拥有相当多的单体，Rosenquist 说。“但如果你看看为你的移动银行应用程序提供支持的最常见应用程序，那将是微服务——大约 50% 到 60%。函数占剩余部分。因此，一个典型的企业最终会拥有一个关于架构的多样化景观，而不是一个单一的景观。”
归根结底，这实际上取决于为你的软件构建的人。“优秀的工程团队无论使用哪种软件架构或模式，都能找到有效的方法，”Johnston 说，“而一个功能失调的团队会找到一种方法来搞砸一些事情，无论它是微服务、单体还是其他任何东西。”
说到团队……
“关于微服务最常见的误解之一是，它们解决了技术问题，”Johnston 说。“但实际上，它们解决的是业务或组织的可扩展性问题。”如果微服务没有实现这个目标，那将是浪费时间——而且不是技术的错。
“我看到很多人正在开始一个新的应用程序，即使是作为大型企业的一部分，他们也认为他们需要从分离域开始，并从微服务开始，”Johnston 指出。“但如果你没有明确定义的业务域，你就不想从微服务开始。”
再次引用 Conway 定律，您的软件架构中的通信模式会模仿整个组织的通信模式。Rosenquist 说：“假设您想从单体架构迁移到微服务架构。看看您的组织是如何组织的。将团队拆分，确保一个微服务属于一个团队。”这更多是一个管理问题，而不是技术挑战。
确保每个人都理解什么是微服务以及该技术如何被设想用来解决业务问题。不同的部门对微服务的本质往往有不同的看法。采用微服务架构的优势将取决于问题空间和采用该技术的组织。
根据 Johnston 和 Rosenquist 的说法，这不是完全的误解，因为这种看法有一定的道理。只是团队并不总是应该使用不同的平台。
微服务的一个普遍感知的优势是，每个人都可以使用他们喜欢的语言、工具和平台。Johnston 说，从某种程度上说，这确实有道理。“如果你有一个非常庞大的组织，有几个团队分布在世界各地，一些团队可能精通 .NET，例如，而另一些团队精通 Java。那么，根据他们特定服务的业务领域，他们可能更倾向于使用其中一种技术。”但是，他提醒说，对额外开发环境的支持是以系统复杂性增加为代价的。“这就是企业架构师存在的意义，”Johnston 说。“他们需要理解系统的复杂性。”
“是的，你可以为每个微服务选择不同的技术，但我真的建议你不要这样做，”Rosenquist 建议道。“如果你有 500 个微服务，你不应该有 500 种不同的技术。大约 5 种会是一个更好的数字。”当然，这些只是例子；没有一种万能的方法。使用常识，在可管理性和阻碍开发人员之间找到一个平衡点。
虽然我们在本文中分享的误解无疑是流传最广的一些，但它们绝不是唯一的误解。我们的专家还提出了一些其他的微服务神话，包括
如果您没有抱有任何这些误解，恭喜您——您本身就是专家。但是，如果您确实有，也不要难过。你不是一个人。我们希望您现在能够更加自信地向前迈进，在公司中更权威地谈论这个话题，并拥抱微服务可以带来的好处。
准备在您的店铺中采用微服务了吗？了解 Redis 如何提供帮助。
