一个微服务应仅拥有一个专属数据库（或schema），以保障边界清晰；共用表会导致事务、锁和schema变更相互干扰，判断依据是变更节奏与一致性需求。
微服务拆分时，一个服务该包含几个数据库表？
没有标准答案，但可以明确：**一个微服务原则上只应拥有且仅能直接写入一个专属数据库（或 schema）**。这不是技术限制，而是为了保障边界清晰——如果多个服务共用一张表，事务、锁、schema 变更都会互相干扰。
常见错误现象：OrderService 和 PaymentService 都在写 orders 表；或者 UserProfile 表被 AuthService、NotificationService、AnalyticsService 同时读写。
- 判断依据看「变更节奏」：如果两张表总是一起加字段、一起改索引、上线必须同步发布，那它们大概率不该拆开
- 看「一致性需求」：需要强一致更新的字段（比如
order_status和payment_state）不应跨服务维护，否则得靠最终一致性+补偿，成本陡增 - Python 项目里容易忽略的是 ORM 的隐式耦合：
SQLAlchemy的joinedload()或 Django 的select_related()跨服务调用时，实际已在破坏边界
Python 中怎么识别“该拆”还是“先别动”？
直接看代码里的 import 和调用链比看架构图管用。重点扫描 models.py、serializers.py、views.py 里是否混着不同业务域的实体和逻辑。
使用场景举例：你正在重构一个单体 Flask 应用，发现 app/routes/orders.py 里同时调用了 user.get_by_id()、inventory.check_stock()、shipping.calculate_fee() —— 这些函数如果来自不同模块，且各自有独立的数据库操作，就是拆分信号。
立即学习“Python免费学习笔记（深入）”；
- 优先拆「高变更频率 + 低依赖」模块：比如促销规则、优惠券发放，业务常调、技术栈可独立升级
- 暂缓拆「读多写少 + 强关联」模块：比如用户基础资料和头像 URL，拆了反而要频繁调用
UserService.get_profile()，延迟和失败率上升 - Django 项目特别注意
settings.py里的INSTALLED_APPS：如果某个 app 同时被三个不同业务路由 import，说明它已成胶水层，该拎出来了
拆完发现接口响应变慢了，是不是拆错了？
不一定错，但肯定暴露了没处理好的通信成本。HTTP 调用、序列化、网络超时、重试逻辑，在 Python 微服务里比 Java/Go 更容易成为瓶颈。
性能影响最明显的三点：requests.post() 默认无连接池、json.dumps() 处理大嵌套对象慢、同步等待下游服务导致线程阻塞。
- 先确认是否真慢：用
logging打点测各环节耗时，别猜。常见坑是urllib3连接池没配，每次请求都新建 TCP 连接 - 避免“服务内再调服务”：比如
OrderService收到创建订单请求后，又同步调InventoryService扣库存、再调PaymentService创建支付单——这本质是分布式事务陷阱 - Python 异步不是银弹：
asyncio+aiohttp能缓解 IO 等待，但若下游服务本身慢或不可用，只是把阻塞从线程换成了协程，问题照旧
团队协作时，怎么让拆分不变成“各自为政”？
关键不是文档写多全，而是约束落地。Python 项目里最容易失控的是协议演进和错误处理风格。
使用场景：多个团队并行开发，UserService 升级了 /v1/users/{id} 返回结构，但 OrderService 还在按老字段解析，结果 KeyError: 'full_name' 在生产环境炸开。
- 强制用 OpenAPI 3.0 定义接口，生成
pydantic模型，而非手写dict.get()或getattr() - 错误码统一：禁止返回
500 Internal Server Error带业务含义，所有服务必须约定400系列表示参数错、409表示状态冲突、422表示校验失败 - 本地调试时，用
docker-compose启动最小闭环（至少含网关 + 2 个服务），而不是只跑单个服务加 mock —— 很多超时、序列化失败只在真实链路里浮现
最常被忽略的一点：服务间数据传递不是“传对象”，而是“传契约”。哪怕用 dataclass 或 TypedDict，只要没走 schema 校验，就等于裸奔。Python 的灵活性在这里反而是陷阱。
