2 anybyb anybyb 于 2017.09.05 21:16 提问

微服务具体工程划分问题

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

那么如果是微服务化的话,我的理解就是把它按照模块分成不同项目,每一个项目都是独立的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是一个工程)。

2个回答

anybyb
anybyb   2017.09.06 09:18

怎么没人啊 我去来个大神给我讲讲

xinzhongtianxia
xinzhongtianxia   2017.09.09 13:04

按业务划分。与ssm无关,与mvc无关

Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
微服务基础建设所需要的各个模块以及缘由
1、微服务一个“服务”,可以对应多个服务实例。把每个服务实例都视作一个黑盒,这个盒子有着明确的输入点和输出点,并且(理想情况下)仅通过这些输入和输出点和外界产生关联。每个服务实例会拥有专属的网络地址、独立的计算资源,并且独立部署。客户端通过访问服务实例的地址来调用服务API(接口)。不同服务也可以相互调用。2、配置管理器:统一管理配置在微服务体系中,每个服务都独立部署和运行,团队可以根据需要自行选...
微服务架构 (七): 微服务粒度设计上的核心设计原则与思考的面向
架构师在设计微服务时, 需把握一个核心的设计原则: 微服务 “外部的世界” 远比 “内部的世界” 重要。
微服务的创建、合并提取
一、父级Maven项目1.创建file——new——maven project——next——填写group Id 、Artifact Id、检查包名——finish2.pom.xml文件中<packaging>jar</packaging>应该改为<packaging>pom</packaging>3.右击项目名称——Maven——Update p...
微服务架构中模块划分和服务识别
微服务架构中模块划分和服务识别 最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务API接口的识别和定义问题,因此这篇文章将重点谈下微服务架构实践过程中的微服务模块划分和服务识别。 最近在进行微服务架构的交流和讨论中,除了谈到微服务技术架构外,客户往往更加挂你微服务模块的划分粒度,已经具体的微服务
F1V3.0-12 微服务开发规范
微服务划分原则 按功能模块划分 微服务之间减少互相调用 微服务端4大模块原则 微服务一个功能模块做成一个普通微服务interface对外提供接口starter用自动装配的方式在微服务启动时加载一些公共组件util经常用到的一些工具类库  命名规范 服务命名 采用递进式命名方式,用'-'作为间隔符。例如:f1-permission表示f1平台的授权相关的微服务模块,f1-starter
微服务的4个设计原则
微服务架构演进过程最早是应用是单块架构,后来为了具备一定的扩展和可靠性,就有了垂直架构,也就是加了个负载均衡,接下来是前几年比较火的SOA,主要讲了应用系统之间如何集成和互通,而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。微服务架构的基本思想就是“围绕业务领域组件来创建应用,让应用可以独立的开发、管理和加速”。微服务架构的好处四个方面的优点: 每个微
微服务架构(二): 如何把应用分解成多个服务
工作中使用了微服务,接下来的一段时间里,我会写一系列的文章来介绍微服务架构,同时我也会在github上写一个microservices的应用框架(地址会在后续文章给出)。 上一篇文章详细说明了单一应用架构与微服务架构各自的优缺点,这篇文章是对  http://microservices.io/patterns/decomposition/decompose-by-business-capabi
微服务的边界 (粒度) 是 "决策", 而不是个 "标准答案"
微服务的边界 ,粒度是 "决策", 而不是个 标准答案。 许多人面对微服务时,往往都会纠结着一个问题:微服务太小?太大? 其实,会纠结在这个问题上,最根本的原因便是误解了微服务粒度划分这件事的本质;微服务划分本身是 "架构设计"。也就是说微服务划分本身绝不是一个只讲"太大" 或 "太小" 标准答案的 "是非题"。而是需综合考量以下的因素,所作出的一个 "架构决策": 1. 市场业务的扩
微服务踩坑之边界
近年来微服务/SOA很是流行,我们团队赶时髦,也玩了玩。虽然用的时间还不长,但也已经踩过不少坑。今天想记录下自己对边界问题的一些思考。 很多人在谈起微服务时,总是会很自豪的说,微服务为我们提供了高内聚低耦合的明显好处,因为微服务强化了模块化的概念。但是, 如何模块化,如何明确的定义模块的边界,却很少有人提及,而这正是微服务架构的难点,也恰恰是开发人员技术能力的体现。如何正确的定义模块的边界,
微服务化架构理解及应用实例分析
微服务化架构理解及应用实例分析,服务化架构是当前最火的概念,当我们一谈到服务化第一时间联想到的就是互联网应用中,采用服务与服务之间进行互联调用的架构模式。RESTful、Json、Webservice,一定是绕不开这些词汇。但是从我个人理解,服务化应该是一种架构设计的理念。相对于之前非常流程的模块化设计思路,服务化是模块化的演进。从原来大颗粒的模块,转变为专注于特定业务、功能的服务(单元)。 从架构的构架上,依照微服务化的思路,首先明确服务的概念,并进行服务的分层。每层均由提供不同功能的服务组成,从原来模块