[开发]sdk,api,rpc(区别和联系)

import_random
41 阅读4分钟

作为程序员，理解 SDK、API 和 RPC 的区别与联系至关重要。它们不是并列关系，而是不同层次和维度的概念。让我为你详细拆解。

一、核心概念定义

1. API（应用程序编程接口）

  • 是什么：一组明确定义的规则和规范，用于不同软件组件之间的交互
  • 核心：接口契约，定义了“能做什么”，但不关心“如何实现”
  • 表现形式：函数签名、HTTP端点、接口定义
  • 例子：
    • Java 的 List 接口
    • Twitter 的 REST API（GET /2/tweets/{id}）
    • 操作系统的系统调用

2. SDK（软件开发工具包）

  • 是什么：一套工具集合，帮助开发者针对特定平台、服务或框架进行开发
  • 核心：工具箱，包含API实现、文档、示例代码、调试工具等
  • 表现形式：库文件、编译器、文档、IDE插件
  • 例子：
    • Android SDK
    • AWS SDK for Python
    • Unity游戏开发SDK

3. RPC（远程过程调用）

  • 是什么：一种技术范式/通信机制，让程序能像调用本地函数一样调用远程函数
  • 核心：网络通信模式，抽象了远程调用的复杂性
  • 表现形式：gRPC、Apache Thrift、JSON-RPC
  • 例子：
    • gRPC服务调用
    • 微服务间的内部通信

二、生动比喻

想象你要做一顿大餐：

  • API = 菜单

    • 告诉你有什么菜可以点（功能）
    • 每道菜需要什么原料（参数）
    • 会做成什么样（返回结果）

  • SDK = 整个厨房工具包

    • 包含菜单（API文档）
    • 预处理的食材（库文件）
    • 菜谱（示例代码）
    • 厨具（编译工具）
    • 甚至有个厨师助手帮你处理复杂步骤

  • RPC = 呼叫服务员的方式

    • 挥手叫服务员（同步调用）
    • 按服务铃（异步调用）
    • 对讲机直接通知厨房（更直接的通信）

三、具体区别对比

维度APISDKRPC
本质接口规范工具集合通信机制
范围相对狭窄，特定功能接口广泛，完整开发支持中等，关注远程调用
包含关系SDK包含API包含API、工具等可实现API
抽象层次中等（定义交互）高（一站式解决方案）低（网络通信细节）
必须联网？不一定（本地API不需要）不一定必须（远程调用）

四、实际关系图

┌─────────────────────────────────────────┐
│                SDK                      │
│                                         │
│  ┌──────────┐  ┌──────────┐  ┌──────┐  │
│  │   API    │  │ 工具/库   │  │ 文档 │  │
│  │ (接口定义)│  │(实现代码) │  │      │  │
│  └──────────┘  └──────────┘  └──────┘  │
│                                         │
│  ┌──────────────────────────────────┐  │
│  │       可能的实现方式之一：        │  │
│  │             RPC                  │  │
│  │    (如gRPC、Thrift等协议)        │  │
│  └──────────────────────────────────┘  │
└─────────────────────────────────────────┘

五、程序员如何区分与选择

场景1：我要调用微信登录功能

  • 选择SDK：使用微信官方SDK
    • 原因：需要完整的认证流程、UI组件、错误处理
    • 包含：API客户端、UI组件、示例代码
  • 选择API：直接调用微信OAuth 2.0 API
    • 原因：轻量级需求，不想引入大SDK
    • 需要自己处理HTTP请求、token管理

场景2：公司内部微服务通信

  • 选择RPC：使用gRPC
    • 原因：高性能、强类型、双向流
    • 内部服务对延迟敏感
  • 对比REST API：
    • RPC：函数调用思维，userService.GetUser(id)
    • REST：资源操作思维，GET /users/{id}

场景3：开发Android应用

  • 必须用SDK：Android SDK
    • 包含：Android API（Activity、Fragment等）
    • 工具：ADB、模拟器、性能分析器
    • 无法绕过，是开发基础

六、技术栈示例

// 层次关系示例
// 1. API层（接口定义）
public interface PaymentService {
    PaymentResult processPayment(PaymentRequest request);
}

// 2. RPC实现（通信机制）
// gRPC .proto 定义
service PaymentService {
    rpc ProcessPayment(PaymentRequest) returns (PaymentResponse);
}

// 3. SDK中的使用
public class PaymentSDK {
    private PaymentService api; // 基于RPC或HTTP实现的API客户端
    
    public PaymentSDK(String apiKey) {
        this.api = new PaymentClient(apiKey); // SDK初始化RPC客户端
    }
    
    public void makePayment(double amount) {
        // SDK提供简化接口，隐藏了RPC细节
        api.processPayment(createRequest(amount));
    }
}

七、常见组合模式

  1. 传统模式：API + SDK

    • 服务提供API规范
    • 同时发布各语言SDK方便调用

  2. 现代微服务：RPC + API Gateway

    • 内部使用gRPC/RPC通信
    • 对外暴露REST API（通过网关转换）

  3. 全栈方案：SDK包含所有

    • 如Firebase SDK：包含API客户端、RPC实现、本地工具

八、容易混淆的概念澄清

  • “RPC API”：这是合理的说法，指通过RPC方式暴露的API
  • “SDK的API”：SDK提供的编程接口
  • 三者不是三选一，而是协同工作：
    • SDK 包含 API的实现
    • RPC 实现 API的远程调用部分
    • API 定义 SDK和RPC应遵守的契约

总结建议

作为程序员，按这个思路区分：

  1. 先问目的：

    • 要开发完整应用？→ 看SDK
    • 要集成特定功能？→ 找API
    • 要解决服务间通信？→ 考虑RPC

  2. 检查现有架构：

    • 已有技术栈偏好什么？
    • 团队熟悉什么？

  3. 权衡复杂度：

    • SDK：方便但可能臃肿
    • 直接API：灵活但需自己造轮子
    • RPC：高效但需基础设施支持

记住这个核心：API是“菜单”，SDK是“厨房套装”，RPC是“传菜方式”。理解了这一层，你就能在实际工作中做出恰当的技术选择了。

avatar
文章
阅读
粉丝