微服务架构的挑战

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

• 有界上下文
• 动态扩展和缩减
• 监控
• 容错性
• 循环依赖
• DevOps 文化

有界上下文：有界上下文的概念源于领域驱动设计 (DDD) 圈子。 它提倡面向对象模型优先的服务方法，定义了服务负责并受其约束的数据模型。 有界上下文澄清、封装和定义了模型的具体责任。 它确保领域不会受到外部干扰。 每个模型都必须在其子域内隐式定义一个上下文，并且每个上下文都定义了边界。

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

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

监控：传统的监控方式与微服务不匹配，因为我们有多个服务组成相同的功能，这些功能以前由单个应用程序支持。 当应用程序中出现错误时，找到根本原因可能具有挑战性。

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

循环依赖：跨不同服务的依赖管理及其功能非常重要。 如果未及时识别和解决，循环依赖可能会造成问题。

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

微服务的其他挑战

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