个特别阴险的方面是共享数据库。当一个服务访问另一个服务数据库时，人们常说“这只是暂时的”。但临时的解决方案很快就会变成永久的依赖。就好像不同的家庭共用一个电网——任何短路都会影响所有家庭。
技术债务的积累速度比传统的整体式架构更快。由于没有人能够全面了解服务是如何连接的，因此变化变得越来越危险。一位开发人员恰当地描述了这一点：“这就像在玩 Mikado 游戏——任何举动都可能导致整个系统崩溃。”
好消息是：分布式整体不一定是最终状态。回归真正的微服务之路是可能的，但需要诚实的分析和一致的行动。与我合作的团队开始将所有服务依赖关系可视化。最终的图表非常复杂——但这是改进的第一步。
微服务的 10 个关键陷阱
1. “微服务总是更好”的谬论
这是一个诱人的想法：微服务作为现代软件架构的通用解决方案。特别是在鼓舞人心的会议演讲或阅读了大型科技公司的成功案例研究之后，道路似乎变得清晰起来。但这正是第一个或许是最严重的陷阱所在。
事实却更加复杂。微服务不是灵丹妙药，而是一种具有特定优点和缺点的工具。它们就像一辆高性能跑车：在合适的环境中令人印象深刻，但可能完全不适合日常通勤。
当这种谬论导致草率的架构决策时，它会变得特别危险。团队急于实施微服务，却没有解决根本问题：我们领域的复杂性是否证明这种架构是合理的？我们的团队是否已经为这一转变做好准备？我们能够保持可能的一致性吗？
更好的方法是冷静的分析。也许结构良好的整体式架构对于您的项目来说是更好的选择。或者您可以从模块化整体式架构开始，之后可以根据需要将其拆分为微服务。架构决策应该由您的特定需求而不是一般趋势驱动。
2. 共享数据库的诱惑
“一个数据库适用于所有服务 - 节省时间并简化数据一致性。”这个想法乍一看很合理，但往往会变成一场噩梦。这就像使用一个电表来管理一栋公寓楼里的所有公寓一样：几乎不可能确定谁使用了多少电，而且停电会立即影响所有居民。
共享数据库很快成为服务之间的秘密通信渠道。一项服务改变了数据库模式，突然间其他默默依赖于同一张表的服务就中断了。原本打算作为实用解决方案的东西却破坏了微服务本来应该提供的功能：独立性和隔离性。
解决方案在于一致的数据分离。每个服务都应该管理和控制自己的数据。是的，这有时意味着数据重复。是的，这需要深思熟虑的同步机制。但这些所谓的缺点是真正的服务自主的代价。
相反，服务应该通过明确定义的接口进行通信。如果服务 A 需要来自服务 B 的数据，它应该通过 API 请求数据或对相关事件做出反应。这乍一看可能比较麻烦，但它明确了责任，实现了真正的解耦。
数据同步最好基于事件进行。当服务中的重要数 乌干达 WhatsApp 数据 据发生变化时，它会发布相应的事件。需要此信息的其他服务可以响应并更新其本地数据。这会产生一个与分布式系统的现实相一致的强健系统：最终一致性而不是即时一致性。
微服务中的“微”并不是指代码行数，而是指职责范围。然而，许多团队陷入了试图将太多功能打包到单个服务中的陷阱。这就像试图将整个百货商店塞进一个小商店——理论上是可行的，但在实践中却非常困难。
过大的服务就像一座发展过快的城市：基础设施跟不上，沟通渠道变得越来越长，管理变得越来越繁琐。最初旨在作为可管理单元的东西发展成为微服务架构内的微型整体。
警告信号往往很微妙。构建时间越来越长，部署也变得越来越危险。团队失去了对服务内依赖关系的追踪。新功能的开发速度变慢，因为每个更改都必须根据越来越多的用例进行仔细测试。
解决之道不是盲目的拆分服务，而是认真分析业务领域。这就是领域驱动设计投资获得回报的地方。确定您所在领域的自然边界。哪里有独立的业务流程？哪些数据真正属于一起？这些技术界限往往是服务削减的最佳参考点。