当前位置:首页 > 编程世界 2017年11月27日
SOA微服务案例springboot+mybatis使用gradle构建案例

SOA系统架构的体现之springboot+mybatis框架

题外话 :为什么要选用SOA架构 
不同种类的操作系统,应用软件,系统软件和应用基础结构(application infrastructure)相互交织,这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程(business processes),因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应,利用对现有的应用程序和应用基础结构(application infrastructure)的投资来解决新的业务需求,为客户,商业伙伴以及供应商提供新的互动渠道,并呈现一个可以支持有机业务(organic business)的构架。SOA凭借其松耦合的特性,使得企业可以按照模块化的方式来添加新服务或更新现有服务,以解决新的业务需要,提供选择从而可以通过不同的渠道提供服务,并可以把企业现有的或已有的应用作为服务, 从而保护了现有的IT基础建设投资。

下面进入主题: 
本例是springboot+mybatis+gradle构建而成 
如下图是工程的目录结构:

这里写图片描述

构建工程和其它springboot的工程构建流程一样,这里主要记录一下几个在实际工作过程中需要注意的地方。

  1. 工程属性的配置文件环境化 
    顾名思义,一个正真的工程都是要进行不断的环境变化的,这就要求工程必须在很小的改动情况下适应不同的工作环境,简单点比如在开发环境,测试环境以及生产环境,这是比较通俗的环境定义,当然在不同的企业要求下可能有些不同。但不管怎么样,对于工程而言要都有高度适应性。springboot提供给我门极简化的工程配置application.properties,里面基本可以满足简单工程的所有配置。这是对于工程而言的,对于环境而言,springboot并没有从这层面来解决我们的问题,需要借助第三方工程管理工具来帮我们解决这个问题,比如maven,比如gradle,下面我们列举在gradle中是如何操作的。 
    -1) 引入environment概念,操作而言,既在主目录下创建environment,并在里面定义环境目录,如图:这里写图片描述 
    - 引入environment后需要我们的构建工具gradle进行配置,使得gradle构建工具去识别认识它,所以我们在build.gradle中添加可扩展变量ext.env = hasProperty(“env”) ? env : “dev”,如图: 
    这里写图片描述 
    至此,配置文件在可变环境下的配置就OK了,可以使用命令 gradle build war来感受一下打出来的包是否是相同的路径下了。 
    -2) 记得在操作上面的步骤之前把本地包引入,不然之前的一切都白搭了,如图: 
    这里写图片描述 
    最后打包完的结果是: 
    这里写图片描述
    这里写图片描述

  2. 工程的日志输出合理化 
    springboot的配置文件可以帮我们解决日志配置的问题,但是如果不加热部署条件,日志格式就显得有点鸡肋,于是我们可以自定义日志格式,即在主目录下引入logback.xml配置文件,spring boot会自动扫描该文件并加载相关bean,如上图目录。日志文件也可以做到在不同的环境中有不同的配置,这个和上面的步骤一样。

  3. 工程目录结构的层次化 
    工程目录的层次化是必须要做的事,没有清晰明了的层次结构,工程到最后会很乱,对代码的管理是极为不便的,甚至会影响到构造部署包时对相关目录操作的复杂化。所以我们要做到: 先层次化–>模块化–>结构化, 以此保证代码的管理的健壮性。 
    在最后要强调一点,如果工程使用的是mybatis,切勿将sql脚本与Java代码以及Java文件目录糅合到一起,这样严重违背mybatis的初衷:高度可配置,高度可维护。

题外话,有一位前辈Java程序员一天问我,gradle熟吗?我说会用。他说:“你懂它的原理吗?”“这个真不懂”。对于我们大多数程序猿来说,它就是个工具,你无须去深究他的原理,能够熟练运用它即可。工程使用maven或者gradle构建都一样,初学者无须纠结该使用什么工具,哪个熟悉就用那个。等能够深刻理解工程构建思路时,可以尝试相互转化,融会贯通。