先说服务拆分这个老大难。见过有团队按数据库表结构硬拆的，结果两个服务整天互相调用，比分布式单体还离谱。建议按业务边界划分，比如用户中心、订单服务、库存服务各成体系。有个血泪教训：商品服务的SKU模块和SPU模块本来耦合紧密，非要把它们拆成两个服务，结果跨服务事务把团队逼得天天通宵。后来改成将商品域整体作为服务，内部用模块化区分，这才消停。
通信机制这块水更深。用JSON-RPC还是RESTful？实测下来，内部服务间调用推荐Swoole+RPC，性能比HTTP高30%以上。但别忘了在API网关层统一转换成RESTful对外暴露，不然移动端同事要骂街。上周排查个诡异问题：订单服务调支付服务超时，自己重试三次，结果支付回调时生成三张相同订单。最后用雪花算法生成全局请求ID，配合Redis分布式锁才解决。
数据一致性是最头疼的。刚开始天真地用本地事务+重试机制，结果分布式事务直接教做人。现在我们的方案是：强一致性场景用TCC事务（比如扣库存+生成订单），最终一致性用本地消息表+事件驱动。特别注意PHP脚本超时问题，有个服务在处理资金结算时因set_time_limit(0)导致僵尸进程，差点把数据库连接池撑爆。
配置管理千万别掉以轻心。曾经把数据库连接串写死在.env文件里，某天数据库主从切换，所有服务同时崩溃。现在统一用Nacos作配置中心，敏感配置还要加密存储。提醒个细节：PHP的opcache会导致配置更新延迟，记得在部署脚本里主动清理缓存。
监控体系建设要趁早。当初没埋点就敢上线，某天晚高峰订单量暴跌，查了通宵才发现是商品服务线程池爆满。现在用Prometheus收集指标，Grafana配置了十多个看板。特别要监控PHP-FPM进程状态，有次因为某个服务内存泄漏，导致整个服务器进程数雪崩。
容器化部署时注意冷启动问题。传统FPM模式每次请求都要初始化框架，响应时间波动太大。推荐用Swoole常驻内存，配合K8s的就绪探针，启动时预加载路由配置。不过要注意代码热更新问题，建议在预发布环境做兼容性测试。
最后说个容易被忽略的：文档同步。我们用OpenAPI规范自动生成接口文档，在CI流程中强制检查文档更新。有次支付接口调整参数没更新文档，直接导致客户端调用失败，这个坑踩过的人都懂。
（掐灭烟头）搞微服务不是跟风赶时髦，关键要看业务体量。五十万用户以内的系统，拆好了是提升效率，拆不好就是自寻死路。建议先拿边缘业务试水，等基础设施完善再动核心业务。记住，合适的架构才是好架构。