第3章：常见通信协议：HTTP/HTTPS、RPC、消息队列的区别与选型
做接口集成，选通信协议是第一道坎。很多刚入行的同事喜欢问：“哪个协议最好？”我不这么看。没有最好的协议，只有最合适的场景。今天我就把这三种主流方案掰开揉碎了讲，你在实际项目中肯定能用上。
3.1 HTTP/HTTPS：万金油，但不是万能油
HTTP，说白了就是浏览器跟服务器聊天用的那套规矩。不过现在都2025年了，除了内部测试，我还真没见过谁还在用纯HTTP做生产集成。
我在项目中遇到过几次，对方提供了HTTP接口，说是“内网环境，没关系”。我坚持让他们改了。为什么？因为你没法保证中间没人搭个嗅探器。内部员工泄露数据的案例，你们应该也听过不少。
适用场景：
- 业务系统与审计系统的单次请求-响应
- 文件上传下载（审计证据、凭证影像）
- 对实时性要求不高的查询类接口
举个例子，你要从财务系统拉一份科目余额表：
POST /api/v1/audit/account-balance
Host: finance.internal.com
Content-Type: application/json
Authorization: Bearer <>
{
"accountCode": "1001",
"period": "2025-01"
}这种方式简单明了。但你要是用它做实时的凭证流推送，那就不太明智了——每次都要建立连接、传输、断开，效率上不去。
3.2 RPC：内部系统之间的高速路
RPC，远程过程调用。你想想看，你调一个本地函数，参数传进去，结果回来。RPC就是让你感觉在调一个远程的函数。常见的实现有gRPC、Dubbo、Thrift。
我个人习惯在审计系统的内部模块间用gRPC。比如审计主控系统要去查一下风险模型引擎的结果，用gRPC就比RESTful快得多。为什么？因为它序列化用的是Protobuf，不是JSON，数据包小了不止一半。
适用场景：
- 审计系统内部模块之间的高频调用
- 对延迟敏感的实时规则校验
- 数据量大的批量查询（一次查几万条分录）
一个gRPC服务的定义大概是这样的：
service AuditRuleEngine {
rpc CheckTransaction (TransactionRequest) returns (CheckResult);
}
message TransactionRequest {
string transactionId = 1;
string accountCode = 2;
double amount = 3;
string timestamp = 4;
}但是，RPC也有坑。我曾遇到过，两个系统用了不同的gRPC版本，结果序列化对不上，跑了一晚上的数据全是空的。嗯，这里要注意，跨系统的RPC一定要事先约好接口规范和版本管理流程。
3.3 消息队列：削峰填谷的利器
消息队列，你先把消息扔进去，消费者有空了再来取。常见的有Kafka、RabbitMQ、RocketMQ。这玩意儿在审计场景里，简直是为数据流转量身定做的。
为什么这么说？你想，审计系统经常要做的是“每天凌晨批量拉取前一天的所有交易流水”。如果用HTTP，财务系统那边可能扛不住瞬间的请求量。用RPC呢？也不现实，因为财务系统没法一直等着审计系统响应。
我建议的做法是：财务系统把流水实时推送到Kafka的一个Topic里，审计系统自己按节奏消费。这样两边都不累。
适用场景：
- 审计数据的批量传输（凭证流、交易流水、审批日志）
- 跨系统的数据同步（财务-审计-风控）
- 对一致性要求不那么苛刻（允许秒级延迟）的场景
一个典型的消息体结构：
{
"messageId": "msg_202501010001",
"eventType": "TRANSACTION_CREATED",
"timestamp": "2025-01-01T00:00:00Z",
"payload": {
"transactionId": "txn_xxx",
"amount": 15000.00,
"accountFrom": "1001",
"accountTo": "2001"
}
}3.4 怎么选？一张表说清楚
很多团队在选型上纠结。我通常会问三个问题：
- 数据重要，还是速度重要？ —— 重要数据选HTTPS/RPC，速度选消息队列。
- 是一对一，还是一对多？ —— 一对一用HTTP/RPC，一对多用消息队列。
- 能接受几秒延迟吗？ —— 能，消息队列；不能，直接调用。
| 维度 | HTTP/HTTPS | RPC (gRPC) | 消息队列 |
|---|---|---|---|
| 通信模式 | 请求-响应 | 请求-响应 | 异步发布/订阅 |
| 延迟 | ~100-500ms | ~10-50ms | ~1-10ms (生产侧) |
| 吞吐量 | 中 | 高 | 极高 |
| 数据格式 | JSON/XML | Protobuf | JSON/Binary |
| 审计适配性 | 最适合外部对接 | 最适合内部模块 | 最适合数据流转 |
3.5 我总结的选型逻辑
你打开任何一本集成架构的书，都会告诉你“根据场景选”。但实际项目中，我建议你从两个维度下手：
- 数据的时间敏感度：实时查询（如当前是否违规）走RPC；批量对账（如日终凭证核对）走消息队列；跨组织的接口（如与税务局对接）走HTTPS。
- 系统的耦合度：强耦合走RPC；弱耦合走消息队列；无耦合走HTTPS。
好了，下面这张图可以帮你理清这三种协议在审计环境中的位置关系。
最后提醒一句：选型不是一次性的。随着审计系统接入的数据源越来越多，你可能今天用HTTP，明天就得切消息队列。别死守一种协议，灵活一点。