关键在于按限界上下文而非技术层拆分，确保业务边界对齐；excel等高负载功能须独立部署并隔离资源；数据库、队列与通信链路需同步解耦，并明确服务sla。
拆分 Laravel 微服务不是“把代码挪到新项目里”就完事——关键看边界是否对齐业务真实变化点，否则只会得到多个互相拖累的单体。
按限界上下文拆分，而不是按技术层
很多人一上来就按 Controller / Model / Job 拆，结果用户服务里还塞着订单校验逻辑、支付回调处理。这违背了高内聚原则。DDD 的 限界上下文 才是可靠边界：比如“下单”流程中，“库存扣减”和“优惠券核销”必须原子一致，它们就该在同一个服务里；但“物流轨迹推送”可以异步、失败可重试，就该拆出去。
- 用事件风暴梳理出核心业务事件（如
OrderPlaced、InventoryDeducted），再反推哪些实体和聚合根必须共存 - 避免跨服务直接调用
DB::table('orders')—— 数据所有权必须归属单一服务，其他服务只能通过 API 或事件消费数据 -
laravel-admin 扩展模块（如
media-manager）看似独立，但若它直接读写主应用的admin_users表，就不算真正解耦
Laravel-Excel 处理必须剥离为独立服务
Excel 导入导出天然具备三高特征：高内存占用、高 IO 延迟、高失败率。把它留在主服务里，一次超时或 OOM 就可能拖垮整个 API 网关。
- 新建 Laravel 项目作为
excel-service，只装maatwebsite/excel和队列驱动（如redis），不引入任何业务模型 - 主服务通过 HTTP 或消息队列发送任务，payload 只含必要参数：
file_url、template_id、callback_url，绝不传原始 Excel 二进制流 - 微服务内部用
QueuedWriter+Filesystem::disk('s3')直接落盘，避免Storage::get()加载大文件到内存
数据库拆分必须同步服务拆分
服务拆了，数据库还共用一个 MySQL 实例？那锁表、慢查询、连接数打满，照样让所有服务一起卡死。
- 每个微服务对应独立数据库实例或 schema，连接配置走
config/database.php中的connections分离项，而非复用default - laravel-admin 的
admin_users表如果被多个服务共享，就必须抽象成auth-service提供/api/v1/users/{id}接口，主应用禁用直接 DB 查询 - 跨库关联（如订单查用户昵称）必须用最终一致性：监听
UserUpdated事件，在订单服务本地缓存昵称字段，而非实时 JOIN
别忽略队列与网络的隐性成本
拆分后，原来内存里的函数调用变成网络请求 + 序列化 + 队列延迟。一个 matchOrder() 在内存撮合引擎里 8ms 完成，改成 HTTP 调用后可能飙到 300ms —— 这不是架构问题，是通信开销没被正视。
- 高频低延迟场景（如交易所订单匹配）必须保留在进程内，用
Redis共享内存结构，而非拆成服务 - 服务间通信优先选 Unix socket 或 gRPC，HTTP/1.1 的 Header 解析和 TLS 握手在压测下会吃掉 20%+ CPU
- 所有外部调用必须设硬超时：
Http::timeout(2)->retry(1)，避免一个下游抖动拖垮整条链路
最常被跳过的一步：没有为每个服务定义明确的故障恢复 SLA。比如 excel-service 宕机时，主应用是拒绝上传、降级为 CSV、还是转存队列等待重试？这个决策不在代码里，而在服务契约文档中。
