17-Ajax，服务之间的调用为啥不直接用HTTP而用RPC

'# 17-Ajax，服务之间的调用为啥不直接用HTTP而用RPC

一、背景与问题

在微服务架构中，服务间通信是核心问题之一。虽然HTTP协议是互联网最通用的通信方式，但越来越多的系统开始采用远程过程调用（RPC）作为服务间通信的首选方案。这种转变背后隐藏着深刻的工程哲学和技术选择。

本文将从底层原理出发，剖析RPC与HTTP在服务间通信中的差异，并结合实际开发场景探讨其适用场景和最佳实践。

二、基本原理

1. HTTP协议的局限性

HTTP/1.1 是基于文本的协议，其设计初衷是面向人类可读的通信。这种设计在服务间通信中存在三个主要问题：

• 协议冗余：每个请求必须包含完整的 HTTP 头（如 Host, User-Agent, Content-Type 等），这些信息在服务间通信中往往不需要
• 数据序列化：需要通过 JSON 或 XML 手动序列化数据，效率较低
• 语义模糊：RESTful 接口的动词（GET/POST/PUT/DELETE）与方法调用的语义不匹配

2. RPC 的核心思想

RPC（Remote Procedure Call）的核心思想是：让服务调用像本地方法调用一样自然。其关键特征包括：

• 协议优化：使用二进制协议减少传输开销
• 序列化优化：采用高效的序列化方式（如 Protobuf, Thrift）
• 语义明确：通过接口定义文件（IDL）明确方法签名和参数

三、环境准备

以 Go 语言为例，我们使用 gRPC 作为 RPC 实现。需要准备：

• Go 1.18+
• protoc 3.21+
• Docker（用于测试）

四、核心实现

1. 定义接口（IDL）

使用 Protocol Buffers 定义服务接口：

// service.proto
syntax = "proto3";

package order;

service OrderService {
    rpc CreateOrder (OrderRequest) returns (OrderResponse);
}

message OrderRequest {
    string user_id = 1;
    repeated string items = 2;
}

message OrderResponse {
    string order_id = 1;
    int32 status = 2;
}

关键点：

• 使用 rpc 关键字定义远程方法
• 消息类型需要明确字段编号（field number）

2. 生成代码

protoc --go-grpc-out=. --go-out=. service.proto

生成的代码包含：

• 服务接口定义
• 消息结构体
• 服务服务器接口

3. 实现服务端

// server.go
package main

import (
    "context"
    "fmt"
    "log"
    "net"

    "google.golang.org/grpc"
    "google.golang.org/grpc/reflection"
    pb "github.com/yourname/order/service"
)

type server struct {
    pb.UnimplementedOrderServiceServer
}

func (s *server) CreateOrder(ctx context.Context, req *pb.OrderRequest) (*pb.OrderResponse, error) {
    fmt.Printf("Received order for user %s with items %v\n", req.UserId, req.Items)
    
    // 模拟业务逻辑
    orderID := fmt.Sprintf("ORD-%d", time.Now().UnixNano())
    return &pb.OrderResponse{
        OrderId: orderID,
        Status:  200,
    }, nil
}

func main() {
    lis, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("failed to listen: %v", err)
    }

    s := grpc.NewServer()
    pb.RegisterOrderServiceServer(s, &server{})
    reflection.Register(s)

    fmt.Println("Server started on port 50051")
    if err := s.Serve(lis); err != nil {
        log.Fatalf("failed to serve: %v", err)
    }
}

关键点：

• 实现 UnimplementedOrderServiceServer 接口
• 通过 grpc.NewServer 创建服务端
• 使用 reflection.Register 支持服务发现

五、完整案例

1. 服务端与客户端架构

+-------------------+        +-------------------+
|   Order Service   |        | Inventory Service |
+-------------------+        +-------------------+
        |                            |
        |                            |
        v                            v
+-------------------+        +-------------------+
|      gRPC         |        |      gRPC         |
+-------------------+        +-------------------+
        |                            |
        |                            |
        v                            v
+-------------------+        +-------------------+
|   Client App      |        |   Client App      |
+-------------------+        +-------------------+

2. 客户端实现

// client.go
package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "google.golang.org/grpc"
    pb "github.com/yourname/order/service"
)

func main() {
    conn, err := grpc.Dial(":50051", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("did not connect: %v", err)
    }
    defer conn.Close()

    client := pb.NewOrderServiceClient(conn)
    ctx, cancel := context.WithTimeout(context.Background(), time.Second)
    defer cancel()

    resp, err := client.CreateOrder(ctx, &pb.OrderRequest{
        UserId: "user123",
        Items:  []string{"itemA", "itemB"},
    })

    if err != nil {
        log.Fatalf("could not create order: %v", err)
    }

    fmt.Printf("Order created: %s\n", resp.OrderId)
}

3. 性能对比测试

使用 JMeter 做基准测试（假设场景：1000 个并发请求）：

六、源码解析

1. gRPC 的通信流程

graph TD
    A[客户端] --> B[序列化]
    B --> C[发送请求]
    C --> D[服务端]
    D --> E[反序列化]
    E --> F[调用服务]
    F --> G[返回响应]
    G --> H[反序列化]
    H --> I[客户端]

关键点：

• 使用 Protobuf 自动生成序列化代码
• 服务端和客户端共享相同的 IDL
• 通过流式处理支持复杂交互

2. 服务发现机制

// 服务发现示例
import (
    "google.golang.org/grpc/credentials/insecure"
    "google.golang.org/grpc/resolver"
)

type dnsResolver struct {
    name string
}

func (r *dnsResolver) Resolve(ctx context.Context, target resolver.ResolveRequest) (resolver.ResolveResult, error) {
    // 实现 DNS 解析逻辑
    return resolver.ResolveResult{
        Addresses: []resolver.Address{
            {Addr: "127.0.0.1:50051"},
        },
    }, nil
}

七、进阶使用

1. 流式通信

// 流式 RPC 示例
func (s *server) StreamOrders(stream pb.OrderService_StreamOrdersServer) error {
    for {
        req, err := stream.Recv()
        if err == io.EOF {
            break
        }
        if err != nil {
            return err
        }
        // 处理订单流
    }
    return nil
}

2. 带身份验证的 RPC

// 自定义认证中间件
func (s *server) CreateOrder(ctx context.Context, req *pb.OrderRequest) (*pb.OrderResponse, error) {
    user, ok := md.Get(ctx, "user_id")
    if !ok {
        return nil, status.Error(codes.Unauthenticated, "missing authentication")
    }
    // 后续业务逻辑
}

八、性能与工程实践

1. 性能优化方案

2. 安全实践

• 使用 TLS 加密传输
• 实现 JWT 认证
• 使用 mTLS 实现双向认证
• 配置访问控制策略

// 配置 TLS
creds, _ := credentials.NewServerTLSFromFile("server.crt", "server.key")
server := grpc.NewServer(grpc.Creds(creds))

九、常见问题与踩坑

1. 常见错误

2. 典型陷阱

• 错误地使用 HTTP 协议模拟 RPC
• 忽略服务版本控制
• 忽视服务发现机制
• 没有进行压力测试

十、最佳实践

1. 推荐方案

• 使用 gRPC/Thrift/Protobuf 等专用协议
• 对服务接口进行版本控制
• 配置服务发现和负载均衡
• 实现完善的监控和日志系统
• 对关键服务进行性能测试

2. 技术选型建议

十一、总结

在微服务架构中，RPC 相比 HTTP 协议具有显著优势，特别是在性能、语义明确性和开发效率方面。通过使用 Protocol Buffers 等专用协议，可以实现更高效的通信。但需要根据具体场景选择合适的技术方案：对于内部服务间通信推荐使用 gRPC，而跨域或需要浏览器兼容的场景则更适合 REST/HTTP。

在实际开发中，需要充分考虑服务的可维护性、安全性以及扩展性。通过合理的架构设计和技术选型，可以构建出高效、稳定、可扩展的分布式系统。记住：技术选型不是一成不变的，需要根据业务需求和团队能力做出动态调整。