微服务似乎是完美的解决方案。从理论上讲，它们可以提高开发速度，同时允许您独立扩展应用程序的不同部分。
但实际上，微服务带有隐藏的成本。也就是说，我认为如果不亲自构建它们，您就无法真正理解它们的复杂性。
这是我使用微服务构建（有时失败）的经验。
管理数据是一场噩梦
跨微服务保持数据同步可能具有挑战性。
每个微服务一个数据库是推荐的模式。它允许松散耦合并允许特定于服务的团队独立运作，而不会减慢在共享代码上的协作速度。
但是，当应该同步启动的两个微服务之一出现故障时会发生什么？例如，其中一个微服务更新其数据库，而另一个不更新。
此类情况会导致数据不一致。
根据个人经验，调查跨服务的数据不一致可能会很痛苦。错误的跨服务性质需要一个人跨多个服务工作以纠正错误。不幸的是，这会使微服务的优势之一——特定于团队的服务无效。
通过将两个数据库调用包装在单个原子事务中，可以轻松防止单体应用程序中的相同情况，因此所有插入都成功或都不成功。十分简单。
但是对于微服务，松散耦合使这变得更加困难。
花费更多时间在设置上
构建微服务架构比将相同的功能整合到单体中需要更长的时间。
虽然单个服务很简单，但交互的服务集合比类似的单体要复杂得多。
单体中的函数可以调用任何其他公共函数。但是一个微服务中的函数仅限于调用同一个微服务中的函数。
这需要服务之间的通信。构建 API 或消息传递系统来促进这一点并非易事。
此外，无法避免跨微服务的代码重复。单体应用可以定义一个模块并多次导入，而微服务就是它自己的应用程序——需要在每个应用程序中定义模块和库。
微服务最适合大型团队
将微服务分配给单个团队的奢侈是针对大型工程部门的。
尽管这是微服务体系结构的一大吹捧优势，但只有当您拥有足够多工程人员数，并将多名工程师专用于每项服务时才可行。减少开发人员的代码范围，可为他们提供了更好地理解他们的代码并提高开发速度的带宽。
但大多数初创公司没有这种奢侈。
在资源不足的早期公司中，一些工程师需要跨所有服务工作。
不幸的是，这会降低工作效率，因为跨应用程序可能会导致严重的上下文切换。
我发现在我有一段时间没有研究过的微服务中的寻找错误令人筋疲力尽。
DevOps 更加复杂
选择微服务的最令人信服的原因之一是能够在不同类型的服务器上运行不同的服务。
为什么？与训练机器学习模型的服务相比，React 前端可能具有非常不同的内存、CPU 和正常运行时间要求。为每项服务选择正确类型的基础设施可以大大降低成本。
但它也带来了自己的挑战。
举个例子：在我职业生涯的早期，我曾经因为忘记重新启动代码已经更新了的服务而丢失了大量的生产数据。过时的代码通过 API 请求接收数据，但随后以静默方式失败，而不是将其记录在其数据库中。这样这些默默被处理的数据永远丢失了。
我提出这一点是为了说明与单个单体应用程序相比，配置、维护和监控多个微服务需要更多的工作。拥有多个应用程序也会增加黑客的攻击向量。
理论上，“松散耦合”服务允许每个服务在其他服务失败时继续运行。但这是一厢情愿的想法——真正的松耦合对于与客户的复杂业务来说几乎是不可能的。
最后，您的应用程序架构仅取决于最薄弱的部分的可靠性。可移动的部件越多，出错的机会就越大。
总结
许多公司在并不真正需要它们的情况下使用微服务。尽管它们目前很受欢迎，但微服务并不适合初学者。
大多数公司最好构建一个单体应用，然后在绝对必要时将单体应用的各个部分拆分为微服务。
让资金雄厚的大型科技公司从头开始构建微服务架构。