微服务不能“包治百病”。
时下微服务是一个不错的架构，它具备模块化、可伸缩和高容错这些优点。许多公司都采用微服务架构并取得了巨大的成功，自然而然地，如果你正开始一个新项目，微服务似乎是最佳选择。
然而，大多数采用微服务取得成功的公司并不是一开始就选择了这种架构。以Airbnb和Twitter为例，他们在单体应用过于庞大之后才选择了微服务路线，现在也仍在解决由此带来的复杂性。即使是大公司也仍在寻找使用微服务的最佳方法。所以说，微服务是一把双刃剑，需要权衡利弊。
从单体应用迁移到微服务也绝不是一项简单任务，未经过测验，便采用微服务构建一个新产品则更加复杂。只有在充分评估了替代方案之后，才应该认真考虑是否使用微服务架构。
PART 01
微服务仅适用于成熟产品
关于从头开始使用微服务，马丁·福勒（Martin Fowler）总结道：
1.几乎所有成功的微服务都是从一个过于庞大而不得不拆分的单体应用开始的。
2.几乎所有从头开始以微服务构建的系统，最后都会因严重的问题而失败。这种情况导致许多人认为，就算你确信你的应用将快速发展壮大，也不应该一开始便采用微服务。
初版设计很难优化得很好，新产品的前几次迭代重点在于寻找用户的真正痛点。因此，成功取决于保持敏捷并能快速优化和重构。在这方面，微服务就比单体应用差得多。如果你没有把握设计好最初的方案，就采用了微服务，那么你的启程之路将更加困难，因为重构微服务比重构单体应用要困难得多。
PART 02
你是否在初创公司或者开发全新项目？
作为一家初创公司，你已经在争分夺秒，在未知的噩耗来临之前努力寻找突破口。此时你不太需要关注扩展性（可能几年之内都不需要），那么为什么要使用复杂的架构而忽视客户的需求呢？
在开发全新项目时也有类似的情况，这些项目不受前期工作的限制，更没有任何决策包袱。《构建微服务：设计细粒度的系统》一书的作者山姆·纽曼（Sam Newman）表示，用微服务构建一个全新的项目非常困难：
我仍然坚信，对现有的旧系统进行划分要比在全新的系统容易得多。你有更多可供帮助的资源，比如你有可供查阅的代码，你可以与使用和维护系统的人员交流讨论