内部Pastebin工具14年支持历程:技术栈演进的经验教训
一款用于分享代码和日志的内部工具,类似于Pastebin,于2012年上线并持续运行了14年。最初,它只是一个简单的网页表单,用于保存“粘贴”内容,生成链接并自动删除过期条目。后来,我们添加了语法高亮、逐行评论、授权功能和文本标注功能。其核心价值在于本地部署,无需依赖外部服务。
该项目并未标榜独特性:这类解决方案很容易复制。关键挑战不在于创建,而在于长期支持,期间技术会过时、框架会消亡、用户期望会增长。
技术栈:Scala与Spring和Hibernate的结合
技术栈的选择基于可用性和兴趣:在经典的Spring-Hibernate-JSP架构上使用Scala而非Java。Scala 2.x编译为JVM字节码,但集成时暴露了兼容性问题。
- 注解和类扫描器:Spring和Hibernate错误处理了Scala字节码。例如Entity字段的问题:
@ManyToOne(fetch = FetchType.EAGER, cascade = Array(CascadeType.PERSIST, CascadeType.MERGE))
@JoinColumn(name = "owner_id")
private var owner: User = null
字段需要显式默认值。
- 数据类型、继承、枚举和注解:一系列不兼容问题,通过试错解决。
我们避免了NoSQL和文件存储:重启时数据丢失是不可接受的。Lucene用于索引,但在更新时导致重复。
构建系统:Maven而非sbt
2012年,sbt尚不成熟,IDE和CI集成较差。Maven提供了稳定性:支持SonarQube、多数据库和多servlet容器。
Maven在14年间的优势:
- 可预测的发布。
- 易于与生态系统集成。
- 配置变更最小。
sbt后来有所发展,但迁移并非必要——Maven从未让我们失望。
Compass搜索的消亡
Compass是Elasticsearch的前身,与Hibernate/Spring集成用于嵌入式搜索。到2014年,该项目消亡:作者转向了分布式ES。
后果:
- 对过时库的依赖破坏了更新。
- 支持废弃代码耗时5年。
- 迁移到Hibernate Search首次尝试未成功。
教训:监控上游项目活动。
Apache Tiles和JSP模板的问题
Tiles为JSP添加了模板组合功能,而基础技术仅限于include指令。每个页面都重复结构:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<!DOCTYPE html>
<html>
<head>
<c:import url="header.jsp" />
</head>
<body>
<%@include file="body.jsp"%>
</body>
<footer>
<jsp:include page="footer.jsp" />
</footer>
</html>
重构变得噩梦般困难。Tiles也消亡了,加剧了问题。
仓库和提交:14年在一个GitHub仓库中
业余时间开发导致提交不够理想。最近版本的代码已清理,项目稳定。公开访问简化了分叉和贡献。
关键要点
- 项目支持比开发更重要:技术过时速度超过期望。
- 基于可用性选择技术栈可行,但需要兼容性测试(Scala + Spring/Hibernate)。
- 废弃框架(Compass、Tiles)会拖累你:监控路线图。
- Maven在遗留项目中仍是稳定性的黄金标准。
- 用户数据至关重要,即使是临时工具。
总体而言,该项目说明了企业开发的现实——90%的努力用于维护。
— Editorial Team
暂无评论。