项目编译打包部署最佳实践

发表于2026-04-09|更新于2026-04-09|云原生

|浏览量:

运行的环境使用 JVM 参数方式，而不是写死在配置文件里面的：

打包jar 的Maven 编译插件

需要指定对应的 finalName，就是生成的 jar 的名字：

打包的时候避免使用测试用例

文章作者: 褚成志

文章链接: https://www.chucz.asia/2026/04/09/%E9%A1%B9%E7%9B%AE%E7%BC%96%E8%AF%91%E6%89%93%E5%8C%85%E9%83%A8%E7%BD%B2%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源褚成志的分享站！

最佳实践 DevOps 部署

相关推荐

持久化配置最佳实践

RDB 持久化配置手动触发RDBsave：会阻塞当前 Redis 服务器，直到持久化完成，线上应该禁止使用 bgsave：该触发方式会 fork 一个子进程，由子进程负责持久化过程，因此阻塞只会发生在 fork 子进程的时候定时触发RDB根据我们的 save m n 配置规则自动触发从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave 执行 shutdown 时，如果没有开启 aof，也会触发 AOF 持久化配置 AOF 重写：当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF文件的内容压缩，只保留可以恢复数据的最小指令集触发机制：Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64MB 时触发 bgrewriteaof 可以手动触发重写原理：将整个内存中的数据库内容用命令的方式重写了一个新的 AOF 文件，这点和快照有点类似持久化数据恢复

消灭重复代码的最佳实践

代码重复本身不可怕，可怕的是漏改或改错。消灭重复代码，降低改动可能引入的风险。学习笔记：https://time.geekbang.org/column/article/228964 工厂模式 + 模板方法消除 if else 和重复代码假设要开发一个购物车下单的功能，针对不同用户进行不同处理：普通用户需要收取运费，运费是商品价格的 10%，无商品折扣； VIP 用户同样需要收取商品价格 10% 的快递费，但购买两件以上相同商品时，第三件开始享受一定折扣；内部用户可以免运费，无商品折扣。我们的目标是实现三种类型的购物车业务逻辑，把入参 Map 对象（Key 是商品 ID，Value 是商品数量），转换为出参购物车类型 Cart。原始代码12345678910111213141516171819202122232425262728//购物车@Datapublic class Cart { //商品清单 private List<Item> items = new ArrayList<>(); //总优惠 ...

自定义通用异常处理

生产级别的通用异常处理所有的异常都抛出，统一在表现层处理，其余直接抛出就好。 spring定义的错误响应方式如图所示。使用Java提供的异常类抛出的时候只可以传递string，所以需要自定义一个异常类，继承RuntimeException，抛出的时候同时包含信息和状态码新建通用异常处理类相当于aop里面的通知，起到拦截的作用，要做到通用，状态码不可以写死，这里的设计不对，后面会改进 src/main/java/com/deltaqin/common/advice/CommonExceptionHandler.java 12345678910111213141516171819package com.deltaqin.common.advice;import org.springframework.http.HttpStatus;import org.springframework.http.ResponseEntity;import org.springframework.web.bind.annot...

接口幂等方案

对于一个接口而言，无论调用了多少次，最终得到的结果都是一样的。幂等性的实现与判断需要消耗一定的资源，因此不应该给每个接口都增加幂等性判断，要根据实际的业务情况和操作类型来进行区分。在进行查询操作和删除操作时就无须进行幂等性判断。查询操作查一次和查多次的结果都是一致的，因此我们无须进行幂等性判断。删除操作也是一样，删除一次和删除多次都是把相关的数据进行删除（这里的删除指的是条件删除而不是删除所有数据），因此也无须进行幂等性判断。关键步骤每个请求操作必须有唯一的 ID，而这个 ID 就是用来表示此业务是否被执行过的关键凭证每次执行业务之前必须要先判断此业务是否已经被处理过第一次业务处理完成之后，要把此业务处理的状态进行保存，比如存储到 Redis 中或者是数据库中，这样才能防止业务被重复处理。前端拦截用户点击完“提交”按钮后，我们可以把按钮设置为不可用或者隐藏状态，避免用户重复点击。数据库实现数据库实现幂等性的方案有三个：通过悲观锁来实现幂等性开启事务实现原子操作 id 字段一定要是主键或者是唯一索引，不然会锁表，影响其他业务执行。通过唯一索引来实现...

日志放在拦截器还是过滤器

Filter过滤器是 Web 应用程序组件，可以在请求到达 Servlet 之前对其进行访问，也可以在响应信息返回到客户端之前对其进行拦截。 Filter 的接口方法： init：Serverlet 容器创建过滤器实例的时候调用 doFilter：拦截到达的请求，检查和处理Header的body的数据 destory：销毁过滤器，doFilter 中所有的方法超时之后，web 容器才会调用销毁链式调用： Interceptor拦截器是 AOP 的一种实现策略，用于在某个方法或宁段被访问前对它进行拦截，然后在其之前或之后加上某些操作。 Interceptor 的接口方法：preHandler、postHandler、afterCompletion HandlerInterceptor 的接口方法： preHandle：方法前置初始化操作，请求预处理，权限校验，返回Boolean postHandle：方法后置处理，Controller 调用之后，DispatcherServelet视图渲染之前处理 afterCompletion：请求处理完成，包括 DispatcherS...

分布式锁最佳实践

在单体的应用开发场景中涉及并发同步的时候，大家往往采用 Synchronized（同步）或者同一个JVM内Lock机制来解决多线程间的同步问题。在分布式集群工作的开发场景中，就需要一种更加高级的锁机制来处理跨机器的进程之间的数据同步问题，这种跨机器的锁就是分布式锁。超卖问题复现现象存在如下的几张表：商品表订单表订单item表 :::danger 商品的库存为1，但是并发高的时候有多笔订单。 ::: 错误案例一：数据库 update 相互覆盖直接在内存中判断是否有库存，计算扣减之后的值更新数据库，并发的情况下会导致相互覆盖发生： 123456789101112131415161718192021222324252627@Transactional(rollbackFor = Exception.class)public Long createOrder() throws Exception { Product product = productMapper.selectByPrimaryKey(purchaseProductId); ...

数据加载中