项目里的各种配置,你都了解吗?(项目里的各种配置,你都了解吗)

  本篇文章为你整理了项目里的各种配置,你都了解吗?(项目里的各种配置,你都了解吗)的详细内容,包含有项目里的各种配置,你都了解吗英文 项目里的各种配置,你都了解吗 项目配置是什么意思 项目配置项 项目里的各种配置,你都了解吗?,希望能帮助你了解 项目里的各种配置,你都了解吗?。

  分享Java技术,高并发编程,分布式技术,架构设计,Java面试题,算法,行业动态,程序人生等。

  
来源:https://lepdou.github.io/blogs/config/config.html

  项目开发中总是有各种各样的配置,对于程序开发新手来说,配置是摆在面前的第一座大山。 回想当年在学校学习经典的“SSH”的时候,一个web.xml配置都是异常的艰辛。工作多年的你,对配置真的了解吗?

  什么是配置?

  首先我们来看一下配置文件的定义:

  “A software file used to configure the initial settings for a computer program.” -- From wikipedia

  配置来源可能有以下这些:

  硬编码参数

  项目里的配置文件

  文件系统上的配置文件

  网络上的配置文件

  启动参数(JVM属性)

  操作系统参数

  下面会详细介绍每一种配置类型的使用场景。

  硬编码参数

  最常见的就是定义静态变量方式。例如: public static final int PAGE_SIZE = 10;
 

  另外就是通过框架暴露的各种API接口设置参数。

  这种是最简单、成本最低的方式

  不用额外创建文件

  代码里能直接能读取

  离配置使用地方最近的一种方式

  代码和配置糅合在一起,不易于维护

  修改配置必须修改源代码,重新编译、打包、上线

  同一个框架的配置散落到项目各个角度,不利于查找

  Hard Code 适用于配置极其简单且几乎不会变更

  为了赋予常量语义

  配置极少从而创建配置文件成本高

  项目里配置文件

  这种方式是最常见的。标准的maven项目有一个resources目录就是用来放置各种类型的配置文件,例如:

  web项目的web.xml

  log框架的配置

  spring的bean定义的xml文件

  mybatis的sql配置文件

  spring boot的application.yml application.properties

  自定义的properties文件

  另外maven项目的核心pom.xml也算是配置文件。项目里使用到的各种各样的框架、中间件基本上都需要配置文件来支撑。框架在运行时,读取配置文件来决定运行时的行为。 配置文件路径一般有两种方式:

  按照框架约定的目录(相对于classpath)

  告诉框架配置文件的路径

  配置和代码分离

  集中统一管理配置

  不依赖项目外部资源

  跟Hard Code一样不能动态修改配置

  配置文件增生,导致项目臃肿

  非常适合框架或者中间件的配置

  项目中自定义业务配置

  文件系统上的配置文件

  此类配置文件是放在应用运行的机器上。常见的比如携程公司内部机器上都会放置一个server.properties文件。文件内容主要是当前机器的一些信息,比如env=dev标示当前机器属于dev环境。公司配套提供framework-fundation基础jar包,用来解析这个文件。

  那么应用只要通过framework-foundation来获取机器的相关信息。 framework-foundation在这里的作用就是作为机器和应用之间的桥梁。这种方式主要好处是规范运维。 另外一种使用比较多的场景是应用直接读取文件系统上的某个文件。这种方式的好处就是可以动态更新配置,无需重新编译、打包、运行应用。

  配置和代码分离

  可动态修改配置

  配置和应用代码不在一个地方(项目源码),不易于理解和运行

  修改配置需要登录机器

  修改配置文件可能涉及权限问题

  配置文件路径也需要沟通

  不建议作为应用业务相关的配置,成本高且不易于开发维护

  适用于运维相关的配置,如前面举的例子

  笔者遇到过一个dal框架,datasource配置文件就是放在文件系统上,结果开发人员在上线时,忘记在机器上放置这个文件导致线上bug。

  网络上的配置文件

  常见的包括两种:DB上的配置表、配置中心。如果公司没有统一的配置中心,那么最简单的动态修改配置的方式莫过于把配置放置在DB上。相信大部分的开发都使用过或者遇到过。

  配置中心是最适合集中化管理配置、动态修改配置的地方。常见的配置中心都会提供管理配置后台、实时推送配置、分环境管理配置、配置版本管理等。笔者目前就在开发一款开源的配置中心系统。

  集中管理配置、全方位管理配置

  动态修改配置、实时推送、更新配置

  配置更加灵活,例如可以分环境、集群以及灰度发布等

  需要依赖数据库或者配置中心,成本高

  经常需要变更的配置

  配置值每个环境不一致

  不希望配置值随着代码一起发布,例如开源项目中的某些配置

  启动参数(JVM属性)

  JVM属性主要是应用运行的JVM进程相关的属性,比如java.class.version、java.class.path等Java相关的参数。在代码里,可以通过System.getProperty()获取参数值。 另外,可以通过在启动时指定-D参数来设置JVM属性。最常见的使用场景是用来解决不同环境需要配置不同的参数。例如作为中间件,依赖的外部系统越少越好,如果不依赖配置中心,那么就可以通过这种方式来实现不同环境配置不同的参数,例如每个环境的数据库连接串不一样。 另外需要提到的是maven打包参数。

  相比于-D运行时参数,maven打包参数是在编译时设置配置属性,maven会获取打包参数然后替换掉配置文件里的placeholder。假设一个可运行的jar包,只需要在打包的时候传入参数值,打出来的jar包就可以到处运行了,如果不这么做,那么需要每次运行的时候指定参数,成本太高。使用方式则是在mvn package 时指定-D参数。 新手很容易混淆这两种参数。换个角度看-D是命令行参数。

  以非常小的代价就可以达到运行时指定特殊参数值

  启动运行项目需要设置启动参数,增加使用成本

  适合中间件类系统,不推荐业务系统使用(业务系统用配置中心解决此类场景)

  增加统一运维成本

  操作系统参数

  操作系统参数一般是只读的,当然也可以设置。例如前面提到的server.properties文件里的env参数,其实也可以作为系统参数,但是不建议这么做。

  配置的好处显而易见,但是我们在工作中经常会遇到这种情况。拿到一个项目,看到乱七八糟的配置无从下手,项目中使用的框架、中间件配置风格更不相同,更头疼的是配置项如果不了解框架的基础上很难理解。

  导致的结果就是如果不复制、粘贴配置,手写配置基本上很难写对。 验证这种情况最简单的方式就是不复制其它项目的配置,手动搭建一个新项目。我相信绝大多数的人都难以做到。

  片面的说学习一个框架其实是在学习这个框架的API和配置参数。如果你非常熟悉一个框架的配置,那么你对框架的使用就得心应手了。当然,知道框架的原理也非常重要。 说这么多,只想说明项目的配置真的非常重要,更好的管理、规范配置更加重要。

  对于框架、中间件开发者来说,配置应该越少越好,增加一个配置对于使用者使用成本就会大大提高。如果配置很多,那么你的框架基本上就是很难用了。 Spring一直是Java界最权威的框架体系,最新的Spring Boot框架的配置就非常少,一眼看上去非常舒心。

  Spring现在倡导减少配置文件,例如Spring早期版本的xml配置其实是很繁琐的。新的Spring更多的配置放置在代码中,利用注解以及API方式配置。Servlet最新版本也不需要web.xml文件了。

  说明一个道理: 大道至简?

  近期热文推荐:

  1.1,000+ 道 Java面试题及答案整理(2022最新版)

  2.劲爆!Java 协程要来了。。。

  3.Spring Boot 2.x 教程,太全了!

  4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!

  5.《Java开发手册(嵩山版)》最新发布,速速下载!

  觉得不错,别忘了随手点赞+转发哦!

  以上就是项目里的各种配置,你都了解吗?(项目里的各种配置,你都了解吗)的详细内容,想要了解更多 项目里的各种配置,你都了解吗?的内容,请持续关注盛行IT软件开发工作室。

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

留言与评论(共有 条评论)
   
验证码: