微服务的阴暗面，解释

无休止的博客文章，白皮书和幻灯片组，宣扬了微服务的优点。 他们谈论微服务如何“提高敏捷性”，“更具可扩展性”，并承诺当您进行切换时，工程师会在办公室门外寻找工作。

让我们清楚一点，尽管有时会夸大其词，但在某些情况下微服务的好处可能是真实的。 对于具有许多团队的大型组织而言，微服务尤其有意义。 但是，微服务并不是万能的-尽管它们具有所有优点，但它们也具有明显的缺点。 在本文中，我将描述微服务的分布式本质如何使它们本质上更加复杂。

分布式系统很难

分布式系统是可以协同工作以执行任务的任何计算机集合。 微服务只是设计用于交付Web服务后端的一种分布式系统。

分布式系统研究的早期可以追溯到70年代。 我们知道分布式系统很难。 从理论上讲，困难主要来自两个关键领域：共识和部分失败。

共识

从理论上讲，构建可行的分布式系统的根本问题归结为共识问题-关于分布式状态的共识。 几乎所有的分布式系统研究都试图以某种方式解决这个问题。 Paxos，Raft，Vector Clocks，ACID，最终一致性，Map Reduce，Spark，Spanner以及该领域中的其他大多数重要进展都在某种程度上摆在强共识和性能之间的取舍。

为了更好地理解分布式共识的问题，我们举一个例子进行说明。 假设Bob要求Server_1写x = 5，而同时Jill要求Server_2写x = 6，x等于5还是6？ 天真的，可以看看x = 5发生的时间和x = 6发生的时间，然后选择最后发生的那个。

但是如何确定写入发生的时间 。

看时钟吗 谁的时钟？ 您怎么知道时钟是准确的？ 您怎么知道Bob，Jill，Server_1和Server_2同意那个时钟？

众所周知，时钟是不同步的，而且（正如阿尔伯特·爱因斯坦所教我们的那样），这是不可修复的[1]。 因此，每个人真的需要就x的值达成一致吗？ 如果是这样，需要多少协议？ 该协议需要多长时间？ 如果Bob试图达成协议而去世怎么办？

它变得复杂。

那么，鉴于很难达成分布式共识，在微服务环境中该问题如何体现？ 好的微服务实现往往会通过简单地禁止共享状态来完全避开该问题。 在我们上面的示例中，不存在x，因此两个微服务需要在任何特定时间点就x的值达成一致。 而是将系统中的所有共享状态发送到外部数据库或容器协调器。

这种方法可以解决也不能解决共识问题。 从理论的角度来看，它并不能解决问题，因为仍然存在共享状态仍然需要管理。 您刚刚移动了它。 顺便说一下，这就是为什么Kubernetes和数据库是如此复杂的原因。

从实际的角度来看，该方法确实解决了这个问题，与大多数微服务相比，Kubernetes和数据库在管理共享状态方面更好。 这些系统是由工程师设计的，他们每天花费一整天思考这些问题。 结果，他们更有可能达成正确的共识。

部分失败

考虑由整体服务的HTTP请求。 收到请求后，一台服务器从头到尾处理事务。 如果存在问题，无论是软件错误还是硬件故障，整个组件都会崩溃–每个故障都是完全故障。

现在考虑进入微服务的相同HTTP请求。 该微服务可能会向其他微服务发送新请求，而其他微服务反过来可能会生成更多请求并发送给更多微服务。 现在假设这些微服务之一失败了。 现在怎么办？ 一个或多个微服务都依赖于数据微服务准备。

他们该怎么办？ 稍等片刻？ 多久？ 再试一次？ 试试别人吗？ 还有谁？ 放弃并尽力利用他们拥有的数据吗？ 必须设计微服务来处理这些问题，这又使它们的开发更具挑战性。

部分失败被描述为不合格的好东西。 想法是，通过支持部分故障，应用程序将变得更有弹性-可以轻松解决小问题。 在我看来，好处很小，在实践中很少获得，并且以大大增加实现复杂性为代价。

更多动人的作品

除了微服务的理论挑战之外，还有很多挑战。 如此多的移动部件使堆栈的几乎每个部分以及软件开发生命周期的每个部分都变得复杂。

发展历程

通常，您可以直接在笔记本电脑上运行整体。 使微服务在本地计算机上运行需要更专业的工具，例如docker-compose和minikube。 此外，它们占用大量CPU和内存，从而使它们在笔记本电脑上的运行速度非常缓慢。

请注意，请查看 Kelda ，尤其是我们的 白皮书 ，以详细了解此问题。

调试

整体中发生的所有事情都在单个过程中发生。 您可以连接所选的调试器，然后开始比赛。 使用微服务，单个请求可能会分布在数十个不同的流程中。 像Jaeger这样的分布式跟踪工具可能会有所帮助，但这仍然是一个挑战。

记录中

使用整体，您可以将日志存储在文件中，并在需要时获取它们。 对于微服务，您需要Splunk或ELK堆栈之类的工具来为您处理。

监控方式

当您拥有数百个微服务时，像Nagios这样的简单的服务器上监视工具就无法扩展。 同样，更好的工具（Prometheus / Datadog / Sysdig等）使问题更容易解决，但是仍然很难。

部署方式

诸如Chef和Puppet之类的工具足以部署整体，但对于微服务而言，您需要诸如Kubernetes之类的更为复杂的工具。

联网

整料可以使用简单的负载平衡器处理。 微服务有更多的端点，所有这些端点都需要负载平衡，服务发现，一致的安全策略等。我想服务网格可以帮助实现这一点（我不相信，但这是以后的主题）。

微服务有时有意义

从技术的角度来看，微服务比单例要严格得多。 但是，从人类的角度来看，微服务可能会对大型组织的效率产生影响。 它们使大型公司中的不同团队可以独立部署软件。 这意味着团队可以快速行动，而不必等待最慢的公分母对他们的代码进行质量检查并准备发布。

这也意味着大型软件工程组织中的工程师/团队/部门之间的协调开销较小。

尽管微服务可以说得通，但关键是它们不是魔术。 就像计算机科学中的几乎所有事物一样，在技术复杂性与组织效率之间也存在权衡取舍。 一个合理的选择，但是您最好确保需要组织效率，以便使技术挑战值得。

[1]：是的，当然，地球上的大多数时钟都不会以接近光速的速度移动。 此外，一些现代分布式系统（特别是Spanner）依靠这一事实，即使用极其精确的原子钟来绕开共识问题。 尽管如此，这些系统本身还是极其复杂的，这证明了我的观点：分布式共识很难。

Kelda 使 Kubernetes上 的开发人员可以更轻松地使用微服务。

加入我们的Slack社区！

先前发布在 https://kelda.io/blog/the-dark-side-of-microservices/

From: https://hackernoon.com/the-dark-side-of-microservices-explained-s6z3679