关于微服务的拆分问题

[阿诺]

【技术区发不了技术贴了发到灌水区了】

微服务最近很多但是对微服务的理解貌似有点不怎么透彻
比如我的项目有用户，订单，积分，消息，商家，商品等这么多模块。如果是单一工程就是很好理解就是一个项目全部都写到里面

那么如果是微服务化的话，我的理解就是把它按照模块分成不同项目，每一个项目都是独立的ssm结构的工程，比如用户(user),订单(order)等等都是单独的独立的完整的一个ssm（mvc三层结构）结构的项目。
然后用户这里需要调用订单也需要调用积分。那就是用dubbo或者spring cloud或者说直接用http来调用就好了。

以前我一直这么理解的。但是最近公司架构师在架构微服务的是好像不是这么回事。

首先架构师还是按照模块分了这么几个项目（分了user,order，message等），但是有个问题就是架构师架构的微服务都是只有service+dao两层结构的工程。然后将springmvc的controller单独抽取出来了。这里可能有UserController,OrderController，成了这种结构了。

到底哪一种是正确的。

感觉spring cloud还是需要一个完整的ssm（三层结构的项目），dubbo好像是我们架构师那种结构（controller是一个工程，service+dao是一个工程）。

[爱吃火锅的S]

自我认为，没有正确的说法，从来的业务对技术选型，楼主可以想下这两种的区别，个人拙见。

[安优小青和他的程序生活]

他把 controller 提取为单独的项目，就是为了向外提供接口 把service + dao提取为模块项目，就是为了向dubbo提供服务或消费服务 不知我说的和你们的一样否？