PHP单体转微服务要改哪些地方_迁移思路【教程】

13次阅读

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

PHP 单体转微服务要改哪些地方_迁移思路【教程】

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

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

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

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

数据库连接和事务怎么拆

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

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

立即学习 PHP 免费学习笔记(深入)”;

  • 订单服务创建订单时,只写本地 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
  • 领域模型(如 UserOrder)** 不要共享类 **,各服务定义自己的 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-cliphp:8.2-apache 构建, 不共用同一套 FPM 配置
  • Nginx 不再直接代理 PHP-FPM,而是作为 API Gateway,用 upstream 分发请求到不同服务的容器(如 auth-service:8080order-service:8080
  • FPM 的 pm.max_childrenpm.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 代码里,而不是靠运维兜底。

星耀云
版权声明:本站原创文章,由 星耀云 2025-12-27发表,共计1875字。
转载说明:转载本网站任何内容,请按照转载方式正确书写本站原文地址。本站提供的一切软件、教程和内容信息仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。
text=ZqhQzanResources