微服务系统相对于以往的单体系统更为复杂。在构建的时候，研发团队必须要管理和支持很多组件，环境会变得更加复杂。下面是我以往构建微服务系统时整理的一些主要挑战。

一、限界上下文

限界上下文概念起源于领域驱动设计 (DDD) 圈子。它的出现促进了优先对象模型的服务方法，定义了服务责任和绑定的数据模型。有边界的上下文澄清、封装并定义了模型的特定责任。每个模型都必须在子域内隐式定义一个上下文，并且每个上下文都定义了边界。换句话说，服务拥有其数据并对其完整性和可变性负责。它支持微服务最重要的特性：独立性和解耦。

二、动态扩展和缩减

不同微服务上的负载可能在不同类型的实例上。除了自动扩展你的微服务应该自动缩减。降低了微服务的成本，可以动态分配负载。

三、监控

传统的监控方式与微服务差异性很大，微服务有多个服务组成了单个应用程序支持的相同功能。当应用程序中出现错误时，找到根本原因具有很大的挑战性。

四、容错

容错是不会降低整个系统的单个服务。当故障发生时，应用程序可以在一定的满意度下运行。如果没有容错能力，系统中的单个故障可能会导致完全崩溃。断路器可以实现容错，它是一种将请求包装到外部服务，并检测它们何时出现故障的模式。微服务需要一定程度上容忍内部和外部故障。

五、循环依赖

跨不同服务的依赖管理，这个功能非常重要。如果不及时识别和解决，循环依赖可能会产生问题，当依赖关系形成了环，最终导致：在安装 A 软件包之前，必须要安装 A、B、C、D 软件包

六、DevOps 文化

微服务非常适合 DevOps。它提供更快的交付服务、跨数据的可见性和具有成本效益的数据。它可以将他们对容器化转换的使用从面向服务的架构 (SOA) 扩展到微服务架构 (MSA)。

微服务的其他挑战

• 随着我们添加更多微服务，我们必须确保它们可以一起扩展。更多的粒度意味着更多的组件，增加了系统的复杂性。
• 传统的日志记录是无效的，因为微服务是无状态的、分布式的、独立的。日志记录必须能够跨多个平台关联事件。
• 当更多的服务相互交互时，失败的可能性也会增加。