Microservices considered harmful

微服务引起了很多炒作，而在 HackerNews 和 Reddit 上，抨击单体应用似乎是普遍的潮流。很高兴看到 DHH 重新为这场讨论带回了一些理智。

大型公司通常有充分的理由将应用程序分解为 Centi、Milli 和 Micro 服务。对于只有十几名工程师的团队来说，这样做简直是疯狂的。

（微）服务解决什么问题

微服务本质上解决了大型工程师团队中的协调问题。

它们可以轻松地独立部署大型应用程序的不同部分。它们还将问题分解为小的复杂单元，可以理解、测试和修复，而无需理解整个系统。

一旦你拥有了一个庞大的单体应用，将其分解还可以极大地提高开发人员的生产力，因为如果你只在单个服务的范围内工作，编译、lint 和测试时间会大大减少。

它们还通过部署机制强制执行这种分离，而不是在单个代码库中使用库的约定。这使得人们更难破坏你的代码封装，迫使他们通过已发布的 API 来使用它。

虽然很讽刺，但它们也解决了公司政治中一个长期存在的问题，即必须与他人好好合作。现在你可以忽略集成问题，只需指向你的微服务并说“所有测试都通过了，它能用！”在下次绩效评估时看起来会很好。

解决你真正遇到的问题

所以，太棒了。听起来像是解决了大型复杂公司中，拥有大量政治因素的高效大型工程团队所面临的问题的绝佳解决方案。

你的当前问题是这样的吗？如果你是一个典型的早期创业公司，你的问题应该看起来像这样：

• 验证产品服务于目标用户
• 制定客户获取策略，并快速迭代促进这一点上的产品边缘
• 通过使部署更简单、更不易出错来获得更多睡眠
• 帮助公司中过劳的其他人做好他们的工作

那么……将应用程序分解成服务到底能给你带来什么呢？

单体应用是早期创业公司的理想选择

部署很简单。设置 CI，自动化部署并频繁部署。使用单体应用，你知道它是否部署成功。

系统范围的更改可以在一个地方完成，你不需要显式地对破坏性更改进行版本控制，因为所有代码都在一个地方。这使得迭代新功能的速度**快得多**。

一切都在一个地方。虽然这意味着需要理解的东西更多，但有一种奇怪的观点认为，将代码分散到 10 多个存储库中会更容易理解整个系统。当然，对于初级开发人员来说，查看单个服务并理解它会更容易。但是，认为创建数十个服务的思维模型比单个代码库中的等效模块更容易的想法是疯了。当然，当你的代码量达到 100 万行以上时，情况就会变得疯狂，但这并不是你现在面临的问题。

微服务的分析后果

那么，除了“互联网上有人错了”这个永恒的问题之外，为什么这会出现在 Metabase 的博客上呢？嗯，主要是因为使用微服务严重影响了你提供分析能力。

如果你有一个解耦的数据模型，总有一天你会想……把它重新耦合起来，以便分析你的业务情况。微服务的主要支持者往往是大型公司的工程师（他们有大量数据工程师来重新整合……你有吗？），顾问（任何能让单个顾问看起来不错并积累可计费小时数的事情都是好事），或者不想与公司其他人协调的工程师。

如果在此基础上再加上“为工作选择合适数据库”的额外疯狂操作，情况会更加糟糕。在这里，你将突然需要对所有这些闪闪发光的小型“雪花”有一个稳定的 ETL 方案。

为什么要在意？

嗯，大多数时候，当你是一家早期创业公司时，你并不确切地知道该构建什么。你可能会有一个想法，希望有一些早期用户和一个梦想。要改进你的产品，你需要同时理解正在发生什么，哪些产品功能有效，哪些无效，用户行为如何等等。

你也会因为定义原因而人手不足。所以，为了经营公司，你需要让非工程师（或者在这种情况下，任何除了编写微服务的人）更容易地提取数据。

总有一天，代码库的规模会促使你将其分解成服务，并承担所有相关的操作负担。在此之前，请尽可能长久地使用一个简单、乏味但稳定的单体应用。

TL;DR - 微服务解决了你作为早期创业公司没有遇到的问题，并使迭代更加困难。尽可能长时间地坚持使用单体应用。