如今，微服务可谓是风靡一时。Forrester发布的一项研究发现，76%的企业正以微服务架构为指导进行应用程序重构。

但需要强调的是，微服务绝不是什么万灵丹药。在一项面向生产环境内微服务应用的研究中，我们看到59%的受访者表示每种微服务都会给数据管理等运营事务带来新的挑战。更令人担忧的是，这份报告还提到在对不同环境内的故障排查难度进行比较时，73%的受访者表示微服务环境难度更大，只有21%的受访者认为单体式架构难度较大。

但为什么会出现这样的状况？根据BCG Digital Ventures公司工程技术培训副总裁Matthew Sinclair的解释，这是因为技术专家们总是想用最现代的技术解决问题，即使他们对很多新兴技术还没有足够的经验。“但作为工程师，我很理解其中的选择思路。这么做不是因为更安全，而是因为能让从业者学到更多新东西。”他说。

客户们在听说微服务这项新技术的消息之后，总觉得应该用新方法解决自身的整体问题。于是，他们热衷于向软件工程师介绍微服务架构，调动起工程师们的积极性，之后就是在软件工程项目中迅速添加大量微服务元素。

但问题在于，整个开发流程不可能一夜之间完成由单体式架构到微服务架构的转换。换言之，企业在微服务迁移方面往往操之过急——一听说其中的优点、了解到部分收益，就想把它全面推向各个角落。正因为如此，一些企业开始不可避免地陷入微服务误区。

那么，我们该如何避免这种误区？

我们必须意识到，微服务架构代表的是一种分布式系统，因此不妨以部分员工已经具备经验的分布式思维进行设计。此外，千万别忘了这样一条黄金准则：如非必要，勿增实体。

换句话说，大家必须明确自己为什么要构建某种事物、想要借此达成怎样的目的。这是个最基本的问题，适用于任何规模的企业。打算解决什么问题、解决之后能够给用户带来怎样的收益，才是决定是否使用某种技术的根本前提。

用户们其实也并不关心底层技术究竟是什么——他们不关心如何实现，只关心能不能解决问题。

如果唯一的实现方法就是微服务，那我们毫无疑问应该着手使用。但如果还有其他替代方法，请优先考虑这些替代方法。千万不要陷入“为了微服务而微服务”的怪圈。

总而言之，微服务是一种旨在降低复杂性的架构模式。而一旦使用，它又会在其它层面增加复杂水平。如果孤立使用微服务，那么某一维度中得以解决的复杂性，必然会在某种形式扩散到其他领域。因此，最重要的是使用多种其他工具将组织的整体复杂性控制在最低程度。

这又回到了之前的拷问：我们要解决什么问题？如果大多数企业完全可以通过传统且常规的技术搞定当前需求，那么无需选择微服务。不要看到Amazon和谷歌等科技巨头全面推行微服务，就跃跃欲试。请先问问自己，微服务对我们来说是不是正确的选择。

也有不少企业掌握着重要的旧代码库，而且与业务体系严密集成。同样的，微服务也许并不适合这种状况。因此，尽量只在云原生项目中使用微服务，同时继续沿用旧有技术处理传统IT领域的挑战。

一次又一次，我们总会回到最基本的考量：我们要用产品或技术解决什么问题？注意，不是如何解决，是解决什么。如果用户与你的产品进行交互，可以获得哪些收益？只有为这个问题找到明确的答案，大家才能判断微服务架构是否适合自己。

不过在多数情况下，各位得到的答案或许会是“可以，但没必要。”