中间件标准化落地

在一个技术栈为 Java、各业务团队“各自为伍”的组织里，如果没有中间件团队，公司其实是在支付一种隐形的、昂贵的**“混乱税”**。

与其让 10 个团队研究如何优化 Kafka 消费堆积，不如由中间件团队提供一个性能压测过、参数调优过的全量 SDK。

这些隐性技术债堆积，“没人认领”的公共问题，每个团队都觉得自己“暂时这样没问题”，但所有团队的“暂时”叠加在一起，构成了公司层面的技术债务，最终在关键业务大促、双11等节点集中暴雷

# 概况

协作层面的现状：

现象	具体表现
联调困难	A团队用RocketMQ 4.9发送的消息，B团队用RocketMQ 5.1的消费端因消息结构/Header解析方式差异出现异常；双方花费半天排查才发现是版本问题
升级动力缺失	任何一个团队都不愿意承担“升级中间件版本”这种“吃力不讨好”的工作，因为收益是全局的，风险是自己的；久而久之，整个公司的中间件版本落后
故障归属扯皮	线上出现Redis连接超时，A团队说“我们用的Lettuce 6.2没问题”，B团队说“我们用的Jedis 4.3也没问题”，最后发现是Redis服务端版本与某个客户端版本存在已知bug，但没人能定论
公共组件重复造轮子	三个团队各自封装了“Redis工具类”，有的用Fastjson序列化，有的用Jackson；缓存Key前缀、异常处理策略各不相同，无法跨团队复用

运维与稳定性层面的现状：

现象	具体表现
故障影响面不可控	某中间件暴露安全漏洞（如Log4j、Fastjson），各团队独立排查、独立升级，有的升级一半没上线，有的不知道漏洞存在，导致漏洞窗口期拉长
监控告警碎片化	A团队用SkyWalking，B团队甚至没有链路追踪；线上出问题时，无法端到端串联调用链，排查时间成倍增加
资源浪费	每个团队独立申请中间件集群：三个团队各建一套Redis集群（都是主从1G规格），总成本远高于一套共享集群，且资源利用率极低
中间件版本“僵尸化”	某服务上线后不再维护，其依赖的Elasticsearch 6.8与公司新推的8.x集群无法打通；该服务因“不敢动”成为架构升级的拦路石

核心诉求：快速交付、低成本运维、避免踩坑、留有扩展空间。

# 落地过程

# 阶段一. 现状盘点与基线建立

# 1.1 建立中间件资产清单

动作：通过CMDB、各项目pom.xml扫描、运维平台，梳理全公司所有应用使用的中间件类型、版本、部署方式。访谈各业务团队TL、核心研发，收集当前最困扰的问题（联调困难、故障频发、升级困难等），优先级排序核心基础组件。

技术方案：编写脚本（Python/Shell）遍历Git仓库，解析pom.xml，提取所有的二方库生成可视化报表

# 1.2 制定标准化基线

结合社区活跃度、公司技术栈、未来规划，确定每类中间件的唯一推荐版本及可选版本范围（通常只允许一个版本）

高优先级：注册/配置中心（直接影响服务发现）、消息队列（跨团队异步通信）、缓存（高频使用且故障影响大）。
中优先级：指标收集、日志采集、链路追踪、告警监控。
低优先级：相对独立的工具类库（如JSON处理）

核心的中间件如下：

旧组件	新组件	说明
	JDBC-MySQL 8.0.32+	关系数据库
SpringMVC	Spring Boot 3.2.x	基础框架
metaq	RocketMQ 4.9.x	消息队列
yard	Apollo 1.9.2	配置中心
kiev	Dubbo 3.x	rpc框架
elasticJob	xxl-job 2.x	分布式定时任务框架
jdk1.7 / jdk1.8_151	jdk1.8_462 / jdk11	jdk版本
jetty7.4.x	jetty 9.4	jetty版本
	zookeeper 3.6.x	注册中心
	sentinel 1.9.x	流控
	MyBatis-Plus 3.2.x	ORM框架
	Jedis 7.2.x	Redis客户端工具
	guava 32.1.x	Google开源工具包
	slf4j+logback	日志切面及框架
	云OSS	对象存储
	knife4j 3.0	api文档
	one-agent	Java探针形式可观测
	Prometheus + 夜莺	监控、告警

以上部分中间件已在团队使用，但是版本较低，而且不少组件已经出现新的解决方案，做为核心的中间件，必须锁定关键的版本，其他允许差异化，逐步收敛。

如何选择基础组件及其版本？

1、通过maven中央仓库可知道最新的版本、是否存在漏洞、以及使用最多的版本：

作为选择，我会优先考虑使用被引用次数最多且没有漏洞的版本。

2、社区活跃、github star数量超过 10k（最好能入选Apache项目）

比如rpc框架来说，国内使用Dubbo远比Grpc更好维护、友好，社区比Brpc更活跃。

# 阶段二：构建标准化技术基础设施

# 2.1 统一依赖管理（BOM）

使用parent pom约定所有基础组件版本：

<dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-dependencies</artifactId>
                <version>${spring-boot-dependencies.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies> 
</dependencyManagement>

使用Maven BOM管理所有核心中间件客户端及框架版本，

配套动作：
- 发布BOM到公司私有仓库（Nexus/Artifactory），版本号与公司基线同步。
- 要求所有新项目必须引入该BOM，并禁止在业务项目中单独声明版本号。

这一步是标准化的基石，后续自研的javaagent也是基于特定版本做切面。

# 2.2 打造标准化脚手架（Archetype/Starter）

技术方案：
- Archetype：提供Maven archetype，生成符合标准的基础项目结构，包含：
  - 统一application.yml模板（预先配置Apollo地址、Redis连接池、RocketMQ Producer/Consumer等）。
  - 集成统一的日志配置（logback-spring.xml，输出格式到stdout）。
  - 集成健康检查、监控指标暴露（Micrometer + Prometheus）。
- 自定义Starter：封装常用中间件的最佳实践，例如：
  - redis-starter：公共Redis集群、统一Key前缀、序列化方式（Jackson2Json）、异常降级策略。
  - rocketmq-starter：封装消息发送模板，消息体规范。
  - log-starter：统一日志切面Slf4j，统一日志路径、存储位置
  - swagger-starter：统一暴露 API文档
  starter 通过配置中心，约定公共中间件服务地址、配置、环境标识。

# 2.3 统一中间件部署与运维平台

技术方案：
- 配置中心：收缩所有团队的公共配置中心平台，比如官网团队有一套Apollo，游戏团队也有一套Apollo，现在统一由中间件团队提供，且项目名称必须保持与CMDB一致
- 分布式任务框架：同上
- 消息队列：搭建RocketMQ集群，提供Topic/Group申请流程（通过内部平台或工单），自动创建并配置ACL
- Redis：提供统一的Redis集群及版本，通过内部平台申请实例，自动分配db索引或前缀。同时非核心业务只能使用公共Redis集群
- 监控：部署统一的Prometheus + 夜莺，所有应用必须接入自研的采集one-agent；

收敛所有中间件集群，统一管理所有集群信息，根据各可用区分配：

基础中间件实例管理

引入工单系统，统一中间件申请步骤（如Topic等信息），

MQ topic申请，与项目绑定

# 2.4 统一CI/CD

目前业务的构建、发布必须是通过Jenkins构建并推送到Jfrog，发布平台再拉取Jfrog构建产物进行发布。

不同的业务部署方式也不一样，有Tomcat、Jetty war形式，也有springboot可执行jar形式，甚至还有 .gz 和 .rpm形式的。

技术方案：

发布平台集成Maven构建方式，构建产物，直接使用Docker打成镜像
提供标准的Ubuntu22.04基础镜像，标准的jdk1.8 和 jdk11 两个版本，同时集成标准的工具包
发布平台统一把应用名称、可用区标识等信息到环境变量

提供标准的Dockerfile镜像模版：

# 标准系统镜像，包含常用工具包curl、ping ,解决乱码、时区日期等问题
FROM registry.meizu.com/base/jdk1.8:latest

# 构建出的产物路径（xxx.jar）
COPY ./metrics-dashboard/target/metrics-dashboard.jar  /metrics-dashboard.jar

# javaagent参数
ENV JAVA_OPTS_ONE_AGENT="-javaagent:/data/one-agent.jar"

# 自定义jvm参数
ENV JAVA_OPTS_CUSTOM=""

# 跟用户确认启动命令 
ENTRYPOINT java  ${JAVA_OPTS_CUSTOM} ${JAVA_OPTS_ONE_AGENT}  -jar /metrics-dashboard.jar