首页 新闻 搜索 专区 学院

微服务开发服务划分

0
悬赏园豆:50 [待解决问题]

在做微服务开发时,核心业务放在服务层,每个服务处理各自的业务逻辑,然后有一个web层,负责包装服务层接口,对外发布,可供app、网站等调用,那么web层是否也需要根据业务服务一样进行细粒度划分吗,如订单服务、产品服务对应订单web服务、产品web服务。如果这么细的话,服务划分是否太多,如果不这么细,那么web层又该由谁负责编写呢?

海风~的主页 海风~ | 初学一级 | 园豆:152
提问于:2017-05-08 16:27
< >
分享
所有回答(5)
1

不多,分层不仅是横向的,纵向也是要分的,叫分割。web层一般公司里都是前端开发工程师写,跟后台对应项目的配合

北方姆Q | 园豆:856 (小虾三级) | 2017-05-08 16:34

你好,我们现在就是在纵向划分,比如产品服务、订单服务,但这些是核心的服务且之间的通信现在是用rest后期可能改为socket等,如果对外发布接口的话肯定会有web层来包装前端请求,重组参数然后调用后边的这些服务,我在想web层也需要根据后边的这些服务这样一一对应起来吗,还是一个web服务就行了

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-08 17:15

@海风~:  内部一一对应,但是在外部看起来是一个整体,尽量解耦,web层保持透明,接口得看你都需要对外提供什么服务了

支持(0) 反对(0) 北方姆Q | 园豆:856 (小虾三级) | 2017-05-08 17:43

@海风~: 最重要的,你团队多少人.....

支持(0) 反对(0) 北方姆Q | 园豆:856 (小虾三级) | 2017-05-08 17:45

@北方姆Q: 我们的项目做外包,我们自己做设计、拆分,然后外包出去,如果一一对应可能好做一些,比如,订单模块的团队做订单服务、订单web服务,产品模块的团队做产品服务、产品web服务,我主要在想如果web服务过多的话,会不会有什么影响呢?

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 09:45

@海风~: 影响就是你们一开始的时候设计细分时需要花点时间,之后就不会了,但是这是值得的,如果web曾都是耦合的,那以后伸缩性扩展性都会很痛苦,一般就得重构。你做外包很敬业啊,好多外包都是去卖卖萌接触不到核心业务的

支持(0) 反对(0) 北方姆Q | 园豆:856 (小虾三级) | 2017-05-09 10:08

@北方姆Q: 那假如订单详情中需要查询商品最新的详细信息,这个时候就可以在订单web服务中进行调用商品服务接口进行组装数据了是吧,因为这些不是核心的业务逻辑,如果是生成订单,需要保存商品的快照,这个时候就应该在订单服务中调用商品服务的接口进行数据的保存,因为生成订单是核心业务,所以要下沉到订单服务中去做。这样理解你觉得没问题吧?

我是甲方啊,我负责把公司的需求、设计等都出理好了,然后拆分外包出去呀。

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 10:12

@海风~: 是的,祝你成功!

支持(0) 反对(0) 北方姆Q | 园豆:856 (小虾三级) | 2017-05-09 10:25

@北方姆Q: 好的,谢了,请问您们有没有微服务开发经验,有没有什么需要提前注意的,我们刚开始,还是有些迷茫的。。

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 10:26

@海风~: 微服务的没有,我就是从架构方面考虑的,需要注意的就是web层不要涉及到处理业务逻辑,web层跟服务层中间可以加rpc解耦,然后就是找个正经的外包团队.....

支持(0) 反对(0) 北方姆Q | 园豆:856 (小虾三级) | 2017-05-09 10:32

@北方姆Q: 嗯,好的,谢了

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 10:33
0

关于Socket还是HTTP,其实都可以,主要看业务访问量,springboot默认就是HTTP。

 

服务划分得细一些,联调会比较不方便,但容易扩展。

 

web层肯定是后端工程师写啊

狼爷 | 园豆:1192 (小虾三级) | 2017-05-08 17:43

恩,我主要在想 web层服务需要跟核心的服务一一对应吗,比如订单模块、产品模块,会有订单服务、产品服务,那么web层是分成两个服务好一些呢,还是合起来做一个服务就行呢

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 09:47

@海风~: 推荐一一对应

支持(0) 反对(0) 狼爷 | 园豆:1192 (小虾三级) | 2017-05-09 11:42

@编程点滴: 好的,谢了

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-10 10:33
0

后端服务细粒度api(crud)

中间用node包一层(授权啦,接口限制啦等,接口组合包装)

各个client端直接调

czd890 | 园豆:8891 (大侠五级) | 2017-05-08 22:36

后端服务细粒度api如果做成crud是否太细了?中间这一层一个服务就行了吗?

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-09 09:48

@海风~: 

后端服务细粒度的业务方法。

中间服务是笔记粗的接口包装。比如获取订单信息接口。那可能要用到后端的商品服务,订单服务,价格服务,物流服务等等。中间服务也是多个呀。

支持(0) 反对(0) czd890 | 园豆:8891 (大侠五级) | 2017-05-09 13:17

@calvinK: 那中间服务,再往前还要有一层用来包装各个来源请求的服务吗

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-10 10:34

@海风~: 没必要了,app,wap,pc都走这个好了

支持(0) 反对(0) czd890 | 园豆:8891 (大侠五级) | 2017-05-10 10:35

@calvinK: 嗯,好的,谢了

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-10 10:36
0

这个是指前端分模块开发么还是怎么着

全力以赴001 | 园豆:616 (小虾三级) | 2017-05-09 15:50

前后端都划分模块,需要一一对应码

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-10 10:34

@海风~: 是的哈,这样不仅开发粒度细,而且方便维护

支持(0) 反对(0) 全力以赴001 | 园豆:616 (小虾三级) | 2017-05-11 09:01
1

架构都是按业务需求来的。不见得有通用的方法。举例说:如果是一个日志服务,数据库存日志,前端Web显示日志。我觉得2层就更合理。

如果像商品服务等,可能就需要多层。最底层一定是包含了数据的细分模块。然后功能性的一半会略高,例如支付系统,订单系统,仓储系统。接着更高一点的可以是业务融合层,例如京东的手机商城,家电商城,也可以是京东白条等独立业务。在上层可以是对外模块,如App,各种Web前端站点等。而现在流行的前后端分离的模式,可能还要给每个前端站点,搞一个对应的后端模块,处理页面数据的整合的工作。

架构无统一定论好坏,适用业务需要就行。

rinson | 园豆:275 (菜鸟二级) | 2017-05-10 16:34

嗯,是的,在你说的最后一个功能上,前后端分离模式中,每个前端站点搞一个对应的后端模块,处理页面的整合工作,那这个后端模块是一个比较好呢?还是细分一下?比如:网站后端的一个模块负责订单、商品、支付的页面数据整合工作,还是网站后端分为三个模块分别为订单模块、商品模块、支付模块来负责整合页面数据的工作呢?

支持(0) 反对(0) 海风~ | 园豆:152 (初学一级) | 2017-05-10 20:34

@海风~: 事无定论。前段时间听说途牛很多微服务只有一个api接口,明显就事粒度太细,导致微服务泛滥了。模块粒度或者说微服务大小,道上的标准说法是1个人2周的开发工作量可以重写一个模块,我估计大概10来个api接口作为一个模块会比较合适。如果更多就建议拆了。

支持(0) 反对(0) rinson | 园豆:275 (菜鸟二级) | 2018-07-03 15:00
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册