我目前正在探索微服务架构的概念，并试图理解其定义的细微差别，特别是与整体架构相比。
我的具体问题是：在完整的整体式架构与完整的微服务架构之间的哪个点上，服务可以真正被视为微服务？
为了将其置于上下文中，请考虑一个三层应用程序，其中每一层都有自己单独的代码库并在单独的服务器上运行：
前端：具有 React 前端的 Node.js 应用程序。 后端：处理业务逻辑和服务器端操作的 Django 应用程序。 数据库：一个单独的数据库服务（例如，PostgreSQL、MongoDB等），前端和后端都与之通信。 每个组件都是独立开发和部署的。然而，它们在整体功能方面紧密集成，并且可能共享一个通用的数据模型。但它们足够宽松，可以经常独立升级。
在这种情况下，这些组件（Node.js 前端、Django 后端、数据库服务）中的每一个都可以被视为单独的微服务吗？如果不是，需要哪些附加特征或修改才能将它们归类为微服务？
我特别有兴趣了解区分微服务与多层架构中的简单模块化组件的最低标准。我们将非常感谢该领域最佳实践的示例或参考。
大多数术语的界限很模糊；例如，“袜子”和“鞋子”之间没有明确的界限，尽管大多数袜子/鞋子要么明显是袜子，要么明显是鞋子，但始终没有适用于袜子/鞋子的特定标准或一组标准告诉你它是什么，并且考虑到一个足够边界的情况，不同的人会不同意。
我认为几乎每个人都同意标准三层架构中的层不是“微服务”；而是“微服务”。相反，微服务架构涉及多个接受服务到服务调用的后端组件（可能是 RPC 调用，尽管 RESTful 和消息队列架构也是可能的）。但此类服务的具体数量、规模或同质性并没有标志着从“非微服务”到“是微服务”的突然转变。界限是模糊的，并且不可避免地带有主观性。