微服务弊大于利

微服务备受追捧，而在 HackerNews 和 Reddit 上，单体应用似乎成了众矢之的。很高兴听到 DHH 重新引入了一些理性的声音。

大型公司通常有充分的理由将应用程序积极地拆分成百厘、毫和微服务。对于只有个位数或两位数工程师的团队来说，这简直是疯了。

微服务解决什么问题

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

它们使得独立部署大型应用程序的不同部分变得容易。它们还将问题分解成小的复杂性单元，这些单元可以在不需要理解整个系统的情况下进行理解、测试和修复。

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

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

讽刺的是，它们还解决了公司政治中必须与他人良好合作这个长期存在的问题。现在你可以忽略集成问题，只指向你的微服务说“所有测试都通过了，它运行正常！”，然后在下次评估中表现良好。

解决你实际遇到的问题

那么，太棒了。听起来这是一个解决在一个有很多政治的大型复杂公司中，高效的大型工程团队所面临的问题的绝佳方案。

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

• 验证产品服务于其目标用户
• 找出客户获取策略，并快速迭代产品边缘以促进这一点
• 通过简化部署并减少错误来获得更多睡眠
• 帮助公司里那些工作过度的其他人完成他们的工作

那么……将应用程序拆分成服务究竟给你带来了什么呢？

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

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

系统范围的更改可以在一个地方完成，而且你不需要明确地版本化破坏性更改，因为所有代码都在一个地方。这使得迭代新功能的速度**快得多**。

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

微服务对分析的影响

除了互联网上总是有人错这个老问题之外，为什么这篇文章会出现在 Metabase 博客上呢？主要原因在于，使用微服务对你提供分析的能力会产生非常严重的后果。

如果你的数据模型是解耦的，在某个时候你会希望……将它们重新耦合起来，以便分析你的业务情况。微服务的主要支持者往往是大型公司的工程师（他们有小批数据工程师来重新整合数据……你也有吗？），顾问（任何能让个人顾问看起来很好并在之后赚取可计费时间的都是好事），或者是不想与公司其他人协调的工程师。

如果你在微服务之上再增加“为工作选择正确的数据库”这种额外的疯狂，情况会变得更糟。这样，你突然需要在所有这些闪亮的小雪花之间建立一个稳定的 ETL 故事。

为什么要关心？

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

此外，根据定义，你的人手不足。所以为了运营公司，你需要让非工程师（或者在这种情况下，除了编写微服务的人之外的任何人）能够轻松地提取数据。

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

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