先说结论，JSON 并非不能使用，而是不应该在任何场景下都无脑使用 JSON。很多接口一旦更换数据格式，带宽消耗和 CPU 使用率会显著下降，从整个调用链路来评估，提升五倍的性能量级并不夸张，尤其是在移动网络和高并发场景下。
曾经在深夜处理线上告警，一条“查询订单详情”的接口平均响应时间达到了 800ms，95 分位线更是高达两三秒。排查后发现，数据库和缓存表现正常，问题出在网关与服务间大量的 JSON 序列化与反序列化操作上。那一刻让我真正开始思考：是否应该让 JSON 在某些场景下“退休”了。
那么，JSON 的性能瓶颈究竟在哪里？
首先必须承认，JSON 有很多优点：调试方便、人类可读、浏览器原生支持、生态工具丰富。但其短板也非常明显：
一是体积臃肿。大量重复的字段名以字符串形式存在，嵌套层级一旦加深，报文体积就会急剧膨胀。在移动端网络环境下，一条 200KB 的 JSON 响应足以带来糟糕的用户体验。
二是 CPU 开销大。字符串解析本身就很消耗计算资源。看似简单的 json.loads() 操作，底层实际上完成了大量“字符串 -> 对象”的转换工作，对于像 Python 这类不以速度见长的语言，频繁的序列化/反序列化会让 CPU 居高不下。
三是表达能力有限。处理二进制数据需要 Base64 编码，时间格式需要额外约定，高精度数字可能丢失精度，前后端只能依靠文档来对齐字段含义，缺乏强类型约束。
因此，我为 JSON 制定了一份“使用说明书”：在对外的开放 API、管理后台等偏“给人看”的场景继续使用；在内部服务通信、数据埋点、批量数据传输等对性能和带宽敏感的场景，则积极考虑其他格式。
方案一：MessagePack —— 为 JSON 装上涡轮增压
最先被用来替代 JSON 的是 MessagePack。选择它的理由很简单：语法类似 JSON，使用方式也差不多，但它是二进制格式，序列化结果为紧凑的字节流，字段类型信息被高度压缩。
我曾在一个订单查询接口上做过对比测试，使用 Python 脚本对同一批订单数据（包含用户信息、商品列表、优惠、物流等嵌套字段）进行压测。
数据示例如下：
data = {
"order_id": 123456789,
"user": {
"id": 9527,
"name": "东哥",
"vip": True
},
"items": [
{"sku": "IP15-BLK-128", "price": 6999.0, "count": 1},
{"sku": "CASE-XXX", "price": 69.0, "count": 2},
],
"coupon": None,
"status": "PAID"
}
使用 JSON 进行基准测试：
import json
import time
def bench_json(n=100_000):
t1 = time.time()
for _ in range(n):
b = json.dumps(data).encode("utf-8")
_ = json.loads(b.decode("utf-8"))
t2 = time.time()
print("JSON:", t2 - t1, "秒")
使用 MessagePack 进行对比：
import msgpack
import time
def bench_msgpack(n=100_000):
t1 = time.time()
for _ in range(n):
b = msgpack.dumps(data, use_bin_type=True)
_ = msgpack.loads(b, raw=False)
t2 = time.time()
print("MessagePack:", t2 - t1, "秒")
测试结果因环境而异，但两个趋势非常稳定：
- 相同数据，MessagePack 序列化后的字节长度通常比 JSON 小 30% ~ 50%。
- 纯序列化/反序列化的耗时，MessagePack 往往比 JSON 快 2-3 倍。
将体积和解析速度的优势叠加，再考虑到真实环境中网络传输、TLS握手、负载均衡等其他环节，最终给用户带来的整体体验提升 3-5 倍是完全可能的。
在实际的 Python 后端项目中，集成 MessagePack 的改动很小，例如在 FastAPI 中：
import msgpack
from fastapi import FastAPI, Response, Request
app = FastAPI()
@app.post("/order/detail")
async def order_detail(request: Request):
body = await request.body()
# 假设客户端发送的是 msgpack 格式
req = msgpack.loads(body, raw=False)
order_id = req["order_id"]
# ... 查询数据库/缓存，构造响应数据 ...
resp = {"order_id": order_id, "status": "PAID"}
return Response(
content=msgpack.dumps(resp, use_bin_type=True),
media_type="application/x-msgpack"
)
前后端只需约定使用 application/x-msgpack 作为 Content-Type，HTTP 协议本身并无变化，变的只是 body 的编码格式。
方案二：Protobuf —— 强类型 API 的黄金搭档
如果说 MessagePack 是“给 JSON 装上涡轮”，那么 Protocol Buffers (Protobuf) 就是更换了整套动力系统。
当你面临这样的场景：内部服务间调用频繁、数据结构稳定、希望有强类型约束来避免依赖文档和口头约定，那么 Protobuf 是一个非常合适的选择。我曾经在构建内部 RPC 框架时使用了 gRPC + Protobuf，接口描述通过 .proto 文件定义并纳入版本管理，任何字段变更都必须先修改协议定义，确保了严格的接口契约。
一个简单的订单协议定义如下：
// order.proto
syntax = "proto3";
message OrderRequest {
int64 order_id = 1;
}
message OrderResponse {
int64 order_id = 1;
string status = 2;
double amount = 3;
}
使用 protoc 工具生成 Python 代码后，使用方式如下：
from order_pb2 import OrderRequest, OrderResponse
# 序列化
req = OrderRequest(order_id=123456789)
req_bytes = req.SerializeToString()
# 反序列化
parsed = OrderRequest()
parsed.ParseFromString(req_bytes)
print(parsed.order_id)
与 JSON 相比，Protobuf 有几个硬核优势：
- 字段编号代替字段名：传输时只传递字段编号和值，避免了字段名带来的字节开销，报文体积显著减小。
- 强类型约束：
order_id 被明确定义为 int64，试图传入字符串会在代码生成或编译阶段就抛出错误，将问题消灭在开发期。
- 良好的兼容性：通过规范的字段编号管理，可以很好地支持向前和向后兼容，老版本客户端通常不会因新增字段而崩溃。
在性能上，Protobuf 通常比 JSON 更节省资源。我曾在 Python 中测试过一个包含数十个字段和嵌套的复杂对象，其反序列化耗时仅为 JSON 的零头。当然，缺点也很明显：需要编写 .proto 文件并生成代码；对前端或需要可视化调试的场景不够友好。因此，我通常只在后端服务间的内部通信中使用 Protobuf。
方案三：Avro —— 大数据与埋点系统的理想选择
曾有一段时间，我们的埋点系统将所有事件都以 JSON 格式写入 Kafka。初期看似省事，但很快问题接踵而至：字段增多导致事件体积暴增，集群存储压力巨大；字段频繁变更，导致消费端代码充满各种版本的兼容逻辑。
此时，Avro 的优势就体现出来了。它的核心理念是将 Schema（模式）视为一等公民，与数据一同管理。
首先定义一个 Avro Schema，例如：
{
"type": "record",
"name": "Event",
"namespace": "log",
"fields": [
{"name": "event", "type": "string"},
{"name": "user_id", "type": "long"},
{"name": "ts", "type": "long"},
{"name": "props", "type": {"type": "map", "values": "string"}}
]
}
在 Python 中使用 fastavro 库进行序列化和反序列化：
from fastavro import parse_schema, schemaless_writer, schemaless_reader
import io
import time
schema = parse_schema({
"type": "record",
"name": "Event",
"namespace": "log",
"fields": [
{"name": "event", "type": "string"},
{"name": "user_id", "type": "long"},
{"name": "ts", "type": "long"},
{"name": "props", "type": {"type": "map", "values": "string"}}
]
})
event = {
"event": "order_create",
"user_id": 9527,
"ts": int(time.time() * 1000),
"props": {"channel": "app", "platform": "ios"}
}
# 序列化
buf = io.BytesIO()
schemaless_writer(buf, schema, event)
raw = buf.getvalue()
# 反序列化
buf2 = io.BytesIO(raw)
parsed = schemaless_reader(buf2, schema)
print(parsed)
对于埋点这类场景，Avro 有两个突出优点：
- Schema 集中管理：字段的增删改可以通过 Schema Registry 统一协调，数据管道不至于因 Schema 变更而混乱。
- 出色的压缩率：尤其当与 Kafka 的主题压缩功能结合时，能极大地缓解海量日志数据带来的存储压力。
方案四：FlatBuffers —— 为极限实时场景而生
FlatBuffers 相对小众一些，最初在游戏领域流行。其核心设计是“零拷贝”（Zero-Copy）。这意味着，当你收到一个 FlatBuffers 编码的二进制缓冲区后，无需将其完全解析为新的内存对象，可以直接在原缓冲区上按需读取数据。
简单类比：JSON 是“必须把整篇文章打印出来才能阅读”；Protobuf 是“按照目录归档，查阅时抽取所需档案”；而 FlatBuffers 则是“一份排好版的 PDF，你可以直接跳转到任意页面和行进行阅读”。
在 Python 的常规 Web 开发中较少使用 FlatBuffers，但在处理实时推送、IoT 设备上报、游戏状态同步等对延迟极度敏感的 高并发场景 时，它的优势非常明显。我曾在一个边缘计算项目中尝试使用，确实能将数据解包的 CPU 开销压得非常低。
实践：抽象序列化层，实现格式可插拔
介绍了这么多格式，最忌讳的做法就是一时冲动将整个系统绑定到某一种格式上，为未来的技术迭代或团队协作埋下隐患。
一个更稳健的做法是，在代码中抽象出一层“序列化策略”，避免业务代码中到处散落着 json.dumps 或 msgpack.dumps 等硬编码调用，而是通过统一的适配器来处理。
一个简单的序列化适配器示例：
import json
import msgpack
class Serializer:
def __init__(self, fmt: str = "json"):
self.fmt = fmt
def dumps(self, obj) -> bytes:
if self.fmt == "json":
return json.dumps(obj, separators=(",", ":")).encode("utf-8")
elif self.fmt == "msgpack":
return msgpack.dumps(obj, use_bin_type=True)
else:
raise ValueError(f"unknown format: {self.fmt}")
def loads(self, data: bytes):
if self.fmt == "json":
return json.loads(data.decode("utf-8"))
elif self.fmt == "msgpack":
return msgpack.loads(data, raw=False)
else:
raise ValueError(f"unknown format: {self.fmt}")
在 HTTP 请求处理器中，业务逻辑无需关心底层使用的是 JSON 还是 MessagePack，它只需要知道“给我一个字典，我返回字节流”即可。切换数据格式只需修改一处配置，对业务代码的侵入性降到最低。
serializer = Serializer(fmt="msgpack") # 线上切换回 json 只需修改此处
def handle_request(raw: bytes) -> bytes:
req = serializer.loads(raw)
# ... 处理业务逻辑 ...
resp = {"ok": True}
return serializer.dumps(resp)
你甚至可以将 fmt 参数配置化，实现不同环境、不同客户使用不同协议的灵活策略，便于进行灰度发布。
决策指南：何时应该“放弃”JSON？
那么，是否意味着从明天起所有 API 都要抛弃 JSON 呢？当然不是。根据我的经验，可以这样划分：
- 对外开放的接口：优先使用 JSON。其无与伦比的调试体验、广泛的兼容性和丰富的第三方集成支持， outweigh 那一点性能损失。
- 内部高频调用服务：尤其是那些每次请求都需要传递大量结构化数据的场景，优先考虑 Protobuf 或 MessagePack。前者提供强类型安全，后者无需预定义 Schema，两者都能有效降低体积和 CPU 开销。
- 埋点、日志、流式数据处理：倾向于使用 Avro。配合 Schema Registry，可以优雅地管理数据结构的演进，降低运维复杂度。
- 极限实时场景：如游戏状态同步、设备传感器高频上报等对延迟有极致要求的场景，可以深入研究 FlatBuffers，其零拷贝特性能在数据量极大时带来显著的性能红利。
最后需要强调的是，切勿迷信某种数据格式是解决所有性能问题的“银弹”。数据格式优化只是整个系统性能调优链路中的一环。数据库索引、多级缓存、网络 参数调优、线程池配置等诸多方面协同优化后，再叠加上一个合适的数据格式，才能真正释放出全部性能潜力。
现在，每当设计一个新接口时，我都会先思考：这个接口未来是否会演变为“高频、大 payload”的调用？如果答案是肯定的，那么 JSON 在我的候选列表中，默认就会排在其他二进制协议之后。这种技术选型的思考，也是我们不断在 云栈社区 与广大开发者交流和实践的核心话题之一。
发表于 12 小时前
|
查看: 1|
回复: 0
