就像 Fred Brooks 近 30 年前写的《人月神话》说的，没有银弹。像其他技术一样，微服务架构模式也是如此，存在着缺点。其中一个缺点就是名称本身。微服务这个术语的重点过多偏向于服务的规模。事实上，有些开发者主张构建极细粒度的 10-100 LOC（代码行） 服务虽然小型服务可能比较好，但重要的是要记住，小型服务只是一种手段，而不是主要目标。微服务的目标在于充分分解应用程序以方便应用敏捷开发和部署。

微服务另一个主要的缺点是由于微服务是一个分布式系统而变得复杂。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。此外，由于目标请求可能很慢或者不可用，他们还必须编写代码来处理局部故障。虽然这些都不是很复杂高深的事，但模块间通过语言级方法/过程调用相互调用，这比单体应用要复杂得多。

微服务的另一个挑战是分区数据库架构。更多多个业务实体的业务事务是相当普遍的。这些事务在单体应用中的实现显得微不足道，因为只有一个单独的数据库。在基于微服务的应用程序中，您需要更新不同服务所有用的数据库。通常不会选择分布式事务，不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理。您最后不得不使用最终基于一致性的方法，这对于开发人员来说更具挑战性。

测试微服务应用程序也很复杂。例如，使用现代的框架如 Sprig Boot，只需要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下，一个类似的测试类对于微服务来说需要启动该服务及其所依赖的任何服务，或者至少为这些服务配置存根。再次声明，虽然这不是一件高深的事情，但不要低估了这样做的复杂性。

微服务架构模式的另一个主要的挑战是实现了跨越多服务变更。例如，我们假设您正在实现一个变更服务 A、B 和 C 的需求，其中 A 依赖于 B，并且 B 依赖于 C。在单体应用程序中，您可以简单地修改相应的模块、整合变更并一次性部署他们。相反，在微服务中您需要仔细规划和协调出现的变更到每一个服务。例如，您需要更新服务 C，然后更新服务 B，最后更新服务 A。幸运的是，大多数变更只会影响一个服务；需要协调的多服务变更相对较少。

部署基于微服务的应用程序也是非常地复杂。一个单体应用可以很容易地部署到基于传统负载均衡器的一组相同的服务器上。每个应用程序实例都配置有基础设施服务的位置（主机和端口），比如数据库和消息代理。相比之下，微服务应用程序通常由大量的服务组成。例如，据 Adrian Cockcroft，Hailo 拥有 160 个不同的服务，Netflix 拥有超过 600 个服务。

每个服务都有多个运行时实例。还有更多的移动部件需要配置、部署、扩展和监控。此外，您还需要实现服务发现机制，使得服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统比较麻烦的基于票据（ticket-based）和手动操作方式无法扩展到如此复杂程度。因此，成功部署微服务应用程序要求开发人员能高度控制部署方式和高度自动化。

一种自动化的方式是使用现成的平台即服务（PaaS），如 Cloud Foundry。PaaS 为开发人员提供了一种简单的方式来部署和管理他们的微服务。它让开发人员避开了诸如采购和配置 IT 资源等烦恼。同时，配置 PaaS 的系统与网络专业人员可以确保最佳实践和落实公司策略。

自动化微服务部署的另一个方式是开发自己的 PaaS。一个普遍的起点是使用集群方案，如 Kubernetes，与 Docker 等容器技术相结合。最后我们将看到基于软件的应用交付方式如 NGINX 是如何在微服务级别处理缓存、访问控制、API 计量和监控，可以帮助解决这个问题。