<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>flyway on </title>
    <link>/tags/flyway/</link>
    <description>Recent content in flyway on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sun, 12 Apr 2026 10:00:00 +0800</lastBuildDate><atom:link href="/tags/flyway/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Spring Boot 3.5 下数据库实践记录：HikariCP 调优、N&#43;1 防护、事务管理与 Testcontainers 集成</title>
      <link>/posts/spring-boot-database-best-practices/</link>
      <pubDate>Sun, 12 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/spring-boot-database-best-practices/</guid>
      <description>📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
2026-04 实践更新 当前主线仓库里，MySQL 领域服务的集成测试基线已经基本统一为 @ServiceConnection；少数仍保留 @DynamicPropertySource 的测试，主要是因为除了数据库容器之外还需要额外挂接自定义属性，而不是数据库接线本身没有迁移完成。
在 Shop Platform 的 15 个服务中，11 个领域服务各自拥有独立的 MySQL 8.4 数据库。Spring Boot 3.5 结合 Spring Data JPA 3.5 提供了比较完善的数据库集成能力，但默认配置未必直接适合当前生产环境。需要额外说明的是：当前仓库已经稳定落地的是 ddl-auto: validate、Flyway 迁移、@ServiceConnection 集成测试，以及部分服务显式关闭 OSIV；像 Hikari 数值和 @EntityGraph 更适合作为“可参考实践”，不应直接写成“仓库现状”。
下面从六个维度整理一下 Spring Boot 3.5 下数据库实践里更常遇到的点。
HikariCP 连接池调优 为什么需要调优 Spring Boot 默认的 HikariCP 配置是 maximum-pool-size: 10。这个值适合当起点，但对容器化环境来说，既可能偏小，也可能偏大。
一个更稳妥的压测起点 spring: datasource: hikari: maximum-pool-size: 10 # 先作为压测起点 minimum-idle: 2 # 最小空闲连接 connection-timeout: 5000 # 获取连接超时（ms） idle-timeout: 300000 # 空闲连接超时（5 分钟） max-lifetime: 1200000 # 连接最大生命周期（20 分钟） 怎么确定 maximum-pool-size HikariCP 作者 Brett Wooldridge 的公式：</description>
    </item>
    
    <item>
      <title>Spring Boot 3.5 &#43; Java 25 &#43; Cloud Native 系列（四）：领域服务设计</title>
      <link>/posts/shop-platform-domain-services/</link>
      <pubDate>Fri, 03 Apr 2026 10:00:00 +0800</pubDate>
      
      <guid>/posts/shop-platform-domain-services/</guid>
      <description>在前两篇文章中，我们看了 API Gateway 的路由分发和 BFF 的聚合编排。这一篇继续往里走，看看业务承载最集中的一层——领域服务层。
📦 本文基于的完整项目源码：https://github.com/meirongdev/shop
上一篇：（三）BFF 聚合层
2026-04 实践更新 领域服务侧当前已经和早期文章发布时相比前进了一步：Problem Details、@ServiceConnection、补偿任务持久化、Kafka 幂等守卫都已落地；本文中的领域边界划分仍然成立，但涉及“后续会做”的部分请以主线仓库现状为准。
领域服务清单 Shop Platform 核心业务按边界拆成 11 个领域服务，每个服务独立开发、独立部署、拥有自己的数据库 schema；此外 auth-server 自己维护 shop_auth，但它更偏认证边界，本文重点放在业务域服务。
服务 数据库 核心业务 profile-service shop_profile 用户档案、地址簿、卖家档案 marketplace-service shop_marketplace 商品目录、SKU、库存、评价 order-service shop_order 订单状态机、购物车、退款 wallet-service shop_wallet 钱包余额、充值、Stripe 支付 promotion-service shop_promotion 促销引擎、优惠券 loyalty-service shop_loyalty 积分账户、签到、兑换 activity-service shop_activity 插件化游戏引擎 search-service — Meilisearch 集成、Feature Toggle notification-service shop_notification 邮件通知、Channel SPI webhook-service shop_webhook 开放平台 Webhook、HMAC 签名 subscription-service shop_subscription 订阅计划、自动续费 其中 search-service 没有关系型数据库——它的数据存储在 Meilisearch 搜索引擎中。</description>
    </item>
    
  </channel>
</rss>
