17370845950

微服务拆分后应弃用$_SESSION，改用JWT无状态认证；$_COOKIE仅存非敏感字段并设Domain/SameSite；数据库事务改用消息队列实现最终一致性；公共代码抽为独立Composer包；各服务独立部署、配置FPM参数并提供标准健康检查接口。

单体 PHP 里的 $_SESSION 和 $_COOKIE 怎么办

微服务拆分后，用户会跨多个服务（如 auth-service、order-service）请求，而 PHP 默认的文件或 Redis session 存储只绑定在单一服务进程里，其他服务无法读取 $_SESSION。硬共享 session 存储（比如全用同一个 Redis DB + 相同 session_id）看似可行，但实际会引发并发写冲突、过期策略不一致、敏感数据泄露等问题。

更稳妥的做法是彻底弃用 $_SESSION，改用无状态认证：

• 登录成功后，auth-service 签发 JWT（含 user_id、role、exp），通过 HTTP Header（如 Authorization: Bearer xxx）透传给下游服务
• 所有服务统一校验 JWT 签名和有效期，不再依赖 session 存储
• $_COOKIE 仅保留非敏感字段（如语言偏好），且必须设置 Domain 和 SameSite 属性适配多子域（如 Domain=.example.com）

数据库连接和事务怎么拆

原单体常共用一个 MySQL 实例，用事务包裹跨模块操作（如“扣库存 + 写订单 + 发通知”）。微服务要求每个服务独占数据库 Schema，跨服务事务无法靠本地 START TRANSACTION 保证一致性。

必须改成最终一致性方案：

• 订单服务创建订单时，只写本地 orders 表，状态设为 pending
• 通过消息队列（如 RabbitMQ 或 Kafka）异步发 inventory.deduct 消息给库存服务
• 库存服务处理成功后，再发 order.confirmed 回调；失败则触发补偿任务（如自动取消订单）
• 避免在 PHP-FPM 中直接调用其他服务的 HTTP 接口做同步事务——超时、级联失败风险极高

原来用 require_once 引入的公共函数库怎么复用

单体里把工具函数、模型类放在 app/Helpers/ 或 app/Models/ 下，用 require_once 或 Composer 自动加载。微服务中这些代码不能直接跨服务引用，否则形成强耦合和部署依赖。

正确做法是分层抽象：

• 把通用逻辑（如密码哈希、ID 生成、HTTP 客户端封装）抽成独立 Composer 包（如 myorg/php-common-utils），发布到私有 Packagist 或 Git repo，各服务按需 composer require
• 领域模型（如 User、Order）**不要共享类**，各服务定义自己的 DTO 或 request struct，通过 API Schema（OpenAPI）或 Protobuf 明确约定字段和类型
• 禁止在服务 A 的代码里 new ServiceBClient() 调用服务 B——应通过 API Gateway 统一路由，或使用 SDK 封装（SDK 只负责 HTTP 请求构造，不包含业务逻辑）

PHP-FPM 配置和部署方式必须变

单体通常一个 Nginx + 一组 PHP-FPM 进程跑全部逻辑；微服务需要每个服务独立部署、扩缩容、监控。这意味着：

• 每个服务必须有自己的 Dockerfile，基于 php:8.2-cli 或 php:8.2-apache 构建，不共用同一套 FPM 配置
• Nginx 不再直接代理 PHP-FPM，而是作为 API Gateway，用 upstream 分发请求到不同服务的容器（如 auth-service:8080、order-service:8080）
• FPM 的 pm.max_children、pm.start_servers 等参数要按服务负载单独调优——例如日志服务可设低内存限制，订单服务需更高并发连接数
• 健康检查接口（如 /healthz）必须返回 JSON 格式、明确状态码，供 Kubernetes 或 Consul 做服务发现

GET /healthz
HTTP/1.1 200 OK
Content-Type: application/json

{"status":"ok","timestamp":1717023456,"service":"order-service"}

真正难的不是改代码，是改协作习惯：接口变更要先更新 OpenAPI 文档，数据库 schema 变更必须配套迁移脚本并测试回滚路径，任何服务都不能假设其他服务永远可用——超时、重试、熔断得写进 PHP 代码里，而不是靠运维兜底。