Skip to content

intomylife/SpringCloud

Repository files navigation

简单了解微服务

所有代码都通过测试,并且真实有效

github star github fork real stuff - Max


简介

本仓库整合了一些工作中经常用到的一些技术。目前深度较浅,但会持续更新,并且会慢慢加深。

文档

对于项目结构的一些说明

前言

有朋友说出了一些疑问:

为什么有些工程里没有任何代码,是有什么特别的用途或者意义吗?

我的回答是:

可以看出,所有的相关整合我都是用的一种结构,这种结构其实是可以适用于 Dubbo微服务 架构的,也是出于习惯,即使有些单个的技术点可能只需用到一两个类文件,我也是“不厌其烦”,更或者说是想保持一种统一的风格,就还是把所有的目录结构全部新建上去。

不过,最近我发现了一个很尴尬的事情:

原来提交代码的时候,Git 自动把空目录过滤了!也就是空目录压根没有提交上来,内心瞬间“五味杂陈”(笑 cry)。瞬间想到,原来问我的是:大兄弟提交的空目录是干啥的?随后我花了一天的时间把所有的空目录补回来了:e95ab8cffebc70e740e7fa94200948bea7dc933cd1606041c280a72cf698544

结构

最外层目录:

  • xxx-commons:公用工程,用来引入公共的依赖,编写默认初始的配置信息,对应的工具类,以及统一返回实体类等等能抽取出来的一切公用代码。比如当项目中需要使用Redis做缓存,这时首先会在此工程中引入Redis的依赖spring-boot-starter-data-redis;其次编写Redis默认的最大连接数,连接超时时间等这些配置信息;然后考虑到兼容还需要统一解决序列化问题;最后把一些频繁使用的Redis操作封装到工具类中来简化调用。

  • xxx-service:聚合服务工程,用来指定SpringBoot版本信息,配置部署信息,以及包含所需的所有子模块。也就是说这个父工程是没有其他代码的,主要就只有一个pom.xml文件。

xxx-service:

xxx-service-api:

  • 每个模块中的“接口”工程

  • 使用Dubbo技术调用服务时,需要先把对外提供的接口在内部实现了,然后再对外暴露并被引入到调用者的工程中,这时为了解耦合,会只把对外暴露的接口单独写在一个工程里,也就是当前的 xxx-service-api 工程;在 SpringBoot 整合各类框架和应用 中对应的目录结构如下

 - api              ## 对外暴露的接口
 - constant         ## 常量
 - dto              ## 扩展实体类
  • 使用服务注册与发现技术调用服务时,而是使用的 服务名 + 请求的完整签名 来实现的,所以到 简单了解微服务 时目录结构变成了这样
 - constant         ## 常量
 - dto              ## 扩展实体类

xxx-service-core:

  • 每个模块的“核心”工程

  • 而此时两种架构的基础结构都有如下

 - controller       ## 前端控制器
 - domain           ## 基础实体类
 - mapper           ## mapper 接口
    - xml           ## mapper.xml 文件
 - service          ## 处理业务逻辑
  • 如果是使用Dubbo技术,那么,要在自己内部实现对外暴露的接口,所有就有
 - api              ## 这里与 xxx-service-api 工程的包名统一
    - impl          ## 对外暴露接口的实现类
  • 如果是使用服务注册与发现技术,那么,写远程调用的类就在
 - feign        ## 远程调用
    - fallback  ## 熔断方法
  • 甚至,使用服务注册与发现技术时,可能还会把给其他服务调用的方法专门放在一个统一的包下管理
 - api          ## 被其他服务远程调用

其他:

可能之前有些项目结构不是和上面所描述的一致,但是现在开始往后的都会以这个为标准来搭建

联系我

如果您有任何疑问,或者有宝贵的建议,欢迎提交 issues

或通过如下方式联系我:

关于我