服务器的调用为什么不用HTTP，服务间调用为何不用HTTP？

服务器调用并不是“不能用HTTP”，而是很多内部调用场景不会优先选传统HTTP/1.1 REST：它们更在意延迟、吞吐、连接复用、序列化效率和流式能力，于是转向RPC、消息队列或自定义TCP；而gRPC这类RPC又常跑在HTTP/2上。对外API走HTTP，内部服务走RPC，是常见分工，但这不是铁律，关键看调用发生在浏览器与服务器之间，还是服务器与服务器之间。

服务器调用为什么不用HTTP？先把“调用”拆成两类

外部访问和内部调用，目标不同

• 外部访问：浏览器、App、第三方开放平台，它们要穿公网、过网关、过防火墙、过CDN，HTTP/HTTPS是通用语言，兼容性最好，调试也方便。
• 内部调用：订单服务调库存服务、库存服务调支付服务，这类东西向流量跑在同机房、同可用区，甚至同集群，它更关心毫秒级延迟、连接数、序列化开销和故障隔离。
• 跨地域调用：北京机房调上海机房，或者同城双活两个机房互调，这时网络RTT已经摆在那里，协议再快也绕不过物理距离，协议选择要服务于就近路由和超时控制。

传统HTTP/1.1 REST在外部访问里很成功，因为可读、可缓存、可代理，但把它直接搬到内部高频调用里，就会遇到几个现实问题。

传统HTTP/1.1 REST在内部调用里的四个包袱

• 头部冗余：每次请求都带一堆文本头，Cookie、User-Agent、Accept，内部调用根本不需要这些。
• 队头阻塞：HTTP/1.1一个连接同时只能处理一个请求，并发靠开多个连接，连接一多，服务端文件描述符和内存就吃紧。
• 连接开销：短连接要反复三次握手，keep-alive能缓解，但并发模型仍不够优雅。
• 契约偏弱：REST加JSON很灵活，但字段类型、必填项、版本兼容，往往靠文档和口头约定，服务一多，容易出现“字段对不上”。

一个抓包场景：压测时HTTP/1.1先撞墙

假设订单服务用REST暴露接口,你用wrk压测：

wrk -t8 -c200 -d30s http://order-svc:8080/api/order/1

同时抓包：

tcpdump -i eth0 port 8080 -nn -A

你会看到大量HTTP头部文本,以及多个TCP连接在反复建连，若换成gRPC，客户端可以复用一条HTTP/2连接，多路复用并发流，用grpcurl验证：

grpcurl -plaintext localhost:50051 list
grpcurl -plaintext -d '{"orderId":"A1"}' localhost:50051 OrderService/GetOrder

请求体是Protobuf二进制,头部用HPACK压缩。传输体积更小，解析通常更快，这就是内部调用偏爱RPC的直接原因。

微服务之间调用选gRPC好还是REST好？对比延迟、成本和治理

协议层差异

从表里能看出,gRPC不是“不用HTTP”，它跑在HTTP/2上，它只是把HTTP当成传输层，把REST那套文本语义换成了二进制RPC语义。

实操：用grpcurl验证gRPC服务

• 先看服务列表：grpcurl -plaintext localhost:50051 list
• 再看方法：grpcurl -plaintext localhost:50051 list OrderService
• 发请求：grpcurl -plaintext -d '{"orderId":"A1"}' localhost:50051 OrderService/GetOrder
• 看反射是否开启：若报错，检查服务端是否注册了reflection。

这些命令能直接验证服务是否可用,REST也能用curl验证，但字段类型和错误码要靠文档，gRPC的proto文件本身就是契约。

成本账：微服务RPC框架选型成本大概多少

成本不只是一台服务器多少钱,它至少分四块：

• 开发成本：团队要学proto、代码生成、拦截器，熟悉REST的团队上手gRPC需要时间。
• 运维成本：要处理HTTP/2连接、负载均衡、健康检查、服务网格sidecar，调试比curl麻烦。
• 改造成本：老系统从REST迁到gRPC，要改客户端、网关、监控、日志链路。
• 硬件成本：高频调用下，RPC通常更省连接和带宽，低频调用下，省下来的钱可能抵不过学习成本。

业内专家指出,协议选型没有银弹，日调用量不大、团队偏小、接口变动频繁时，HTTP/2加JSON往往更划算，调用量大、延迟敏感、需要双向流时，gRPC更合适。

同城双活机房服务调用延迟怎么优化？

北京上海同城双活服务调用延迟对比的常见误区

• 同城双活不等于零延迟,两个机房之间仍有网络RTT，只是比跨地域小。
• 跨地域调用别硬扛,北京调上海，物理距离决定延迟下限，协议优化只能减少额外开销，不能消除光速限制。
• 就近路由比协议更重要,北京的服务优先调北京机房，上海的服务优先调上海机房。
• 超时和重试要克制,跨机房重试可能放大雪崩。

可落地操作：Kubernetes + gRPC 就近调用

• 开启拓扑感知路由,让Service优先把流量转到同可用区或同机房的Pod。
• 使用Headless Service，让客户端拿到Pod IP，自己做负载均衡。
• 设置合理的超时,比如内部查询接口超时设短一些，避免线程池被拖死。
• 用服务网格做流量治理,Sidecar可以统一处理重试、熔断、超时。
• 检查端点分布：

kubectl get endpoints order-svc -o wide
kubectl describe svc order-svc

如果发现端点全在上海,而调用方在北京，那协议再快也没用，先修拓扑，再谈协议，行业共识认为，分布式系统里，网络分区和延迟是设计前提，不是事后补丁。

哪些场景反而应该继续用HTTP

对外API和管理接口

• 开放平台给第三方用,HTTP/JSON最省沟通成本。
• 管理后台、运营接口，调用频率低，可读性优先。
• Webhook回调,HTTP是事实标准。
• 需要CDN、缓存、API网关鉴权时，HTTP生态最成熟。

团队栈和可观测性

• 团队没有gRPC经验,强行上马会拖慢交付。
• 现有监控基于HTTP状态码、日志基于文本，换协议要重做可观测性。
• 调试时curl一把梭,比grpcurl更顺手。

折中方案：HTTP/2 + JSON 或 Connect

如果既想要HTTP生态,又想要多路复用，可以选HTTP/2加JSON，gRPC生态里的Connect协议也支持HTTP/1.1和HTTP/2，兼容curl和浏览器，它保留了proto契约，又降低了调试门槛，对多数中小团队，这是从REST过渡到RPC的务实路径。

Q&A：服务器调用为什么不用HTTP？

服务器调用为什么不用HTTP？不是绝对，关键看内外网边界

外部调用通常继续用HTTP/HTTPS，内部调用若追求低延迟、高吞吐、强契约和流式，就倾向RPC、消息队列或自定义TCP，传统HTTP/1.1 REST在内部高频场景下开销偏大，gRPC本身基于HTTP/2，所以准确说法是：不是不用HTTP，而是不局限于HTTP/1.1 REST。

微服务之间调用选gRPC好还是REST好？中小团队怎么选

看调用量和团队能力,日调用量不大、接口以增删改查为主、团队熟悉JSON，优先REST或HTTP/2加JSON，调用量大、延迟敏感、需要双向流、多语言客户端，选gRPC，若已有服务网格和proto治理体系，gRPC的长期收益更明显。

同城双活下服务器调用协议怎么选，HTTP/2够用吗

同城双活里,HTTP/2通常够用，它有多路复用和头部压缩，比HTTP/1.1更适合内部调用，若还要双向流、强类型契约和跨语言代码生成，再上gRPC，协议只是其中一层，就近路由、超时控制、熔断限流和容量规划才是决定稳定性的关键。

服务器调用不是“HTTP不能用”，而是不同场景要选不同工具，对外用HTTP保证通用，内部用RPC或消息队列换取效率，同城双活先做就近路由再谈协议优化，这才是更接近工程现实的答案。