微服务应该按处理层分还是按业务模块分

wei__chao 发布于 06/21 09:39
阅读 2K+
收藏 4

开源软件供应链点亮计划,等你来!>>>

现在在做一个项目,请求量和数据量都比较大,要求使用微服务完成,我应该按view层、service层、dao层区分微服务,还是按业务模块区分好点呢?如果按处理层区分,每层都需要写controller会不会有点臃肿呢?

加载中
3
sprouting
sprouting

就按照业务拆,你说的那种是dubbo的写法,不怎么好用,业务拆的方便一些,比如你要做一个商城系统,根据业务,将订单、物流、购物分别拆分开,一般购物和付款是压力最大的,我随时将这一块容器化后增加容器部署,物流之类的基本不用管,压力过去了,又可以随时缩减相应容器

wei__chao
wei__chao
点赞,很详细
3
10进制宇宙
10进制宇宙

能单独启动的才是微服务。 你拆成controller, service, dao,  dao这个玩意能单独启动吗? 连个请求都发不进去

1
letwang
letwang

微服务,本质上每个服务都是一个独立的应用,独立的应用~~~~

0
一剪梅i
一剪梅i
后台服务互相调用使用grpc就行,前端一个网关分发前端请求
0
开源中国首席聊天玩家
开源中国首席聊天玩家

当然是业务模块,独立的一个模块作为一个服务,不然要微服务干啥

0
肥仔哥哥1930
肥仔哥哥1930
我目前是都分,人员不在,分的线不多
0
纵度飞行
纵度飞行

我现在是按照业务模块分服务,暂时不分库,但是多从

0
yong230
yong230

说明你对微服务只理解个皮毛。什么是微服务,最简单来说就是按业务模块拆分成一个个小服务,每个小服务之间互不影响!

0
哎码
哎码

首先是以团队习惯为主,如果团队都习惯按业务分层,非要改那不现实。

其次个人建议先按业务分,这样开发时候更方便,也更适用复杂业务的系统,具体里面需不需要再继续分层也可以灵活的变化。

wei__chao
wei__chao
:thumbsup:
0
今天的吉祥
今天的吉祥
请求量大数据量大不代表软件是复杂的,如果内部业务较复杂,应该先在业务角度划分域,按照技术分层已经是过去式了,前提是你的业务是否复杂,你是否在正确使用微服务,还是巨大的分布式单体
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部