每个微服务之间都是通过共享数据库,共享缓存进行交互的,并没采用彼此之间的接口调用。

问题:
spring boot 搭架了多个微服务,让其轻量级, 没有引入 spring cloud netflix的服务发现注册,熔断器等技术框架。为了防止多个微服务彼此采用 restful 接口调用 在没有netflix(服务发现注册,熔断器)的保护下,极有可能发生雪萌效应。故我每个微服务之间都是通过共享数据库,共享缓存 进行交互的。
 
之所以采用以上设计原因有二,
一、是出于 公司目前所接触的业务都是企业级级别的,对其高并发性,高可靠性,稳定性要求不太高。
二、是由于自己从游戏行业出来,才接触spring boot微服务,在去学习spring cloud netflix一套分布式架构需要花费更多的时间去学习,去理解。而且公司当时也并没有给我宽裕的时间去做这件事情。
最后 在此感谢超哥在我学习微服务架构的路上给予的帮助。
 
 这里在补充一下问题:
首先每个微服务都是独立的,不存在相互之间的接口调用,全部通过数据共享来进行业务交互。下面上传一张简单的图示:

架构图_2.png

图例上提到的DAO 泛指数据交互层,包括对持久化关系型数据以及缓存数据,并非传统意义上的DAO。
 
这里使用了nginx做负载均衡,分流。最上层采用阿里巴巴提供的LBS 做服务发现,注册等服务管理。
框架里面的每个服务没有引入任何spring cloud 体系的功能。

故想在这里听听大家的意见,采用这样的架构会有什么潜在的问题或者给业务开发使用上造成一定的不方便,增加开发难度等。


 
 
 
 
已邀请:

itmuch.com - 《Spring Cloud与Docker微服务架构实战》作者

赞同来自:

一般来说微服务更提倡各个微服务有自己的存储(数据库、缓存等等)。

泥瓦匠BYSocket - bysocket.com

赞同来自:

可以这么过渡,但都是独立 db ,独立服务

梁桂钊 - 后端攻城狮,微信公众号「服务端思维」

赞同来自:

从架构设计层面来说,数据层面(Mysql、MongoDB、Redis)在服务中是透明的,不建议共享数据,每个微服务单独使用一个数据库。每个微服务之间,一般情况下,使用消息队列来解耦,例如 RabbitMQ。

xiaobaxi - Fang Oba

赞同来自:

数据一致性大部分会采取最终一致性。其实通过一些交互友好性,就可以让用户认为这个最终一致性是可以接受的。平常也有遇到过一些情况,银行的转账或者发工资,其实消息还是会有延迟的

json

赞同来自:

你这个“家电报修业务”和微服务没啥关系,对于数据库中同一条记录的更新,应该采取“锁”的方式解决。

采蘑菇的大叔 - 80后IT男

赞同来自:

从某个角度来讲,这个不能算是微服务。微服务的DB最起码应该是独立的,你的这个只能叫独立的模块。
只是你用spring boot实现了各个系统的各个模块,让他们各自独立。这个比传统的单一程序好在功能独立。各个模块可以独立部署,独立维护。
但是数据共享我觉得会有问题,如果业务比较简单, 这个东西其实也挺好。 

要回复问题请先登录注册