微服务的黑暗面

博客文章、白皮书和幻灯片层出不穷，宣扬微型服务的优点。他们谈论微服务如何“提高敏捷性”，“更易于扩展”，并承诺当你进行转换时，工程师会在你的办公室门口敲击，寻找一份工作。

让我们弄清楚，虽然偶尔有些夸大，但在某些情况下，微服务的好处是真实的。特别是对于大型组织，有许多团队，微服务可以有很多意义。然而，微型服务并不神奇--尽管它们有很多好处，但它们都有明显的缺点。在本文中，我将描述微服务的分布式特性如何使它们本质上更加复杂。

分布式系统是很难的

分布式系统是为执行任务而共同工作的计算机的任何集合。微服务是一种简单的分布式系统。提供Web服务的后端.

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

共识

从理论上看，构建可行的分布式系统的根本问题归结为对分布式状态的协商一致问题。几乎所有的分布式系统研究都试图以某种方式解决这个问题。帕克斯，筏子，矢量时钟，酸液，最终一致性，地图减少，火花，扳手，和大多数其他重大进展，在这一领域都是摆弄权衡之间的强大共识和性能在某种程度上。

为了更好地理解分布式协商一致的问题，让我们以一个例子来说明。假设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和数据库比大多数微服务更善于管理共享状态。这些系统是由工程师们设计的，他们每天都在思考这些问题。因此，他们更有可能获得正确的共识。

部分失效

考虑由Monolith服务的HTTP请求。当收到请求时，一个服务器从头到尾处理事务。如果有问题，无论是软件错误还是硬件故障，整个一体机就会崩溃--每一个故障都是完全失败的。

现在，考虑进入微服务的相同HTTP请求。该微型服务可能会向其他微型服务发送新的请求，而其他微服务则可能产生更多的微服务请求。现在假设其中一个微服务失败了。现在怎么办？一个或多个微服务取决于数据。那微型服务正在准备。

他们应该怎么做？等一会儿？多长？再试试?试试别人？还有谁？放弃并尽最大努力处理他们所掌握的数据？必须设计微型服务来处理这些问题，再次使它们的发展更具挑战性。

部分失败被描述为一件无条件的好事。我们的想法是，通过支持部分故障，应用程序变得更有弹性--小问题可以优雅地被掩盖起来。在我看来，好处很小，在实践中很少得到，而且代价是大大增加了实现的复杂性。

更多的移动碎片

除了微观服务的理论挑战外，还有很多。拥有如此多的移动部件几乎会使堆栈的每个部分和软件开发生命周期的每个部分复杂化。

发展您通常可以直接在笔记本上运行Monolith。要想让微型服务在本地机器上工作，需要更多的专用工具，如坞式组合和迷你库。此外，它们需要大量的CPU和内存，使得它们在笔记本电脑上速度慢得令人痛苦。注意，退房凯尔达，特别是我们的白纸有关此问题的详细描述。

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

测井使用Monolith，您可以将日志存储在文件中，并在需要时获取它们。对于微服务，您需要一个像Splunk或elk堆栈这样的工具来为您处理这个问题。

监测像Nagios这样简单的服务器上监视工具在您拥有数百个微服务时是不会扩展的。同样，更好的工具(Prometheus/Datadog/Sysdigg等)使问题容易处理，但仍然很难。

部署像Chef和PupPET这样的工具对于部署Monolith来说已经足够好了，但是对于微服务来说，您需要一些更复杂的东西，比如Kubernetes。

联网单石可以通过简单的负载均衡器来处理。MicroServices还有更多的端点，所有这些都需要负载平衡、服务发现、一致的安全策略等等。我认为服务网格可以帮助解决这个问题(我不相信，但这是未来文章的主题)。

有时候，微型服务是有意义的。

从技术角度看，微观服务比单一服务更加困难。然而，从人的角度来看，微型服务可能对大型组织的效率产生影响。他们允许大公司内的不同团队独立部署软件。这意味着团队可以快速行动，而无需等待最低的公分母来获得他们的代码QA并为发布做好准备。这也意味着大型软件工程组织中工程师/团队/部门之间的协调开销更小。

虽然微服务是有意义的，但关键是它们并不神奇。就像计算机科学中的几乎所有东西一样，在这种情况下，组织效率的技术复杂性之间也存在着权衡。一个合理的选择，但你最好确保你需要的组织效率，技术挑战是值得的。

[1]：是的，当然，地球上的大多数时钟都没有移动到接近光速的任何地方。此外，一些现代分布式系统(尤其是扳手)依靠这一事实，使用极为精确的原子钟来回避共识问题。然而，这些系统本身是极其复杂的，这证明了我的观点：分布式共识是困难的。