Sprint boot 菜鸟请教一个微服务架构中对模块进行拆分的问题，望指教

就我之前的项目经验来说，如果你这是个大型项目，且前期就能确定业务模块比较多的话，那么前期设计的时候就可以尽量的细分，或者即使不细分也要为以后得拆分留余地，不然经过一系列迭代升级之后再去拆分会头疼

小项目就无所谓了，大头的业务功能模块分清楚就好，其他怎么简单怎么来，拆的太细反倒麻烦

一家之言

认证模块和用户模块我这边是放一起，单个认证没多少代码

@wushigejiajia01 多谢！

@312ybj 那请问一下如果 auth 和 user 合一起的话，token 在哪个模块生成？也是在 user 模块吗？

@hantsy 感谢回复，你说的第三方认证就是走 oAuth2 对吧？

基本都是支持 OAuth2/OIDC 的。

common //用于存放公共的 entity---》 这个不知道干嘛的，完全没有意义。不同 Domain 来划分 Service，即使是同一概念，建模也会不一样，比如，库存，和产品目录中的 Product，属性会有差别， 而 Customer Service 和 Order Service 中的 Customer 也不尽相同。何况，Microservice 一个准则是每个服务都是维护自己的数据库。理想情况下，每个服务应该做到完全自治。

@hantsy 这个主要就是因为我把服务拆成了 auth-service, user-service，admin-service，这几个模块都要访问一个共同的 UserEntity 。我觉得如果不抽到 common 里面的话，那就要在每一个 service 下面都放一个 UserEntity 和 UserRepository，感觉很重复。不过确实如你所说，不同模块下的 model 属性可能会有区别，所以你的建议还是去掉 common，把它们分别放到各自的模块中去？

教程 DEMO 就是学习一下组件的用法、背后的思想、参考下设计思路就好了。

实际的项目中如何落地，就需要具体问题具体分析。
做的什业务？规模多大？团队配置情况？技术选型？开发策略？从 0 到 1 还是已有体系？

我们的业务最开始就是 ALL-IN-ONE，起步时需要快速验证，用户量上去了才开始拆，才开始上各种中间件，才开始招更多的人。

架构设计都是需要匹配业务场景、业务当前的发展阶段的，纸上谈兵没什么意义，需要找一个好公司到实际的业务中去积累经验。

楼上说的对

每次遇到服务拆分的问题都建议去看下领域驱动设计的概念

我的项目中：
1.是拆分开的，oauth 服务单独拿来做授权校验等；
2.可以单独一个 admin-service ；
3.同 1 ；如果你是做 demo 来练习的话，建议没必要拆分开，而且实际开发中，目前还没见过拆开单独做 login-service 的

@admin7785
@Sayommy
好的，感谢

@admin7785 我其实也就是想听听大家实际项目中的经验，毕竟我不可能每家公司都去工作一遍，多谢分享

推荐一个脚手架，jhipster，多参考参考，它是注册中心、UAA （用户认证和授权）、网关、微服务这样。

@hantsy 什么时候微服务有「每个服务都是维护自己的数据库」这种准则了？谁提出来的？依据是什么？

照这个准则行事的话，一个领域只能存在一个服务咯？这显然是不切实际的，譬如用户管理这个领域，就可以具体拆分为：用户、用户组、组织机构、租户、角色、资源、认证等七大模块。这些难道都必须塞到一个服务里面？

一个财务管理领域，也可以分为：账户、流水、收款、付款、退款、对账、提现、开票等等功能，也必须塞到一个服务里面？

@Kyle18Tang 多谢，刚看了一眼 JHipster 的官网，感觉这个东西有点意思，是不是用了它就基本上不用操心这些框架、架构的事情了？

@chihiro2014 什么乐优商城？

@xuanbg #17 https://martinfowler.com/articles/microservices.html

Martin Fowler 在这篇文章中提出微服务这个概念的。你可以在文章中搜一下关键字词「 polyglot persistence 」。

「微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统 - 这就是所谓的混合持久化(Polyglot Persistence)。」

@demonzoo #19 可以多参考它们的东西，然后加入自己的东西，当然完全使用它们的框架创建项目也是可以的。Jhipster 使用的很多技术都是很好的实践，看看 jhipster-framework 的代码能学到不少知识，特别是 problem 库的使用，我已经打算在项目中推广。推荐异常处理一定按照标准来处理，不要返回 code 、message 、data 这种类似的格式。

@xuanbg 微服务的基础是领域编程，把领域搞清楚了，就看要拆分什么样的粒度了，我觉得一般还是按照领域（业务）来拆分，相关性强的拆分到一块，当然到时候不同领域都是要基于事件进行进程间通信的。

@tonnycao 一般而言，按领域划分服务是合适的，我举例是有些领域比较大，拆分更多的服务会比较合适。

@Xbluer 是的，「倾向于」。这一点我是认可的，也是尽量这么做的。但绝不能不因地制宜教条地认为微服务必须一个服务一个数据库，某些时候多个服务都属于同一领域，因此会在数据上产生依赖关系。这个时候就是需要多个服务共用一个数据库。

@Xbluer 原文是「 While monolithic applications prefer a single logical database for persistant data, enterprises often prefer a single database across a range of applications - many of these decisions driven through vendor's commercial models around licensing. Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence 」
Martin Fowler 拿传统单体应用和微服务做了个对比，阐明「 As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions 」这个观点。根本没提什么「准则」……有些人也太过道听途说不求甚解了吧。

只有我一个人发现 楼主标题打错了吗？

确实是标题错打了，但大家都懂看了。。。。

@ajaxfunction 噗，sprint 打顺手了

@xuanbg 我发现你字打颠倒了

@xuanbg 感谢！说“准则”确实不太合适，不过姑且可以称之为“原则”吧。

最近项目，在把原先 10 几个模块合成 3 个左右，里面关联调用太多了…维护也费劲

@hantsy 现在很多 social 账号登录，他喵的新用户还是让绑定手机账号，真想口吐芬芳

@lcinshu 是的，国内有些服务特别脑残，明明 oauth 登录完事了，还是让填写用户名、手机号什么的。早知道还是要填手机号，我费劲用什么社交账号登录啊

请问老哥这个项目，方便分享一下嘛，最近也想开始学习一下 Spring boot