springCloud搭建一套简单的分布式

说明：

     为何放弃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 这样的模块就好了 剩下 的 的做为一个架构 就是慢慢去完善那些 内容就好了。