微服务架构有毒,何时不使用微服务?
在过去的四年中,使用微服务来构建应用程序似乎成了一种标准。大多数我所合作过的团队也对此表现出了不同程度的兴趣。 微服务所承诺的弹性、高可用、低耦合、敏捷,以及能够解决单体架构带来的问题,这些都是它流行的主要原因。 但是近段时间来,对于微服务的一些保留意见和注意事项似乎引起了人们的注意。 在这篇文章中,我重点想讨论的是微服务的应用,它的缺点是什么,以及在什么情况下应该慎重考虑使用微服务架构。 什么是微服务 在工业级别,关于微服务基本特征的定义比较一致。 这些特征可以总结如下: 微服务是一种应用于组件设计(服务如何分组)和部署架构(服务如何部署和通信)的模式。 微服务适用于创建具有“一定功能复杂性”的分布式应用程序。 各个服务必须小。 各个服务按功能划分,实现关注点分离。 各个服务保持自治和相互解耦,可以独立进行部署、版本控制和伸缩。 各个服务之间通过轻量级 API 和异步通道相结合的方式进行通信。 各个服务拥有独立的状态,并且只能通过服务本身来对其进行访问。 一个典型的微服务实现模式如下图: 图 1:典型的微服务实现模式 从上图中我们可以看到: 微服务中的每组服务有自己的前端 (由一个 API 和一个可选的 UI 组件组成)、一个实现自身服务领域逻辑的域层以及独立的数据存储。 前端复合。 将所有前端组件(UI 组件或 API)组合成一致前端(复合 UI 或 API 网关)。