微服务的双刃剑
支持者认为微服务能提高开发速度和可靠性，提供更全面的测试和灵活的扩展能力。确实，早期采用微服务架构可能会看到成本改善，但这并不意味着没有代价。微服务带来的灵活性往往伴随着额外的开销，而这些开销通常流向你的组织之外。
标准化的误区
微服务允许使用不同的技术栈，但现实是开发人员倾向于使用他们熟悉且高效的环境，导致技术栈扩散。为了应对这种模式，平台工程学科应运而生，通过“黄金路径”来规范内部开发实践。这实际上增加了对云服务提供商的依赖。
自动化的挑战
每个团队依赖微服务的灵活性构建各自的服务，导致生产基础设施变得复杂。这种复杂性难以维护，增加了对CI/CD提供商的依赖。自动化成为部署这些分散技术栈的唯一可靠方式，同时也增加了运营成本。
网络调用的代价
网络调用和服务分区替换了方法调用和模块分离，这在大多数情况下是一种低效的做法。这些调用昂贵且容易出错，需要开发新的防御机制和可观测性工具来捕捉问题，从而增加了对第三方提供商的依赖。
运维和可观测性的负担
在微服务架构中，你可以选择让每个团队负责监控其服务的健康和性能，或者创建一个“单一视图”的可观测性仪表板。这两种路径都增加了对昂贵的可观测性平台的依赖。
扩展的幻觉
微服务提供了多种扩展选项，但这种简单性掩盖了底层的低效性。即使是大型企业也会遇到硬性的扩展限制，唯一的解决方案可能是放弃微服务架构，回到单体结构。
单体结构的优势
虽然单体结构不是完美的，但它为每个缺陷提供了一个可理解的解决方案。与微服务不同，解决单体结构的每个问题都会创造一个改进的内部反馈循环。
结论
亚马逊 Prime Video 的经验表明，转移到单体结构后，基础设施成本减少了超过 90%，并且提高了扩展能力。这表明，微服务的好处并非无限，复杂性仍然存在于系统中。单体结构至少让你承担成本并享受胜利。
