而共享数据最贱的方式就是采用共享数据库模式,也就是单体应用中最常用的方式,一般只有一个数据库,如图一库多服和一库一服的方式:
一库多服的架构模式通常会被认为是微服务架构下的反范式,它的问题在于:
稳定性:单点故障,一个数据库挂掉,整批服务全部停止。服务独立性被扼杀?
耦合性:数据在一起,会给贪图方便的开发或者DBA工程师编写很多数据间高度依赖的程序或者工具;
扩展性:无法针对某一个服务进行精准优化或扩展,服务会大体分为两个读多写少、写多读少,数据库优化是根据服务而来的,不是一篇而论。
所以随行付内部一般推荐的做法:是为每一个微服务准备一个单独的数据库,即一库一服模式。这种模式更加适合微服务架构,它满足每一个服务是独立开发、独立部署、独立扩展的特性。当需要对一个服务进行升级或者数据架构改动的时候,无须影响到其他的服务。需要对某个服务进行扩展的时候,也可以手术式的对某一个服务进行局部扩容。
那么问题来了,在改造中我们发现,以下问题,诞生了该项目:
报表中心和前端详细页都存在SQL Join方式,经历我们一库一服的拆分后,无法在继续使用SQL Join方式了
数据中心,做得是数据聚合,数据拆分后,给数据中心带来了很大的麻烦
微服务之后,各个应用模块对数据库的要求出现了分歧,数据库类型多元化自主选择还是统一
等等
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)