微服务定义中，每个微服务有一套自己的数据库，缓存，消息队列等资源
在我司的现有产品中，有一个核心的基座产品-“物联网平台”，目前由我来维护，不管领导还是新入职的新员工，对此平台的架构都认为是微服务架构，因为它确实实实在在的拆分了很多不同的模块，这些模块之间的交互采用了RPC服务。但我认为，这不是真正意义上的微服务架构，因为在微服务架构的定义中，各个服务之间是要自治的，可以独立演进，所以这要求每个服务都要有自己的一套数据库以及其他组件，那么这种不完全进化的架构叫什么，我称之为**“微服务式单体架构”**。
进一步的，如果多个微服务共用一个物理数据库集群，但是使用逻辑库进行隔离，这种可以吗，显然是不行的。这种做法带来的一个最大的问题就是自治性不足，因为共享一个数据库的资源（如连接池、存储、计算资源等），如果有一个服务占据太多的数据库资源，就有可能会导致数据库资源瓶颈，进而影响其他服务，所以这也不是完全的微服务。
但是，完全态的微服务带来的代价就是费用问题，在就目前的软件项目而言，服务器资源在整个软件项目中费用占比通常不是很高，所以导致软件厂家必须缩减服务占用的资源，那么“微服务式单体架构”在这个角度来说也不失是一个折中的解决方案，既有微服务架构的伸缩弹性，也节省了数据库资源。