微服务可能有害

关于微服务的炒作很多，在 HackerNews 和 Reddit 上对单体应用抨击似乎很流行。很高兴听到 DHH 将一些理性带回对话。

大型公司往往有很好的理由将应用程序积极拆分为Centi、Milli和Micro服务。对于只有个位数或两位数的工程师的团队来说，这几乎是不可能的。

(微)服务解决的问题

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

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

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

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

从悲观的角度来看，他们也解决了企业政治中常见的必须与他人良好合作的问题。现在你可以忽略集成问题，只需指向你的微服务并说“所有测试都通过并且它工作得很好！”在下次审查时看起来很好。

解决你真正存在的问题

所以，太棒了。听起来像是一个针对大型、复杂环境中功能强大的工程团队以及众多政治问题的绝佳解决方案。

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

• 验证产品服务其目标用户
• 制定客户获取策略，并在促进这一点的产品边缘快速迭代
• 通过简化部署并降低出错概率来睡得更香
• 帮助工作过劳的其余公司员工完成他们的工作

所以……将应用程序分解为服务到底给您带来了什么，再次问一遍？

单体适合早期初创公司

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

系统级更改可以在一个地方完成，你不需要显式地版本化破坏性更改，因为所有代码都在一个地方。这使得迭代新功能的速度大大加快。

所有内容都在一个地方。虽然这意味着需要理解的内容更多，但有人认为将代码分散在10+个仓库中可以更容易地理解整个系统。当然，对于初级开发人员来说，查看单个服务并理解它是很容易的。但是，将数十个服务的精神模型与单个代码库中的等效模块相比，这种想法是荒谬的。当然，当您达到100万+行代码时，事情会变得疯狂，但那不是你现在的问题。

微服务的分析后果

所以，除了“互联网上有人在犯错”这个永恒的问题之外，为什么这会在Metabase博客上？主要是因为使用微服务对您提供分析能力有非常严重的后果。

如果您有一个解耦的数据模型，您最终会想要将其重新耦合在一起，以便分析您的业务情况。微服务的主要支持者往往是大型公司的工程师（他们有小型数据工程师团队来将事物重新组合在一起……你有吗？），顾问（任何让个人顾问看起来好并增加可计费时间的任何事情都是好事），或者不想与他们公司中的其他人协调的工程师。

如果在微服务之上叠加“为任务选择合适的数据库”这种额外的疯狂，情况会进一步恶化。在这里，您将突然需要在所有这些闪亮的小雪花之间有一个稳定的ETL故事。

为什么要关心？

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

根据定义，您的人力资源也远远不足以完成这项工作。因此，为了运营业务，您需要让非工程师（或者在这种情况下，任何不是微服务编写者的人）能够轻松提取数据。

在某个时候，代码库的规模将促使您将其拆分为服务，并承担其中的所有运营烦恼。在此之前，尽可能地使用简单的单体架构。

TL;DR - 微服务解决的是早期初创公司所没有的问题，并使迭代变得更加困难。尽可能长时间地使用单体架构。