微服务有害论

微服务有很多炒作，而抨击单体应用似乎在 HackerNews 和 Reddit 上很流行。很高兴听到 DHH 为对话带来一些理智。

大型公司通常有充分的理由积极地将应用程序分解为 Centi、Milli 和 Micro 服务。对于工程师团队人数为个位数或两位数的公司来说，这简直是胡闹。

(微)服务解决什么问题

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

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

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

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

愤世嫉俗地说，它们还解决了公司政治中长期存在的不得不与他人良好合作的问题。现在你可以忽略集成问题，只需指向你的微服务，说“所有测试都通过了，它可以工作！”并在下次评估中看起来不错。

解决你实际存在的问题

太棒了。听起来像是解决一个高效运转的大型工程团队在一个庞大而复杂的、充满政治的地方所面临问题的绝佳方案。

这描述了你当前的问题吗？如果你是一家典型的早期创业公司，你的问题应该是这样的

• 验证产品是否服务于其目标用户
• 制定客户获取策略，并在产品边缘快速迭代以促进这一点
• 通过使部署更容易且不易出错来睡得更多
• 帮助过度劳累的公司其他员工完成工作

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

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

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

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

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

微服务的分析后果

因此，除了“有人在互联网上犯错”这个长期存在的问题之外，为什么这篇文章会出现在 Metabase 博客上？嗯，主要是因为在提供分析能力方面，使用微服务会产生非常严重的后果。

如果你的数据模型是解耦的，那么在某个时候你将希望将其重新耦合在一起，以便你可以分析你的业务正在发生的事情。微服务的主要支持者往往是大型公司的工程师（他们有少量数据工程师来将事物缝合在一起……你有吗？）、顾问（任何使个人顾问看起来不错并在以后累积计费小时数的事情都是好事），或者是不想与公司其他人协调的工程师。

如果你在微服务之上堆叠“为工作选择正确的数据库”的额外疯狂，情况会更糟。在这里，你突然需要为所有这些闪亮的小雪花制定一个稳定的 ETL 故事。

为什么要关心？

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

按照定义，你的人手也会太少而无法完成工作。因此，为了运营业务，你需要让非工程师（或者在这种情况下，除了编写微服务的人以外的任何人）能够轻松地提取数据。

在某个时候，代码库的大小将促使你将其分解为服务，并承担其中所有的运营麻烦。在此之前，尽可能长时间地使用一个简单的、枯燥的单体应用。

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