服务间调用延迟比本地函数高约 1000–10000 倍：本地函数调用为纳秒至微秒级，而网络调用（含 localhost）通常为 1–10ms，主因是 tcp 握手、序列化、反序列化、网卡中断及调度切换等固有开销。
服务间调用延迟比本地函数高多少
Python 进程内函数调用是纳秒到微秒级，而服务拆分后走网络（哪怕 localhost），一次 HTTP/gRPC 调用通常在 1–10ms 量级。这不是 Python 慢，是 TCP 握手、序列化、反序列化、网卡中断、调度切换这些绕不开的开销。
实操建议：
立即学习 “Python 免费学习笔记（深入）”；
- 用
timeit测本地add_user()耗时；再用curl -w "@format.txt"或httpx.get()测同逻辑的 HTTP 接口耗时，对比差值 - 避免在循环里发多次服务请求 —— 改成批量接口，比如把
get_user(id)拆成get_users(ids) - localhost 的延迟不代表生产环境：K8s Pod 间通信、跨 AZ 网络、Service Mesh 中间件（如 Istio）都会额外加 2–5ms
JSON 序列化是隐藏的性能瓶颈
Python 的 json.dumps() 在数据量稍大（比如 >10KB）或嵌套深（>5 层）时会明显拖慢响应。更麻烦的是，它默认不处理 datetime、Decimal、bytes，容易抛 TypeError: Object of type datetime is not JSON serializable。
实操建议：
立即学习 “Python 免费学习笔记（深入）”；
- 用
ujson或orjson替代标准json——orjson快 3–5 倍，且原生支持datetime - 服务返回体别塞整张表数据：加
select()字段白名单，或用 Pydanticmodel_dump(exclude={"password"}) - 别在响应里传
__dict__或vars(obj)—— 容易漏掉 property、循环引用，直接崩在json.dumps()
同步阻塞调用会让并发能力归零
用 requests.get() 调其他服务时，当前线程完全卡住，GIL 不放、协程不切、连接池空转。哪怕你用 asyncio 写主服务，只要里面混了同步 HTTP 调用，整个 endpoint 就退化成单并发。
实操建议：
立即学习 “Python 免费学习笔记（深入）”；
- HTTP 调用必须用异步客户端：
httpx.AsyncClient（推荐）、aiohttp；别碰requests - 数据库连接也得配异步驱动：
asyncpg+SQLModel（非SQLAlchemy ORM同步版） - 别以为加个
await asyncio.to_thread(requests.get, ……)就安全 —— 线程池调度本身有开销，且掩盖了根本问题
gRPC 比 REST 更快？不一定
gRPC 默认用 Protocol Buffers 序列化，二进制体积小、解析快，但 Python 的 grpcio 实现有显著 GIL 争用，尤其在高并发小包场景下，吞吐可能不如优化过的 httpx + orjson。
实操建议：
立即学习 “Python 免费学习笔记（深入）”；
- 先压测：用
locust对比相同接口的 gRPC 和 HTTP/1.1 吞吐与 p99 延迟，别凭经验选型 - 如果团队没 PB 经验，别为了“技术先进”强上 gRPC —— 错误码映射、流控策略、TLS 配置都更难调试
- Python 服务间通信，优先考虑
httpx+orjson+HTTP/2（需hypercorn或uvicorn --http http2）
真正卡脖子的往往不是协议本身，而是序列化方式、错误重试逻辑、超时设置是否合理 —— 比如一个没设 timeout 的 httpx.get()，可能让整个请求挂住 60 秒才失败。
