微服务的额外代价

过去一年里，我们已经听到很多关于微服务的讨论。无论你觉得它们是一种新的架构方式，还是认为它们仅仅是对SOA 理念进行了重新包装，毋庸置疑的是微服务的理念正在席卷整个程序员社区。 Martin Fowler 的一篇文章经常被作为微服务的原始素材所引用，文章详细阐述了像 Netflix 这样的组织使用微服务的经验和成果。最近，Martin 在这个话题上又有新的言论，特别谈到了开发人员什么时候应当考虑使用微服务。

微服务 [噱头化] 带来的的后果之一是，我们看到开发团队太渴望拥抱微服务，却没有意识到他们要为此付出的代价。这增加了一个项目的成本和风险——经常会使项目陷入到严重的麻烦当中。

Martin 承认，微服务的术语最近可能有炒作之势，但它作为一种有用的架构风格已经存在很长时间了。有趣的是，Martin 并没有将这种风格视作 SOA 的一个变种，尽管他作为先驱见证了微服务最早的一些发展。不管微服务的名字叫什么， Martin 还是对程序员想要知道的答案做出了解释：究竟微服务架构对你的系统来讲是不是一个好的选择?

系统自身的复杂性是你决定是否使用微服务的一个决策点。微服务的方法适用于处理复杂系统，但微服务自身也会引入一组新的复杂性问题。当你使用微服务时，你必须有自动部署、监控、异常处理、最终一致性保证，以及其它分布式系统引入的各种复杂因素。

Martin 在他的文章中包含了一个图表，试图展示微服务应用与典型单体应用相比，它是如何改变系统复杂性的。他的建议是：

除非你面对的是一个过于复杂以至于难于管理的单体应用，否则绝对不要考虑使用微服务。大多数的软件系统应该构建为独立的单块程序。确保注重单体应用自身的模块化，而不要试图把它们分离成单独的服务。

有多种驱动程序员使用微服务的复杂难题，包括多应用并存、支持多个业务功能独立发展和扩展。然而，在 Martin 的观点中，采用微服务的决定性因素应当是单块应用已经过于庞杂以至于难以修改和部署。然而，正如我们去年的报道，Simon Brown 做了一个有趣的观察。

如果您正在构建一个单体系统，而它正在变成了一个大杂烩，也许你应该考虑是否足够对软件架构足够关注。你真的理解了软件中核心的结构性抽象吗？它们的接口和责任明确吗？如果不是，你为什么认为迁移到微服务架构可以有所帮助？当然，微服务将迫使你的系统物理分离从而无法走捷径，但是通过单块应用组件之间的分离也能达成同样的效果。

Martin 对于微服务和单体应用的看法更加客观。

很多归结于单体应用的问题其实并不是那种架构风格所自有的。我听说过人们说，你之所以需要使用微服务，是因为在单块应用中无法做到持续交付 - 然而已经有很多公司成功的完成了曲奇分割式部署（ cookie-cutter deployment ) 的方式：Facebook 和 Etsy 是两个很著名的例子。

他还认为，将系统规模的增长视作你被迫使用微服务，从而使部件（组件）更容易替换的理由并不成立。认为单体应用不会有定义良好的模块边界的理由也并不充分。然而，Martin 通过实践认为，由于这些边界通常太容易被逾越，所以单体应用很容易被冠以大杂烩（ Big Ball of Mud ）的称号。总之，Martin 还是希望人们在决定向微服务架构跨越之前，深思熟虑一番，认真考虑架构和系统实现中的所有因素:

当代码规模等复杂性问题不断涌入项目时，我看到很多团队会发现微服务是个不错的选择。你要始终牢记微服务会带来了高昂的额外开销，显著减缓你的开发效率，除非你面对的复杂性难题确实需要微服务来解决。所以如果你能够保证系统足够简单，从而避免使用微服务：那怎么简单就怎么做吧。

查看英文原文： Microservices Premium

感谢张龙对本文的审校。

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