基于微服务的解决方案有一些缺点：
分布式应用程序
分布式应用程序增加了开发者在设计和生成服务时的难度。 例如，开发者必须使用 HTTP 或 AMPQ 等协议实现服务间通信，这会增加测试和异常处理的复杂性。 还会增加系统延迟。
部署复杂性
如果应用程序具有许多微服务类型，且需要高可伸缩性（需要能为一个服务创建许多实例且在许多主机中实现服务均衡），这意味着 IT 运营和管理需要应对高度部署复杂性。 如果不使用面向微服务的基础结构（如业务流程协调程序和计划程序），为应对增加的复杂性所作的开发工作可能比业务应用程序本身多得多。
原子事务
多个微服务之间的原子事务通常不可能。业务要求必须接受多个微服务之间的最终一致性。
增加全局资源需求（所有服务器或主机的总内存、驱动器和网络资源）
在许多情况下，如果用微服务方法替代整体式应用程序，新的基于微服务的应用程序所需的初始全局资源数量超过原始整体式应用程序的基础结构需要。此方法是因为更高程度的粒度和分布式服务需要更多全局资源。 但是，由于与开发整体式应用程序所需的长期成本相比，资源成本通常较低，且具有能够横向扩展应用程序的某些区域的优点，因此增加资源使用量好过使用大型、长期应用程序。
客户端到微服务直接通信的问题
对于拥有许多微服务的大型应用程序，如果应用程序需要客户端到微服务直接通信，则存在难题和限制。 一个问题是客户端和每个微服务公开的 API 的需要之间可能存在不匹配。 在某些情况下，客户端应用程序可能需要进行许多单独的请求，以构成 UI，这在 Internet 中效率低下，且在移动网络中不切实际。 因此，仅尽量减少从客户端应用程序到后端系统的请求。
客户端到微服务直接通信的另一个问题是某些微服务可能使用不支持 Web 的协议。 一个服务可能使用二进制协议，而另一个服务可能使用 AMQP 消息。 这些协议不支持防火墙，最好在内部使用。 通常情况下，应用程序应针对防火墙外的通信使用 HTTP 和 WebSockets 等协议。
但是，客户端到服务直接方法的另一个缺点是难以重构这些微服务的协定。 一段时间后，开发者可能需要更改系统分区到服务的方式。 例如，它们可能会合并两个服务或将一个服务拆分为两个或多个服务。 但是，如果客户端直接与服务进行通信，执行这种重构可能会破坏与客户端应用的兼容性。
正如体系结构部分所述，如果基于微服务设计和生成复杂应用程序，需要考虑使用多个细化 API 网关，而不是使用较简单的客户端到微服务直接通信方法。
微服务分区
最后，无论针对微服务体系结构采用哪种方法，另一个难题是确定如何将端到端应用程序分区到多个微服务。
基本上，需要确定要从其他区域分离的应用程序区域，以及具有较少硬依赖项的区域。 在许多情况下，此方法与按用例划分的分区服务一致。 例如，在 e-shop 应用程序中，订购服务负责与订购流程相关的所有业务逻辑。 目录服务和购物篮服务则负责实现其他功能。 理想情况下，每个服务应仅具有一小部分职能。 此方法类似于应用于类的单一责任原则 (SRP)，该原则声明一个类应仅具有一个更改原因。 但我们现在探讨的是微服务，因此范围比单个类要大。 最重要的是，微服务必须是端到端且自治的，包括对其自己的数据源负责。
