微服务溢价

在过去的一年里，微服务架构风格一直是热门话题。在最近的O'Reilly 软件架构大会上，似乎每个环节都在谈论微服务。这足以让每个人的过度炒作-胡说八道检测器启动并闪烁。其后果之一是，我们看到团队过于急于拥抱微服务，[1]没有意识到微服务本身也会带来复杂性。这会给项目的成本和风险增加溢价 - 一种经常会让项目陷入严重困境的溢价。

虽然围绕微服务的这种炒作令人讨厌，但我确实认为它是一个有用的术语，用于描述一种已经存在了一段时间的架构风格，但它需要一个名称来方便讨论。这里重要的是，不要关注你对炒作的厌烦程度，而是它引发的架构问题：微服务架构是否适合你正在开发的系统？

任何对有趣问题的合理答案都从“这取决于……”开始。

-- 肯特·贝克

我的答案必须从“这取决于”开始，但我必须将重点转移到它取决于什么因素。是否使用微服务的关键在于你正在考虑的系统的复杂性。微服务方法完全是关于处理复杂系统，但为了做到这一点，这种方法引入了自己的复杂性。当你使用微服务时，你必须处理自动化部署、监控、处理故障、最终一致性以及分布式系统引入的其他因素。有一些众所周知的应对所有这些问题的方法，但这需要额外的努力，而且我认识的软件开发人员中似乎没有人有充足的空闲时间。

因此，我的主要指导原则是，除非你的系统过于复杂，无法作为单体进行管理，否则不要考虑微服务。大多数软件系统应该构建为单个单体应用程序。请注意该单体内部的良好模块化，但不要试图将其分离成单独的服务。

促使我们使用微服务的复杂性可能来自许多来源，包括处理大型团队[2]、多租户、支持多种用户交互模型、允许不同的业务功能独立发展以及扩展。但最大的因素是规模本身 - 人们发现他们拥有一个过于庞大而无法修改和部署的单体。

在这一点上，我感到有些沮丧。许多归因于单体的問題并非该风格的本质。我听说过有人说你需要使用微服务，因为用单体进行持续交付是不可能的 - 但实际上，有很多组织成功地采用了标准化部署方法：Facebook 和 Etsy 就是两个众所周知的例子。

我还听到过一些论点，说随着系统规模的扩大，你必须使用微服务才能拥有易于修改和替换的部件。然而，没有理由说明你不能创建一个具有明确定义的模块边界的单体。至少在理论上没有理由，在实践中，模块边界似乎很容易被打破，单体也会变得像大型系统一样混乱。

我们还应该记住，不同微服务系统之间的服务规模存在很大差异。我见过微服务系统从 60 人的团队和 20 个服务到 4 人的团队和 200 个服务不等。目前尚不清楚服务规模在多大程度上影响溢价。

随着规模和其他复杂性增强因素对项目的影响，我看到许多团队发现微服务是一个更好的选择。但除非你面临这种复杂性，请记住，微服务方法会带来很高的溢价，这可能会大大减缓你的开发速度。因此，如果你能够保持系统的简单性，以避免使用微服务的必要性：那就这样做吧。