最近帮朋友公司做架构升级，他们正把一个大块头的单体应用拆成微服务。结果呢？改完之后上线问题一堆，接口调用像走迷宫，查个日志得翻五六个系统。问题出在哪？不是技术不行，而是微服务边界划歪了。
边界划不好，运维累断腰
很多人一听说微服务好，立马动手拆。用户模块、订单模块、支付模块，咔咔一顿切。但切完发现，这几个服务之间调来调去，一个下单操作要跨四个服务通信，网络抖一下，整个流程就卡住。这哪是微服务，简直是“危”服务。
关键在于，边界不该按“功能名字”来切，而要按“业务能力”和“数据归属”来定。比如订单和支付，看着是两件事，但如果支付逻辑完全围绕订单展开，且数据强关联，硬拆开只会增加复杂度。
怎么划才算靠谱？
一个简单的方法是看“高内聚、低耦合”。一个服务内部的功能要紧密相关，对外依赖尽量少。比如用户注册、登录、信息管理，这些都属于用户上下文，放一起没问题。但要是把权限控制也塞进去，等后面权限规则一变，用户服务就得跟着发版，这就耦合了。
另一个实用技巧是“事件驱动思维”。比如下单成功后，订单服务不要直接调用库存服务扣减，而是发一个 OrderCreated 事件，让库存服务自己监听并处理。这样两边解耦，以后加个积分服务也只需订阅事件，不用改订单代码。
<?php
// 下单完成后发布事件
$eventBus->publish(new OrderCreated($orderId, $userId, $amount));
?>别忽视数据库的墙
服务拆了，数据库还共用一张表？那等于房子分了，钥匙还串在一起。真正的边界意味着每个服务拥有自己的数据存储，别人想查，必须走接口，不能越界直连。
举个例子，用户服务管用户表，订单服务需要用户昵称，不能自己去查 user 表，而是调用用户服务提供的 API。虽然多了一次网络请求，但换来的是独立演进的能力。
从小场景开始试水
如果你还在犹豫怎么划，不妨先挑个非核心流程试试。比如把“发送通知”单独拆成一个服务，支持短信、邮件、站内信。它不参与主流程，失败也不影响下单，但能让你熟悉服务间通信、部署、监控这一整套流程。
等跑顺了，再动核心模块。别一上来就拿订单开刀，不然半夜报警电话少不了。