首页 文章 精选 留言 我的

精选列表

搜索[Spring Framework],共10000篇文章
优秀的个人博客,低调大师

《Spring Boot Flyway 实战手册》第5招 生产故障处理——搞定 checksum、repair、baseline 和失败迁移

## 01、痛点 凌晨两点,订单表新增字段的变更脚本在生产库执行到 V9 时挂了,`flyway_schema_history` 里躺着一行 `success=0`。开发同学第一反应是执行 `flyway repair`,我赶紧拦住。为什么?因为 repair 用错地方,可能把版本链推向更难恢复的深渊。 我是老李,在数据库运维和后端架构的边界上摸爬了多年。见过太多因为一个小小迁移失败,最后演变成全表数据核对、甚至回滚整库的血案。现在微服务和持续交付越来越普遍,数据库 schema 变更的频率远高于过去,但大部分团队对 Flyway 这类工具的“失败现场”仍然缺乏标准处置流程。今天我们就从头梳理一次:当迁移失败发生时,如何科学地定位、修复并避免二次事故。 ``` 迁移失败 ──> 慌张执行 repair ──> 版本链错乱 ──> 更难恢复 │ └──> 正确姿势:先分析 flyway_schema_history,再决定前滚或回滚 ``` ## 02、是什么 先厘清几个关键概念。 Flyway 是基于“版本化迁移”思路的数据库变更管理工具。每次变更被定义为一个带版本号的脚本(如 V9__add_order_remark.sql),执行成功后会在 `flyway_schema_history` 表中写入一条记录,包含版本号、描述、脚本 checksum、执行时间等信息。这个 checksum 是脚本内容的哈希,用来保证版本内容一旦执行过就不能被任意修改。 `repair` 操作的真实用途,是修复 `flyway_schema_history` 表本身的不一致,而不是修复业务表的数据。例如,当一个已经成功执行的迁移脚本被后人修改,导致 checksum 不匹配时,repair 会更新历史记录中的 checksum。它不会倒回业务表结构,也不会回滚已执行的 SQL。很多人把 repair 当成“重试”或“恢复”按钮,这是一个严重误解。 `baseline` 则是在一个已有大量业务表的老库上,让 Flyway 从某个版本开始接管后续变更。它会在历史表中插入一条 baseline 记录,版本一般设为当前最大版本或指定版本,之前的历史一概不纳入管理。 `Forward Migration` 指的是“向前修复”思想:当一个变更失败后,优先考虑在原版本基础上继续往前推出一个修复脚本(例如 V10 修复 V9 未完成的部分),而不是执行自动回滚。生产环境的数据一旦写入,回滚往往意味着数据丢失和逻辑不一致,因此“自动 rollback”不应作为主要方案。 ``` Flyway 核心对象 ─────────────────────────────── 迁移脚本 V1..Vn │ 执行 ▼ flyway_schema_history │ 记录 ├─ version ├─ checksum ├─ success └─ description ``` ## 03、为什么 为什么看到 checksum mismatch 不能第一时间直接 repair?因为 checksum 不匹配往往意味着“有人改了历史脚本”。如果此时直接 repair,Flyway 会把历史记录的 checksum 更新为当前文件的内容,看起来“绿了”,但已经应用过的 SQL 逻辑和当前脚本逻辑可能已经不同。比如 V8__create_order.sql 曾经成功创建了 order 表,后来有人把该文件改成新建一个 customer 表。如果直接 repair,Flyway 会认为 V8 内容无误,但真实数据库中并没有 customer 表,后续迁移也可能在错误假设下继续执行。正确做法是:先搞清楚为什么 checksum 变了——是误改、误提交,还是有意调整?如果是误改,应该还原脚本内容,而不是 repair。只有确认“脚本内容本身没问题,只是历史记录需要同步”时,才考虑 repair。 baseline 的作用也容易被误用。对一个已有几十张甚至几百张业务表的老系统,第一次引入 Flyway 时,不能直接执行 `flyway migrate`,因为 Flyway 会尝试从 V1 开始执行,看到数据库里已存在同名表会报错或冲突。正确步骤是先确定一个版本号(比如 V100),在该版本执行 baseline,让 Flyway 知道“以前的历史我不管了,从 V101 开始由我接管”。这之后新增的迁移脚本版本必须大于 baseline 版本。 结构漂移更是危险的“隐形炸弹”。DBA 或开发人员手动在数据库上添加了字段、修改了索引,但没有同步更新 Flyway 脚本,导致“真实数据库结构”和“Flyway 历史记录”不一致。下一次执行迁移时,可能因为“表已存在”“字段已存在”而失败,或者更糟糕的是,Flyway 在错误的结构假设上执行新脚本,造成数据问题。 大表 ALTER TABLE、锁表、长事务和批量数据迁移的风险也必须正视。几千万行的订单表新增字段,如果直接执行 `ALTER TABLE ... ADD COLUMN`,在 MySQL 的某些版本和引擎下可能锁表,阻塞所有写入,导致订单无法下单。长事务会进一步加剧锁等待,甚至把数据库拖垮。批量数据迁移如果一次性更新全表,会产生巨量 binlog 和主从延迟。 ``` checksum mismatch ──直接 repair──> 掩盖问题 └─正确──> 分析原因:误改就还原,确认改正确才 repair 已有业务表 ──直接 migrate──> 冲突 └─正确──> 先 baseline,再接管后续变更 大表 DDL ──直接 ALTER──> 锁表、业务中断 └─正确──> pt-osc / gh-ost / 分步操作 ``` ## 04、架构 Flyway 的整体架构并不复杂,但需要理解它的状态机。核心就是读迁移脚本 -> 比对历史表 -> 决定执行哪些 -> 写入结果。历史表 `flyway_schema_history` 的字段一般包括 `installed_rank`、`version`、`description`、`type`、`script`、`checksum`、`installed_by`、`execution_time`、`success`。 一个失败的迁移会在表中留下 `success=0` 的记录。后续再执行 `migrate` 时,Flyway 会先检测到这条失败记录,如果没有处理,可能拒绝继续。这时很多人的第一反应是删除失败记录或执行 repair。但正确的做法是先读这条失败记录,弄清楚它在执行哪条 SQL 时失败,失败的具体错误是什么,再决定修复手段。 ``` ┌─────────────────────────────┐ │ Flyway 引擎 │ └──────────────┬──────────────┘ │ 1. 读取迁移脚本 ▼ ┌─────────────────────────────┐ │ 按版本排序,过滤已应用记录 │ │ 比对 checksum / version │ └──────────────┬──────────────┘ │ 2. 执行待应用迁移 ▼ ┌─────────────────────────────┐ │ 执行 SQL / Java 迁移 │ │ 成功:写入 success=1 │ │ 失败:写入 success=0 │ └─────────────────────────────┘ │ ▼ ┌─────────────────────────────┐ │ flyway_schema_history │ └─────────────────────────────┘ ``` 这张图的关键在于:历史表是“账本”,业务表是“实物”。账本和实物必须一致,否则后续迁移全部建立在错误认知上。所以排查时先看账本,再核对实物。 ## 05、实战 下面通过几个模拟实验,把理论知识变成肌肉记忆。 ``` 实验路线图 V9失败 → 分析失败记录 → checksum mismatch → baseline → 结构漂移 → 大表DDL → Forward Migration → 应急SOP ``` **实验一:故意编写错误 V9 SQL,制造 Migration Failed** 假设当前 Flyway 已执行到 V8,现在新增一个 `V9__add_order_remark.sql`,内容如下: ```sql ALTER TABLE orders ADD COLUMN remark varchar(255) DEFAULT NULL; ``` 但我们故意把表名写错: ```sql ALTER TABLE orderx ADD COLUMN remark varchar(255) DEFAULT NULL; ``` 执行 `flyway migrate`,会报类似 `Table 'db.orderx' doesn't exist`,然后在 `flyway_schema_history` 里留下 `success=0` 的记录。此时查询历史表: ```sql SELECT installed_rank, version, description, success, checksum FROM flyway_schema_history WHERE version = '9'; ``` 你会看到 `success` 为 0。注意,`checksum` 列仍会记录这个脚本的 hash,这是关键。不要删除这条记录,也不要立刻 repair。先查看数据库里 `orders` 表是否还被修改过?本例中 SQL 没有执行成功,`orders` 表不变。于是我们可以直接修复 V9 脚本内容(把表名改成 `orders`),然后再次执行 `migrate`。Flyway 会检测到 V9 处于失败状态,并且 checksum 与当前文件不同,可能会报 checksum mismatch 或直接尝试重新执行(取决于配置)。通常需要先清理失败记录。但更稳妥的做法是:确认 V9 没有部分执行成功后,手动删除该失败记录,或使用 `flyway repair` 同步 checksum 后再执行。但注意:这里 repair 是同步 checksum,因为脚本内容已经修正,历史记录的 checksum 需要更新,这样才合理。这正是 repair 的适用场景之一:脚本内容确实需要修正,且修复后需要让历史表认识新 checksum。 **实验二:分析 flyway_schema_history 中的失败记录** 失败记录的信息非常丰富。除了 `success=0`,还要关注 `execution_time`(执行耗时)、`script` 名称、`description` 等。如果脚本是 Java 迁移,还要看错误堆栈。关键是:判断失败点是在 SQL 执行之前还是执行过程中。如果 SQL 含有 DML(数据操作),可能已经部分写入,此时不能简单重试,需要考虑数据幂等性。 例如一个迁移脚本包含两条语句: ```sql UPDATE orders SET status = 'ARCHIVED' WHERE created_at checksum -> repair -> baseline -> Forward Migration -> 结构漂移 ``` **延伸阅读** - Flyway 官方文档:https://flywaydb.org/documentation/ - 在线改表工具:Percona Toolkit 和 gh-ost 的官方使用指南 - 数据库大表变更最佳实践:各大云厂商数据库团队发布的 DDL 风险控制文章

优秀的个人博客,低调大师

Java 通用代码生成器光,电音之王尝鲜版十,Spring Boot 3.4.0 PostgreSQL 演示

Java通用代码生成器光,电音之王尝鲜版十,SpringBoot3.4.0 PostgreSQL示例生成演示 Java通用代码生成器光,电音之王尝鲜版十公布了最新介绍视频,详细讲解了使用电音之王尝鲜版十的boot3技术栈生成SpringBoot3.4.0 PostgreSQL的示例的详细过程。并对前端和后端代码生成物进行了代码讲读。视频请见: https://www.bilibili.com/video/BV1keqaY8EXG/ Java 通用代码生成器光已发布 2.4.0 电音之王 TechnoKing 版本尝鲜版十。此版本支持新的技术栈 boot3,此技术栈支持 springboot3.4.0,POI 5.3.0,Shiro 1.13.0, Mybatis 3.0.3 等一系列新版本,同时仍然兼容原先的 sbmeu,smeu,msmeu 三个技术栈。更多缺陷修复,更多测试。已接近 Beta 质量。请部署在 Tomcat9 的 webapps 目录下。可以从源码建构。介绍视频请见:https://www.bilibili.com/video/BV1MRqDYfEZV/ Boot3 技术栈将 sbmeu 技术栈丝滑升级至 SpringBoot 3.4.0 最新版,并升级了其他组件。从此,您可以使用 SpringBoot 3.x 完成功能,同时,光保留了原来 SpringBoot 2.2.2 的 sbmeu 技术栈,您仍然可以使用此技术栈,如果您需要的话。 Java 通用代码生成器光,电音之王尝鲜版十将强大的生产力赋能广大程序员。无论是新开发的软件还是通过遗留数据库反射以再次开发的遗留项目,您都可以使用动词算子式通用代码生成器的强大生产力大大加速研发速度。 项目地址:https://gitee.com/jerryshensjf/LightSBMEU 二进制发布版地址:https://gitee.com/jerryshensjf/LightSBMEU/attach_files Java通用代码生成器光 新版本发布 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版十。支持新的技术栈boot3,此技术栈支持springboot3.4.0,POI 5.3.0,Shiro 1.13.0, Mybatis 3.0.3等一系列新版本,同时仍然兼容原先的sbmeu,smeu,msmeu三个技术栈。更多缺陷修复,更多测试。已接近Beta质量。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版九。界面美化,完善了数据库自动反射功能,完善了前端代码生成,完善了枚举和哑数据模式。更多缺陷修复,更多测试。已接近Beta质量。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版八。完善支持数据库自动反射功能和多对多候选功能。完善了元数据和数据编辑器。在尝鲜版七基础上有多处缺陷修正和功能增强。 补充了一些缺失的功能。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版七。支持数据库自动反射功能和多对多候选功能。完善了元数据和数据编辑器。在尝鲜版六基础上有多处缺陷修正和功能增强。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版六。支持枚举和哑数据模式。支持Nodejs 21,18和14。消除了95%的前端EsLint编译警告并隐藏全部。在尝鲜版五基础上有多处缺陷修正和功能增强。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版五,已发布。 此版本在尝鲜版四基础上有错误修正。 电音之王支持日期与日期时间,支持修改自己的资料和密码。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版四,在尝鲜版三基础上有错误修正。 电音之王支持三大部分生成功能群,即高级定制功能群,部分生成功能群,和自动生成差异版本功能群,即支持上传同一项目的两个模板,自动生成差异版本,支持多次,全程使用代码生成器。可以从源码建构。支持Go语言和Rust语言兼容性。 电音之王也支持三大变形功能群,即动态椰子树功能群,动词否定功能群和字段否定功能群。非常强大,非常方便。 电音之王支持四种数据导出格式,即Excel,PDF,PPT和Word。 电音之王支持三种复杂版面,即父子表,树表和树父子表。 电音之王支持三种图形报表。并支持三种图表类型:折线图,柱状图和饼图。 版本与简介 本代码生成器最新版是Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版十。支持新的技术栈boot3,此技术栈支持springboot3.4.0,POI 5.3.0,Shiro 1.13.0, Mybatis 3.0.3等一系列新版本,同时仍然兼容原先的sbmeu,smeu,msmeu三个技术栈。更多缺陷修复,更多测试。已接近Beta质量。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版九。界面美化,完善了数据库自动反射功能,完善了前端代码生成,完善了枚举和哑数据模式。更多缺陷修复,更多测试。已接近Beta质量。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版八。完善支持数据库自动反射功能和多对多候选功能。完善了元数据和数据编辑器。在尝鲜版七基础上有多处缺陷修正和功能增强。 补充了一些缺失的功能。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版七。支持数据库自动反射功能和多对多候选功能。完善了元数据和数据编辑器。在尝鲜版六基础上有多处缺陷修正和功能增强。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版六。支持枚举和哑数据模式。支持Nodejs 21,18和14。消除了95%的前端EsLint编译警告并隐藏全部。在尝鲜版五基础上有多处缺陷修正和功能增强。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版五,在尝鲜版四基础上有错误修正。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版四,在尝鲜版三基础上有错误修正。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版三。在尝鲜版二基础上有增强和修正。 Java通用代码生成器光2.4.0电音之王TechnoKing版本尝鲜版二,在尝鲜版基础上有错误修正。 Java通用代码生成器光2.3.0文明版本Beta11版。可以从源码建构。是光2.3.0文明版本的最后一个版本。 Java通用代码生成器光2.3.0文明版本Beta10版。可以从源码建构。支持Go语言和Rust语言兼容性。重新格式化了所有的SGS2模板。 Beta8版修复了没有登录模块的项目的代码生成的缺陷。所有示例皆可以顺利生成代码生成物。 Beta7版彻底排查修复了前端权限系统,并更新了文档,已接近候选(RC)版质量。 Beta6版彻底检查和增强了弹性登录模块,并检查修复了Oracle代码生成物。 Beta5版全面增强了模版向导功能的界面操作,并全面检查修复了English语言版本。 Beta4是个修复与增强版本,修复了前端登录权限系统和复杂版面功能。 Beta版有文档更新,并支持可以设置的SQL脚本的表名和字段名的中文注释。 尝鲜版19在尝鲜版18基础上有功能改进。 尝鲜版18完善了前端复杂版面功能,至此,文明版本所有规划功能均已实现。 尝鲜版17修复了一些运行时错误。 尝鲜版15支持图形报表,使用了Echarts图形库。支持折线图,柱状图和饼图三种图形报表,支持原始数据和累加数据两种数据格式。 尝鲜版14是一个缺陷修复版本,修复了尝鲜版8以来的所有跨域和功能缺陷。 尝鲜版8版本最大特色是一键生成前端和后端,共享一套登录权限系统,session,token等信息不需要人工设置,默认生成,前端是基于Vue的,您可以使用此独立Vue前端管理系统。等前端项目生成完成复杂版面和报表功能后,即可进入Beta阶段。 尝鲜版6的Excel模板向导界面全面支持新功能。等前端界面完全支持新功能后即可进入Beta阶段。 光2.3.0文明尝鲜版5添加了PPT数据导出功能。 文明版本新增ShiroAuth弹性登录模块,使用Apache Shiro权限框架。新增三种复杂版面。包括父子表,树表和树父子表。新增三种报表。使用Echarts报表框架。包括报表,带数据网格的报表和计划与执行对比报表,带双数据网格。显著增强编译错与编译警告功能,增强更准确的错误信息和域对象簿记检查功能。请在本站附件处下载二进制发行版。 其中ShiroAuth模块。使用Apache Shiro权限框架。本弹性登录模块具有强大的变形能力。您可以指定User,Role,Privilege的具体对象。系统会严格校验,并生成相应的Shiro登录模块。完全无需人工编程。注意,Privilege对象的数据由系统生成,您无需配置。Role会自动增加admin和user两个Role。admin和user都自动关联所有权限。但是admin可以访问User,Role,Privilege三个对象,而user不行。系统会在User表中新增admin和jerry两个用户。其中amdin的角色是admin。jerry的角色是user。用户的密码您可以以明文设置。系统自动把密码转化为密文。若您未设置。amdin的密码为admin。而jerry的密码为jerry。 项目图片 新的大版本号 现在新的大版本号是光2.4.0 电音之王TechnoKing 短名TK 百度话题 #通用代码生成器# 介绍视频 电音之王尝鲜版十,介绍视频请见 https://www.bilibili.com/video/BV1MRqDYfEZV/ 电音之王尝鲜版九,介绍视频请见 https://www.bilibili.com/video/BV1T6zrYNEMD/ https://www.bilibili.com/video/BV1gUBRYVEKu/ 电音之王尝鲜版八,介绍视频请见 https://www.bilibili.com/video/BV1Q1WjeSEwW/ 电音之王尝鲜版七,介绍视频请见 https://www.bilibili.com/video/BV1MLeTe1EmN/ 电音之王尝鲜版六,介绍视频请见 https://www.bilibili.com/video/BV1Cf421Z7PF/ https://www.bilibili.com/video/BV1yD421j7UP/ 2.4.0 电音之王尝鲜版五,介绍视频请见 https://www.bilibili.com/video/BV1Wh4y1r7Pa/ 2.4.0 电音之王尝鲜版四,介绍视频请见 https://www.bilibili.com/video/BV1sx4y1X7XM/ 2.4.0 电音之王尝鲜版三,介绍视频请见 https://www.bilibili.com/video/BV1394y1q744/ 2.4.0 电音之王尝鲜版二,支持日期和日期时间,支持修改自己的资料和密码,支持三大部分生成功能群,支持上传同一项目两个版本的Excel模板生成差异版本,视频请见: https://www.bilibili.com/video/BV1W8411Z7MK/ 2.3.0 文明Beta10版,从源码构建,视频请见: https://www.bilibili.com/video/BV1AY4y197dB/ 三大变形功能群,即动态椰子树功能群,动词否定功能群和字段否定功能群,是动词算子式代码生成器的强大功能,使它可以适配多种代码规范和各种场景。现在 Java 通用代码生成器光 2.3.0 文明 Beta8 版,发布了三大变形功能群介绍视频上下集。请见: 上集:https://www.bilibili.com/video/BV1pg411n7Mg/ 下集:https://www.bilibili.com/video/BV18D4y1879F/ Beta7版 B站介绍视频 https://www.bilibili.com/video/BV1gD4y147oK/ Beta6版 B站介绍视频 https://www.bilibili.com/video/BV1he4y1a7VT/ Beta4版 B站介绍视频 https://www.bilibili.com/video/BV1Jm4y1A7nW/ Beta2版 B站介绍视频 https://www.bilibili.com/video/BV1H44y1u75P/ Beta版 B站介绍视频 https://www.bilibili.com/video/BV1z34y1Y77Q/ B站技术直播间 https://live.bilibili.com/23023356 二进制发行版下载 https://gitee.com/jerryshensjf/LightSBMEU/attach_files 截图 生成界面截图 模板向导生成界面 上传生成界面 自动生成差异版本生成界面 新功能截图: 前端复杂版面:树表 图形报表: 柱状图: 折线图: 、 PPT数据导出功能 登录 错误 登录后 新功能Excel模板页签 新功能,复杂版面,树表 新功能,报表 独立前端页面截图 登录页 内页 源码编译用户指南 通用代码生成器已经支持自己编译源码,我已把原来缺的前端代码生成器的jar包上传。支持大家自行编译源码。 需要注意的是,现在我的开发平台是Fedora 37上的openjdk 17。所以大家编译源码最好使用openjdk17。编译好的war包运行在apache tomcat 9.0上。 已有jdk8的用户报告默认下载的代码生成器war包在他的平台上无法运行。您如果遇到类似问题请报告。我的电子邮件是:jerry_shen_sjf@qq.com 附openjdk 17下载地址: https://jdk.java.net/java-se-ri/17 架构变化 从光2.3.0 文明尝鲜版2开始,光使用Maven管理jar依赖,方便您从源码构建代码生成器。同时开始支持Tomcat9。 使用前端功能的注意事项 由于图片文件比较大,原来前端使用cnpm instll安装类型,npm run dev运行有所改动,改为先使用npm install --registry=https://registry.npm.taobao.org安装类库,出错后使用cnpm install安装类库, 使用node --max-http-header-size=1000000 ./node_modules/.bin/webpack-dev-server --inline --progress --config build/webpack.dev.conf.js 运行系统。 您也可以从安传好的本系列代码生成器的前端项目中拷贝node_modules目录,即可运行前端。 动词算子式代码生成器的应用场景 快速原型:项目或演示场景使用。可以生成具有关系型数据库后端,使用MyBatis的数据库后端和Vue和ElementUI前端。 项目前期:如果项目和动词算子式代码生成器兼容,可以使用动词算子式代码生成器执行项目前期的自动化生成。 源码研读者注意事项 无垠式代码生成器第一个完整版本源码,有兴趣可以抄写一下: https://gitee.com/jerryshensjf/InfinityGPGenerator_0_6_5 相关技术视频: https://www.bilibili.com/video/BV1fX4y1u7Bn/ https://www.bilibili.com/video/BV1rv41187qY/ https://www.bilibili.com/video/BV1xv41187cA/ https://www.bilibili.com/video/BV1t64y1v7WA/ 询问AI

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

优质分享App

优质分享App

近一个月的开发和优化,本站点的第一个app全新上线。该app采用极致压缩,本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

用户登录
用户注册