如今微服务风靡一时。Forrester发布的一项研究发现，76%的企业正在使用微服务架构作为应用程序重构的指南。但需要强调的是，微服务绝不是万能的。在对生产中微服务应用的研究中，我们看到59%的受访者表示每个微服务都会给数据管理等运营事务带来新的挑战。更令人担忧的是，报告中还提到，在比较不同环境的排错难度时，73%的受访者表示微服务环境更难，只有21%的受访者认为单体架构更难难的。但是为什么会出现这样的情况呢？BCGDigitalVentures工程技术培训副总裁MatthewSinclair表示，这是因为技术人员总是希望使用最现代的技术来解决问题，即使他们对许多新兴技术的了解还不够。经验。“但作为一名工程师，我理解思路的选择，这并不是因为它更安全，而是因为它可以让从业者学到更多新东西。”他说。客户在听说微服务新技术后，总觉得应该用新的方法来解决他们的整体问题。因此，他们热衷于将微服务架构介绍给软件工程师，调动工程师的积极性，进而迅速在软件工程项目中加入大量的微服务元素。但问题是，整个开发流程不可能一夜之间从单体架构转变为微服务架构。换句话说，企业在迁移到微服务方面往往过于仓促——他们一听说好处并了解其中的一些好处，就想到处推。正因为如此，一些企业难免陷入微服务的误区。那么，我们该如何避免这种误解呢？我们必须意识到微服务架构代表了一个分布式系统，所以我们不妨用一些员工已经有经验的分布式思想来设计它。另外，不要忘记黄金法则：除非必要，否则不要增加实体。也就是说，每个人都必须清楚自己为什么要建一个东西，想要达到什么目的。这是一个适用于任何规模企业的基本问题。计划解决什么问题，解决后能给用户带来什么好处，是决定是否使用某项技术的根本前提。用户实际上并不关心底层技术是什么——他们不关心如何实现它，他们只关心它是否能解决问题。如果唯一的方法是微服务，那么我们绝对应该开始使用它们。但如果有其他选择，请优先考虑这些选择。不要陷入“为了微服务而微服务”的恶性循环。总而言之，微服务是一种旨在降低复杂性的架构模式。一旦使用，它会增加其他级别的复杂性。如果孤立地使用微服务，那么在一个维度上解决的复杂性必然会以某种形式扩散到其他领域。因此，使用多种附加工具将组织的整体复杂性保持在最低水平至关重要。这就又回到了之前的拷问：我们要解决什么问题？如果大多数企业都可以通过传统常规技术完全解决当前的需求，那么就没有选择微服务的必要了。不要试图看到亚马逊和谷歌等科技巨头全面实施微服务。请先问问自己微服务是否是我们的正确选择。还有许多公司持有重要的旧代码库，并与业务系统紧密集成。同样，微服务可能不适合这种情况。因此，尽量在云原生项目中只使用微服务，同时继续使用旧技术来应对传统IT领域的挑战。一次又一次，我们总是回到最基本的考虑：我们要用一个产品或技术解决什么问题？注意，不是怎么解决，而是解决什么。如果用户与您的产品互动，他们可以获得什么好处？只有找到这个问题的明确答案，大家才能判断微服务架构是否适合自己。但在大多数情况下，你得到的答案可能是“是的，但不一定是”。
