微服务开发服务划分
0
所有回答(5)
1
不多，分层不仅是横向的，纵向也是要分的，叫分割。web层一般公司里都是前端开发工程师写，跟后台对应项目的配合
你好，我们现在就是在纵向划分，比如产品服务、订单服务，但这些是核心的服务且之间的通信现在是用rest后期可能改为socket等，如果对外发布接口的话肯定会有web层来包装前端请求，重组参数然后调用后边的这些服务，我在想web层也需要根据后边的这些服务这样一一对应起来吗，还是一个web服务就行了
@海风~: 内部一一对应，但是在外部看起来是一个整体，尽量解耦，web层保持透明，接口得看你都需要对外提供什么服务了
@海风~: 最重要的，你团队多少人.....
@北方姆Q: 我们的项目做外包，我们自己做设计、拆分，然后外包出去，如果一一对应可能好做一些，比如，订单模块的团队做订单服务、订单web服务，产品模块的团队做产品服务、产品web服务，我主要在想如果web服务过多的话，会不会有什么影响呢？
@海风~: 影响就是你们一开始的时候设计细分时需要花点时间，之后就不会了，但是这是值得的，如果web曾都是耦合的，那以后伸缩性扩展性都会很痛苦，一般就得重构。你做外包很敬业啊，好多外包都是去卖卖萌接触不到核心业务的
@北方姆Q: 那假如订单详情中需要查询商品最新的详细信息，这个时候就可以在订单web服务中进行调用商品服务接口进行组装数据了是吧，因为这些不是核心的业务逻辑，如果是生成订单，需要保存商品的快照，这个时候就应该在订单服务中调用商品服务的接口进行数据的保存，因为生成订单是核心业务，所以要下沉到订单服务中去做。这样理解你觉得没问题吧？
我是甲方啊，我负责把公司的需求、设计等都出理好了，然后拆分外包出去呀。
@海风~: 是的，祝你成功！
@北方姆Q: 好的，谢了，请问您们有没有微服务开发经验，有没有什么需要提前注意的，我们刚开始，还是有些迷茫的。。
@海风~: 微服务的没有，我就是从架构方面考虑的，需要注意的就是web层不要涉及到处理业务逻辑，web层跟服务层中间可以加rpc解耦，然后就是找个正经的外包团队.....
@北方姆Q: 嗯，好的，谢了
0
关于Socket还是HTTP，其实都可以，主要看业务访问量，springboot默认就是HTTP。
服务划分得细一些，联调会比较不方便，但容易扩展。
web层肯定是后端工程师写啊
恩，我主要在想 web层服务需要跟核心的服务一一对应吗，比如订单模块、产品模块，会有订单服务、产品服务，那么web层是分成两个服务好一些呢，还是合起来做一个服务就行呢
@海风~: 推荐一一对应
@编程点滴: 好的，谢了
0
后端服务细粒度api（crud）
中间用node包一层（授权啦，接口限制啦等，接口组合包装）
各个client端直接调
后端服务细粒度api如果做成crud是否太细了？中间这一层一个服务就行了吗？
@海风~:
后端服务细粒度的业务方法。
中间服务是笔记粗的接口包装。比如获取订单信息接口。那可能要用到后端的商品服务，订单服务，价格服务，物流服务等等。中间服务也是多个呀。
@calvinK: 那中间服务，再往前还要有一层用来包装各个来源请求的服务吗
@海风~: 没必要了，app，wap，pc都走这个好了
@calvinK: 嗯，好的，谢了
0
这个是指前端分模块开发么还是怎么着
前后端都划分模块，需要一一对应码
@海风~: 是的哈，这样不仅开发粒度细，而且方便维护
1
架构都是按业务需求来的。不见得有通用的方法。举例说：如果是一个日志服务，数据库存日志，前端Web显示日志。我觉得2层就更合理。
如果像商品服务等，可能就需要多层。最底层一定是包含了数据的细分模块。然后功能性的一半会略高，例如支付系统，订单系统，仓储系统。接着更高一点的可以是业务融合层，例如京东的手机商城，家电商城，也可以是京东白条等独立业务。在上层可以是对外模块，如App，各种Web前端站点等。而现在流行的前后端分离的模式，可能还要给每个前端站点，搞一个对应的后端模块，处理页面数据的整合的工作。
架构无统一定论好坏，适用业务需要就行。
嗯，是的，在你说的最后一个功能上，前后端分离模式中，每个前端站点搞一个对应的后端模块，处理页面的整合工作，那这个后端模块是一个比较好呢？还是细分一下？比如：网站后端的一个模块负责订单、商品、支付的页面数据整合工作，还是网站后端分为三个模块分别为订单模块、商品模块、支付模块来负责整合页面数据的工作呢？
@海风~: 事无定论。前段时间听说途牛很多微服务只有一个api接口，明显就事粒度太细，导致微服务泛滥了。模块粒度或者说微服务大小，道上的标准说法是1个人2周的开发工作量可以重写一个模块，我估计大概10来个api接口作为一个模块会比较合适。如果更多就建议拆了。
