微服务架构风格一直是去年的热门话题。在最近的 o'reilly 软件架构会议 上，似乎每个会议都在谈论微服务。足以让每个人的过度炒作废话探测器启动并闪烁。这样做的后果之一是，我们已经看到团队过于急于接受微服务，却没有意识到微服务会为他们自己带来复杂性。这增加了项目的成本和风险——通常会使项目陷入严重的麻烦。
虽然这种围绕微服务的炒作很烦人，但我确实认为它是一种架构风格的有用术语，这种架构风格已经存在了一段时间，但需要一个名称以便于讨论。这里重要的不是你对炒作有多恼火，而是它提出的架构问题： 微服务架构是你正在使用的系统的好选择吗？
对一个有趣问题的任何体面的回答都是从“这取决于……” ——肯特·贝克
“这取决于”必须开始我的回答，但随后我必须将重点转移到它 取决于 什么因素。是否使用微服务的支点是您正在考虑的系统的复杂性。微服务方法是关于处理一个复杂的系统，但为了做到这一点，该方法引入了它自己的一组复杂性。当你使用微服务时，你必须处理自动化部署、监控、故障处理、最终一致性以及分布式系统引入的其他因素。有很多众所周知的方法可以解决所有这些问题，但这是额外的努力，而且我认识的软件开发人员中似乎没有人有大量的空闲时间。
所以我的主要指导方针是 甚至不要考虑微服务，除非你的系统太复杂而无法作为一个单体来管理 。大多数软件系统应该构建为一个单一的整体应用程序。请注意单体应用中良好的模块化，但不要尝试将其分离为单独的服务。
驱使我们采用微服务的复杂性可能来自许多来源，包括处理大型团队、 多租户 、支持多种用户交互模型、允许不同的业务功能独立发展以及扩展。但最大的因素是庞大的规模——人们发现他们拥有一个太大而无法修改和部署的整体。
在这一点上，我感到有些沮丧。归因于单体的许多问题对于这种风格来说并不是必不可少的。我听说有人说你需要使用微服务，因为用整体式应用不可能进行持续交付——但是有很多组织通过 千篇一律的部署 方法取得了成功：facebook 和 etsy 是两个众所周知的例子。
我也听说过这样的论点，即随着系统规模的增加，您必须使用微服务才能拥有易于修改和替换的部件。然而，您没有理由不能制作具有明确定义的模块边界的单一单体。至少 在理论上 没有理由，在实践中，模块边界似乎很容易被破坏，整体也很容易变得混乱和庞大。
我们还应该记住，不同微服务系统之间的服务规模存在很大差异。我见过微服务系统从 60 人团队和 20 项服务到 4 人团队和 200 项服务不等。目前尚不清楚服务规模对保费的影响程度。
随着规模和其他复杂性助推器进入项目，我看到许多团队发现微服务是一个更好的地方。但除非您面临这种复杂性，否则请记住，微服务方法会带来高额费用，这会大大减慢您的开发速度。所以如果你能让你的系统足够简单以避免对微服务的需要：那就去做吧。
笔记
1：这是一个非常普遍的问题，我们最近的雷达将其称为 微服务嫉妒 。
2： 康威定律 说系统的结构遵循构建它的人的组织。一些微服务使用的例子让组织故意将自己分成小的、松散耦合的组，以便将软件推入类似的模块化结构——这个概念被称为 逆康威策略 。
致谢
我从我的同事那里窃取了很多这种想法：james lewis、sam newman、thiyagu palanisamy 和 evan bottcher。 stefan tilkov 对早期草稿的评论有助于完善这篇文章。 rob miles、david nelson、brian mason 和 scott robinson 在我们的内部邮件列表上讨论了本文的草稿。
