微服务那么火，我也该用微服务吗？

前言

近来，几乎人人都在谈论微服务。开发人员都在研究Eric Evan的著作《领域驱动设计》。团队正在重构一体化应用，寻找限界上下文，并定义通用语言。虽然有不计其数的文章、视频和座谈可以帮助您转换到微服务，但很少有人愿意多花些时间来探讨一下某个具体的应用是否应该采用微服务。

使用微服务架构有很多充分的理由，但天下没有免费的午餐。微服务虽有诸多优势，但也增加了复杂性。团队应该积极应对这种复杂性，但前提是应用能够受益于微服务。

切忌盲目跟风，请负责任地考虑是否采用微服务架构

Matt Stine和我在最近与一家客户一起研究了他们的一些应用。我们的讨论以“一切都应该是微服务”为出发点，因为这在如今已经“司空见惯”。结果谈话陷入了僵局，大家就各种实施细节争论不休。

Matt在白板上写下了一组原则。这些简单的句子在这一天剩下的时间里指导着我们，我们审视应用架构的每个部分，寻找微服务可以交付价值的地方。这个列表彻底改变了对话的氛围，帮助团队制定了明智的架构决策。

为了不滥用微服务，我们列出了这组原则，帮助您集中精力开展工作。通过阅读下面的这些原则，看看特定的应用能否因某一个原则而受益。如果对于以下一个或多个原则，您的回答是“是”，那么这个功能就适合采用微服务。如果对于每个原则，您的回答都是“否”，那么您可能会给系统引入偶发复杂性。

01

多个变更速度

系统的各个部分是不是需要以不同的速度或向不同的方向发展？如果是，就分别采用微服务吧。这让每个组件都有了独立的生命周期。

在任何系统中都是一些模块很少受影响，而另一些模块似乎每次迭代都会发生变化。我们来举例说明，假设有一款用于在线零售的一体化电子商务应用。