用于云应用程序开发的微服务架构是一种将软件应用程序构建为小型（"微型"）、松散耦合服务集合的架构方法。架构中的每个服务都代表一种特定的业务能力或功能，例如向数据库添加库存项目或检查新客户的信用。它们通常作为独立的流程运行，通过应用程序接口或轻量级协议与其他服务通信。

微服务源于面向服务的架构和构建更好应用程序的需求。它成为构建全新应用程序最受欢迎的方法也是情有可原。我喜欢使用微服务架构，因为它提供了松散的耦合和隔离。

服务的设计是松散耦合的。它们可以独立运行，无需直接依赖其他服务中的内部实施细节。服务允许团队单独开发、部署和扩展服务，从而提高敏捷性。由于服务可以独立运行，因此还能带来更多的好处，如提高复原能力。

这就说明了独立性和隔离性的好处，它们与松散耦合直接相关。每个服务都可以独立开发、测试、部署和扩展。

老实说，这在出现时并不具有革命性。它更像是架构最佳实践的演进，始于 20 世纪 70 年代的结构化开发，然后是面向对象的开发、基于组件的开发、服务的使用和微服务。每种方法都会对以下方法产生影响；希望我们能一路改进。

当然，开发过程中没有免费的午餐。每一种方法、工具、语言和架构都有其利弊，在进行应用时，开发人员也必须考虑到微服务的缺点对项目的影响。这些缺点有时会因为对微服务的大肆炒作而被忽视。让我们来探讨一下微服务架构的缺点。

最大的问题是复杂性。与单体架构相比，微服务更加复杂。系统被分解成无数个服务；架构变得更加错综复杂，理解不同服务之间的交互可能具有挑战性。

如果考虑到我们还要处理复杂的分布式系统作为部署微服务的平台，这就变得更加困难。这几乎是所有企业构建和部署多云的副产品。

分布是另一个应该考虑的不利因素。使用微服务时，服务之间的通信通常通过网络进行，这会导致延迟、网络故障和设备压力增加。正是因为这个原因，我不得不在部署基于微服务的应用程序后升级网络，但又进一步增加了应用成本。

数据管理也更加复杂。微服务可能拥有自己的数据库或数据存储，从而使各种服务之间的数据一致性变得更加复杂。维护数据完整性通常需要付出额外的努力，而企业往往在遭受损失时才明白这一点。这当然是可以解决的，但需要的资源比大多数人理解的要多得多。

服务依赖性可能会为企业带来麻烦。由于微服务通过应用程序接口（API）进行交互，一个服务的变化可能会对其他服务产生影响。结果是什么？版本挑战和潜在的兼容性问题，尤其是在升级或服务变更期间。

最后是资源开销。对于大多数已部署的应用来说，运行多个微服务实例所消耗的资源要多于单个单体应用。这会增加基础设施成本，尤其是在管理效率不高的情况下。

现在应该怎么办？

我发现，云计算开发人员和架构师对微服务架构的态度近乎狂热。当然，微服务架构并不适合所有应用，在许多情况下，微服务架构会成为一种勉为其难的选择。在对已经迁移到云或正在迁移到云的应用程序进行现代化改造时，它们需要的资源远远超出了应有的水平。这就是由微服务的许多缺点造成的。

尽管如此，它们往往是使用的典范架构。但是，在使用之前，您必须充分地权衡利弊，而且必须专注于核心应用需求。遗憾的是，我们并没有关注很多应该关注的事情，最终导致核心应用需求的不匹配而导致效率低下。

微服务与其他任何方法一样，只能根据具体情况来考虑，同时还要牢记应用这种架构的目的，什么时候该用，什么时候不该用。

原文标题：The downsides of microservices architecture

原文作者： David Linthicum