说明：
为什么放弃zookeeper dubobo，阿里有个很奇怪的现象，但凡开源出来的东西基本上就不维护了。技术的日新月异，不断的进行更换交替，总是有着相同的终点和不同的起点。
选择Spring Cloud一方面出于尝试性，另一方面出于对后来者更容易接触；毕竟对于java 这一块来说spring 这几年似乎得了疯牛症，什么都去插一脚，权限，微服务，分布式，数据库，jpa等等。
这是大体的项目构建方案 先上个图后续慢慢完善，
zuul ：路由中心，主要处理路由；
user ：用户模块也就是业务模块；
upload ：文件管理上传下载的模块，专门负责文件上传，格式转化，压缩等等一系列有关服务器文件的相关内容；
tools：一些工具包，utils，还有一些返还的基本方法之类主要负责整个项目的全部自定义的辅助方法比如 电话号码识别，ip识别等等一些；
sso ： 单点登录以及权限控制中心，用户请求模块业务，以及权限处理都在整个服务内进行，目前用jwt+redis，权限使用spring security ；
rbbion： 负载均衡控制中心；
mybatis ：这里统一管理 各个mapper 和 xml文件，所有模块的xml和 mapper 和 vo类；这样设计的目的有利之处在于各个库之间用文件名区分统一管理，维护的时候方便，调用各个Mapper之间更加方便；有弊之处就是，项目大了之后可能部署时 各个木块之间 此jar 可能会不同步的问题，这里讲后续时再解释，目前暂时想到这里；
message：消息队列中心，目前主要使用kafak；
log ：日志统一处理；
job：实现所有定时业务，用Quartz，负责整个项目的定时任务；
eureka： 服务发现中心；
config ：整个模块的配置中心；通用统一配置；此处只配置通用；接上面的问题来说：jar 不同步的问题；
首先开发 模块 例如user 用户中心模块 打包方式采用 lib jar 外置的方式（就是把lib 不打包到项目内，打包到项目外，然后有新的关联jar 加入的时候 只需要更换指定 jar 就行了，不需要重新打包，而且项目主体出去jar 后 每次部署上传可能就 几M） 所以 如果某个模块一直都没更新过 mappr 或者 xml的话 那么 几个版本迭代之后 前后的 Mapper.jar（即 mybatis模块）可能出现不一致太多，唯一能够降低管理成本的 就是 每一个 mapper.jar 尽量做版本管理 ；
这样构建的思想： 其实开发的时候 你只要交给 下面的程序user 模块和 mapper 这样的模块就行了 剩下 的 的作为一个架构 就是慢慢去完善那些 内容就行了。
1186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
