前不久，ThoughtWorks首席科学家Martin Fowler发表了一篇，探讨。他写道：

\

除非你的系统太复杂，作为单体应用会很难管理，否则不要考虑微服务。绝大多数软件系统都应该构建为单体应用。要注重在单体应用中实现良好的模块化，但不要试图将其拆分成单独的服务。

\

Tyler Treat是来自的一名软件开发人员，同时也是咨询公司的创建者。近日，他发表了一篇博文《》（DOA）。文中，他对Fowler的观点表示了赞同，同时他指出，团队迫不及待地采用微服务架构，一个原因是像Fowler所说的那样，他们不了解微服务的，另外一个原因是他们只看到了像Netflix公司这样的成功案例，却没有意识到那些公司并不是从微服务开始的，也就是说，是“”导致团队作出了那样的选择。

微服务确实有许多优点：“反脆弱性（anti-fragility）”、容错、独立部署与扩展、架构抽象、技术隔离。但并不是说采用了微服务就自然地具备了这些特性。比如，要具备反脆弱性，需要充分考虑分布式系统的不确定性，清楚异步、网络划分、节点故障、平衡可用性与数据一致性等问题。同样地，要具备可维护性和可扩展性，首先要有恰当的基础设施和组织结构。理论上讲，微服务可以提高开发速度，但在创建组织依赖时，“”可能会降低开发速度。所以，采用微服务架构需要具备一些先决条件，包括恰当的持续发布管道、能胜任的DevOps和Ops团队、审慎的服务边界等等。此外，周密的测试和集成模式也很重要。

而提到“单体（monolith）”，人们就会想到不可扩展、不可维护、缺乏弹性。但实际上，只要规模合理，单体系统也可以具有模块化、可维护、容错等特性。

因此，Treat认为，自下而上的方法是一种更好的微服务实施策略。像Fowler所说的那样，从单体或一个粗粒度服务的小集合开始，在有了足够的服务维护和部署经验后，再逐步分离出更细粒度的服务。

总之，微服务需要很高的组织和系统成熟度。否则，匆忙采用只能创建出一个“非面向服务的架构（disservice-oriented architecture）”。

感谢对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。