微服务架构的挑战

微服务架构比传统系统更复杂。微服务环境变得更加复杂，因为团队必须管理和支持许多活动部件。以下是组织在微服务旅程中面临的一些主要挑战：

• 有界上下文
• 动态放大和缩小
• 监控方式
• 容错能力
• 循环依赖
• DevOps文化

有界上下文：有界上下文概念起源于域驱动设计(DDD)圈子。它促进了对象模型优先用于服务的方法，定义了服务负责并绑定到的数据模型。有界上下文阐明，封装和定义了模型的特定责任。它确保了域不会被外界分散注意力。每个模型必须在子域中隐式定义一个上下文，并且每个上下文都定义边界。

换句话说，服务拥有其数据，并负责其完整性和可变性。它支持微服务的最重要功能，即独立性和去耦性。

动态扩展和缩小：不同的微服务上的负载可能处于该类型的不同实例上。除了自动扩展微服务外，还应自动缩减。它降低了微服务的成本。我们可以动态分配负载。

监视：传统的监视方式无法与微服务很好地配合，因为我们有多个服务组成了以前由单个应用程序支持的相同功能。当应用程序中出现错误时，寻找根本原因可能是具有挑战性的。

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

循环依赖性：跨不同服务的依赖性管理，其功能非常重要。如果没有及时发现并解决，周期性依赖关系就会产生问题。

DevOps文化：微服务非常适合DevOps。它提供了更快的交付服务，跨数据的可见性以及具有成本效益的数据。它可以将其容器化开关的使用范围从面向服务的架构(SOA)扩展到微服务架构(MSA)。

微服务的其他挑战

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