微服务架构(MSA)面临的挑战有哪些?
微服务系统相对于以往的单体系统更为复杂。在构建的时候,研发团队必须要管理和支持很多组件,环境会变得更加复杂。下面是我以往构建微服务系统时整理的一些主要挑战。
一、限界上下文
限界上下文概念起源于领域驱动设计 (DDD) 圈子。它的出现促进了优先对象模型的服务方法,定义了服务责任和绑定的数据模型。有边界的上下文澄清、封装并定义了模型的特定责任。每个模型都必须在子域内隐式定义一个上下文,并且每个上下文都定义了边界。换句话说,服务拥有其数据并对其完整性和可变性负责。它支持微服务最重要的特性:独立性和解耦。
二、动态扩展和缩减
不同微服务上的负载可能在不同类型的实例上。除了自动扩展你的微服务应该自动缩减。降低了微服务的成本,可以动态分配负载。
三、监控
传统的监控方式与微服务差异性很大,微服务有多个服务组成了单个应用程序支持的相同功能。当应用程序中出现错误时,找到根本原因具有很大的挑战性。
四、容错
容错是不会降低整个系统的单个服务。当故障发生时,应用程序可以在一定的满意度下运行。如果没有容错能力,系统中的单个故障可能会导致完全崩溃。断路器可以实现容错,它是一种将请求包装到外部服务,并检测它们何时出现故障的模式。微服务需要一定程度上容忍内部和外部故障。
五、循环依赖
跨不同服务的依赖管理,这个功能非常重要。如果不及时识别和解决,循环依赖可能会产生问题,当依赖关系形成了环,最终导致:在安装 A 软件包之前,必须要安装 A、B、C、D 软件包
六、DevOps 文化
微服务非常适合 DevOps。它提供更快的交付服务、跨数据的可见性和具有成本效益的数据。它可以将他们对容器化转换的使用从面向服务的架构 (SOA) 扩展到微服务架构 (MSA)。
微服务的其他挑战
- 随着我们添加更多微服务,我们必须确保它们可以一起扩展。更多的粒度意味着更多的组件,增加了系统的复杂性。
- 传统的日志记录是无效的,因为微服务是无状态的、分布式的、独立的。日志记录必须能够跨多个平台关联事件。
- 当更多的服务相互交互时,失败的可能性也会增加。
THE END