最近需要快速理解一个 Spring Boot、Spring Cloud 项目并准备借助 AI 新增一个项目。因为 Java 基础还不扎实我给自己定的目标不是短期内独立手写所有代码而是先达到三个标准能解释每个基础设施组件解决什么问题能在代码和配置中找到它的入口能和研发人员沟通也能判断 AI 生成的方案是否合理。我集中学习了 Docker、Docker Compose、Kubernetes、Kafka、RabbitMQ、OceanBase 和 Doris。最大的收获不是记住七套定义而是发现它们可以放进一张非常清楚的系统地图。一、先别背名词后端系统只是在解决三类问题第一类问题是应用怎样以一致的方式运行本地环境、测试环境和生产环境不能各装一套不同版本的 Java 与依赖。Docker 用镜像统一交付Compose 组织一台机器上的多个容器K8s 在集群中管理大量容器。第二类问题是服务之间怎样异步协作一次请求不可能永远同步等待所有下游。Kafka 保存可以被多个系统独立读取和重放的事件RabbitMQ 把需要处理的消息路由到合适的任务队列。第三类问题是数据怎样保存和使用订单、账户和库存要求事务准确报表和指标要求快速扫描大量数据。MySQL、OceanBase 偏前者Doris 偏后者。从这三个问题出发再看具体产品就不容易混乱。二、Docker、Compose、K8s从一个容器到整个集群1. Docker统一应用交付物Dockerfile 像一张配方说明基础镜像是什么、JAR 放在哪里、用什么命令启动。构建结果是镜像镜像运行后才是容器。FROM eclipse-temurin:21-jre WORKDIR /app COPY target/order-service.jar app.jar ENTRYPOINT [java, -jar, app.jar]一开始我把 Docker 理解成“把本地项目打包成可以直接运行的应用”这个方向没错但还要加上两个边界镜像是只读模板容器是运行实例容器中的临时数据可能随容器删除因此数据库等持久数据要放到 Volume。2. Docker Compose组织一台机器上的多个容器一个 Spring Cloud 项目可能同时依赖 Gateway、订单服务、MySQL 和 RabbitMQ。Compose 可以把它们写进一个 YAML一次启动整套本地环境。它最适合开发、联调、演示和简单单机部署。服务之间可以用服务名通信但depends_on主要表示启动顺序不代表数据库已经做好接收请求的准备。3. Kubernetes维护集群期望状态K8s 最重要的概念不是“多服务器部署”而是期望状态。例如我声明订单服务需要三个副本期望状态3 个 Pod 实际状态2 个 Pod 控制器动作再创建 1 个 PodDeployment 管理副本和发布Service 给变化的 Pod 提供稳定地址ConfigMap 和 Secret 承载配置探针判断应用是否存活、是否已经可以接收流量。因此可以这样记Docker运行一个容器 Compose组织一台机器上的多个容器 K8s在集群中持续维护容器化应用的期望状态三、Kafka 与 RabbitMQ事件档案和任务派送这是我学习过程中最容易混淆的一组。1. Kafka 更像可重放的事件档案生产者把事件追加到 Topic 的 Partition。消费者通过 offset 记录自己在分区中读到了哪里多个 Consumer Group 可以各自读取同一批事件。例如订单创建后OrderCreated ├── 风控消费组 ├── 积分消费组 ├── 推荐消费组 └── Doris 数据同步消费组如果 Doris 需要重建近七天的数据可以调整消费位置重新读取历史事件。这种需要保留、重放和多个下游独立订阅的场景通常更偏 Kafka。2. RabbitMQ 更像任务派送中心RabbitMQ 通常把消息发送给 Exchange再根据 Routing Key 和 Binding 路由到 Queue。消费者处理完成后发送 ACK消息随后从队列移除。例如支付成功 ↓ SendPaymentSms ↓ 短信队列 ↓ 某一个短信消费者处理 ↓ 成功 ACK多次失败进入死信队列需要灵活路由、任务确认、重试和死信处理的场景通常更偏 RabbitMQ。3. 不是“Kafka 能做什么、RabbitMQ 不能做什么”Kafka 也能在一个消费组内把任务分摊给多个消费者RabbitMQ 也能绑定多个队列实现发布订阅。两者存在能力重叠。真正的判断维度是消息是否需要保留和重放多个下游是否需要独立消费是否需要复杂路由任务是否强调 ACK、重试和死信处理四、我对 offset 最大的一次误解学习时遇到一道题优惠券已经发放但 Kafka offset 还没提交消费者突然宕机恢复后会发生什么我最初想到的是多节点备份和定时写入磁盘。这个回答混淆了两个层次Kafka Broker 的副本和磁盘负责保存消息Consumer 的 offset 负责记录读取进度。消息其实还在 Kafka 中。因为 offset 没有提交消费者恢复后会再次读到同一条事件于是可能重复发放优惠券。真正需要的是业务幂等。例如每个订单只允许领取一次某类优惠券可以使用UNIQUE(order_id, coupon_type)消费者再次收到消息时如果唯一记录已经存在就不再发券但仍把本次消费视为成功并提交 offset。还有一个容易忽略的并发问题不能只“先查询是否处理过再决定是否发放”。两个消费者可能同时查询都看到未处理。数据库唯一约束才是最后防线。这让我理解了一个常见取舍先提交 offset 可能丢业务先完成业务再提交 offset 可能重复。工程上常选择至少一次投递再用幂等消除重复影响。五、MySQL、OceanBase、Doris业务事实和分析结果1. MySQL 与 OceanBase 偏 OLTP创建订单、扣减库存和修改支付状态需要频繁增删改查、事务和低延迟点查。MySQL 和 OceanBase 都适合这类在线交易处理。OceanBase 是独立的分布式关系型数据库并提供 MySQL 兼容模式。它的价值主要在原生分布式扩展、高可用和大规模事务能力但不能简单理解成“任何场景都比 MySQL 更好”。规模较小、架构简单时MySQL 通常更轻量。2. Doris 偏 OLAP“查询某一笔订单是否支付”更像 OLTP“统计过去一年每个地区每天的销售额”则需要扫描和聚合大量数据更适合 Doris。Doris 兼容 MySQL 协议和一部分 SQL 使用方式因此可以用 JDBC、数据库客户端和 BI 工具连接但连接方式相似不代表用途相同。典型数据链路可以是订单写入 MySQL / OceanBase ↓ Kafka / CDC / 同步任务 ↓ Doris ↓ 报表、趋势、排行一句话记忆MySQL 或 OceanBase 把每笔生意记准确Doris 从大量生意中总结规律。六、把七个组件放回一条订单链路用户请求 ↓ Spring Cloud Gateway ↓ Spring Boot 订单服务 ↓ MySQL / OceanBase 保存订单事务 ↓ Kafka 发布 OrderCreated ├── 风控 ├── 积分 └── 同步到 Doris 做分析 发送短信、邮件等任务 ↓ RabbitMQ ↓ 任务消费者处理并 ACKDocker 把这些应用制作成镜像。开发环境可能用 Compose 启动一整套依赖测试和生产环境可能交给 K8s 调度。这只是一张学习用的示意图真实项目必须结合目录、依赖、配置和调用链验证不能看到技术名词就套固定架构。七、接下来看真实项目时我会先找什么我不会从某个业务类开始逐行阅读而是先找组件“接缝”DockerDockerfile、基础镜像、JAR、端口、启动命令Composecompose.yml、services、ports、volumes、healthcheckK8sDeployment、Service、镜像、副本、探针、ConfigMapKafkaspring-kafka、bootstrap-servers、KafkaListener、topic、group-idRabbitMQspring-boot-starter-amqp、Exchange、Queue、Routing Key、RabbitListenerOceanBase数据源 URL、JDBC 驱动、MyBatis/JPA、事务、表和索引Doris分析数据源、聚合 SQL、Kafka 导入、Stream Load、分区分桶。然后固定追问六件事谁写入、谁读取、失败如何重试、是否可能重复、数据以谁为准、如何观察健康状态。这次速成让我建立了概念地图但还不能算真正看懂项目。下一步是把真实项目的模块目录、启动类、构建文件和配置拿出来把每一个概念映射到实际文件和调用链中。
最近需要快速理解一个 Spring Boot、Spring Cloud 项目并准备借助 AI 新增一个项目。因为 Java 基础还不扎实我给自己定的目标不是短期内独立手写所有代码而是先达到三个标准能解释每个基础设施组件解决什么问题能在代码和配置中找到它的入口能和研发人员沟通也能判断 AI 生成的方案是否合理。我集中学习了 Docker、Docker Compose、Kubernetes、Kafka、RabbitMQ、OceanBase 和 Doris。最大的收获不是记住七套定义而是发现它们可以放进一张非常清楚的系统地图。一、先别背名词后端系统只是在解决三类问题第一类问题是应用怎样以一致的方式运行本地环境、测试环境和生产环境不能各装一套不同版本的 Java 与依赖。Docker 用镜像统一交付Compose 组织一台机器上的多个容器K8s 在集群中管理大量容器。第二类问题是服务之间怎样异步协作一次请求不可能永远同步等待所有下游。Kafka 保存可以被多个系统独立读取和重放的事件RabbitMQ 把需要处理的消息路由到合适的任务队列。第三类问题是数据怎样保存和使用订单、账户和库存要求事务准确报表和指标要求快速扫描大量数据。MySQL、OceanBase 偏前者Doris 偏后者。从这三个问题出发再看具体产品就不容易混乱。二、Docker、Compose、K8s从一个容器到整个集群1. Docker统一应用交付物Dockerfile 像一张配方说明基础镜像是什么、JAR 放在哪里、用什么命令启动。构建结果是镜像镜像运行后才是容器。FROM eclipse-temurin:21-jre WORKDIR /app COPY target/order-service.jar app.jar ENTRYPOINT [java, -jar, app.jar]一开始我把 Docker 理解成“把本地项目打包成可以直接运行的应用”这个方向没错但还要加上两个边界镜像是只读模板容器是运行实例容器中的临时数据可能随容器删除因此数据库等持久数据要放到 Volume。2. Docker Compose组织一台机器上的多个容器一个 Spring Cloud 项目可能同时依赖 Gateway、订单服务、MySQL 和 RabbitMQ。Compose 可以把它们写进一个 YAML一次启动整套本地环境。它最适合开发、联调、演示和简单单机部署。服务之间可以用服务名通信但depends_on主要表示启动顺序不代表数据库已经做好接收请求的准备。3. Kubernetes维护集群期望状态K8s 最重要的概念不是“多服务器部署”而是期望状态。例如我声明订单服务需要三个副本期望状态3 个 Pod 实际状态2 个 Pod 控制器动作再创建 1 个 PodDeployment 管理副本和发布Service 给变化的 Pod 提供稳定地址ConfigMap 和 Secret 承载配置探针判断应用是否存活、是否已经可以接收流量。因此可以这样记Docker运行一个容器 Compose组织一台机器上的多个容器 K8s在集群中持续维护容器化应用的期望状态三、Kafka 与 RabbitMQ事件档案和任务派送这是我学习过程中最容易混淆的一组。1. Kafka 更像可重放的事件档案生产者把事件追加到 Topic 的 Partition。消费者通过 offset 记录自己在分区中读到了哪里多个 Consumer Group 可以各自读取同一批事件。例如订单创建后OrderCreated ├── 风控消费组 ├── 积分消费组 ├── 推荐消费组 └── Doris 数据同步消费组如果 Doris 需要重建近七天的数据可以调整消费位置重新读取历史事件。这种需要保留、重放和多个下游独立订阅的场景通常更偏 Kafka。2. RabbitMQ 更像任务派送中心RabbitMQ 通常把消息发送给 Exchange再根据 Routing Key 和 Binding 路由到 Queue。消费者处理完成后发送 ACK消息随后从队列移除。例如支付成功 ↓ SendPaymentSms ↓ 短信队列 ↓ 某一个短信消费者处理 ↓ 成功 ACK多次失败进入死信队列需要灵活路由、任务确认、重试和死信处理的场景通常更偏 RabbitMQ。3. 不是“Kafka 能做什么、RabbitMQ 不能做什么”Kafka 也能在一个消费组内把任务分摊给多个消费者RabbitMQ 也能绑定多个队列实现发布订阅。两者存在能力重叠。真正的判断维度是消息是否需要保留和重放多个下游是否需要独立消费是否需要复杂路由任务是否强调 ACK、重试和死信处理四、我对 offset 最大的一次误解学习时遇到一道题优惠券已经发放但 Kafka offset 还没提交消费者突然宕机恢复后会发生什么我最初想到的是多节点备份和定时写入磁盘。这个回答混淆了两个层次Kafka Broker 的副本和磁盘负责保存消息Consumer 的 offset 负责记录读取进度。消息其实还在 Kafka 中。因为 offset 没有提交消费者恢复后会再次读到同一条事件于是可能重复发放优惠券。真正需要的是业务幂等。例如每个订单只允许领取一次某类优惠券可以使用UNIQUE(order_id, coupon_type)消费者再次收到消息时如果唯一记录已经存在就不再发券但仍把本次消费视为成功并提交 offset。还有一个容易忽略的并发问题不能只“先查询是否处理过再决定是否发放”。两个消费者可能同时查询都看到未处理。数据库唯一约束才是最后防线。这让我理解了一个常见取舍先提交 offset 可能丢业务先完成业务再提交 offset 可能重复。工程上常选择至少一次投递再用幂等消除重复影响。五、MySQL、OceanBase、Doris业务事实和分析结果1. MySQL 与 OceanBase 偏 OLTP创建订单、扣减库存和修改支付状态需要频繁增删改查、事务和低延迟点查。MySQL 和 OceanBase 都适合这类在线交易处理。OceanBase 是独立的分布式关系型数据库并提供 MySQL 兼容模式。它的价值主要在原生分布式扩展、高可用和大规模事务能力但不能简单理解成“任何场景都比 MySQL 更好”。规模较小、架构简单时MySQL 通常更轻量。2. Doris 偏 OLAP“查询某一笔订单是否支付”更像 OLTP“统计过去一年每个地区每天的销售额”则需要扫描和聚合大量数据更适合 Doris。Doris 兼容 MySQL 协议和一部分 SQL 使用方式因此可以用 JDBC、数据库客户端和 BI 工具连接但连接方式相似不代表用途相同。典型数据链路可以是订单写入 MySQL / OceanBase ↓ Kafka / CDC / 同步任务 ↓ Doris ↓ 报表、趋势、排行一句话记忆MySQL 或 OceanBase 把每笔生意记准确Doris 从大量生意中总结规律。六、把七个组件放回一条订单链路用户请求 ↓ Spring Cloud Gateway ↓ Spring Boot 订单服务 ↓ MySQL / OceanBase 保存订单事务 ↓ Kafka 发布 OrderCreated ├── 风控 ├── 积分 └── 同步到 Doris 做分析 发送短信、邮件等任务 ↓ RabbitMQ ↓ 任务消费者处理并 ACKDocker 把这些应用制作成镜像。开发环境可能用 Compose 启动一整套依赖测试和生产环境可能交给 K8s 调度。这只是一张学习用的示意图真实项目必须结合目录、依赖、配置和调用链验证不能看到技术名词就套固定架构。七、接下来看真实项目时我会先找什么我不会从某个业务类开始逐行阅读而是先找组件“接缝”DockerDockerfile、基础镜像、JAR、端口、启动命令Composecompose.yml、services、ports、volumes、healthcheckK8sDeployment、Service、镜像、副本、探针、ConfigMapKafkaspring-kafka、bootstrap-servers、KafkaListener、topic、group-idRabbitMQspring-boot-starter-amqp、Exchange、Queue、Routing Key、RabbitListenerOceanBase数据源 URL、JDBC 驱动、MyBatis/JPA、事务、表和索引Doris分析数据源、聚合 SQL、Kafka 导入、Stream Load、分区分桶。然后固定追问六件事谁写入、谁读取、失败如何重试、是否可能重复、数据以谁为准、如何观察健康状态。这次速成让我建立了概念地图但还不能算真正看懂项目。下一步是把真实项目的模块目录、启动类、构建文件和配置拿出来把每一个概念映射到实际文件和调用链中。
