1.1.1 服务定义

gRPC 使用 protocol buffers 作为 IDL 来定义服务接口。protocol buffers是语言中立、平台无关、实现结构化数据序列化的可扩展机制 。服务接口定义在 proto 文件中指定，也就是在扩展名为“.proto”的普通文本文件中。我们要按照普通的 protocol buffers 格式来定义 gRPC 服务，并将RPC 方法参数和返回类型指定为 protocol buffers 消息。因为服务定义是protocol buffers 规范的扩展，所以可以借助特殊的 gRPC 插件来根据proto 文件生成代码。

第 4 章会详细介绍 protocol buffers 的基本原理，现在可将其看作一种数据序列化机制。

在示例场景中，ProductInfo 服务接口可以使用代码清单 1-1 中的protocol buffers 来定义，其中涉及远程方法调用、相关输入参数和输出参数以及这些参数的类型定义（或消息格式），这些也是ProductInfo 服务定义的组成部分。

// ProductInfo.proto
syntax = "proto3"; ➊
    package ecommerce; ➋
    service ProductInfo { ➌
    rpc addProduct(Product) returns (ProductID); ➍
    rpc getProduct(ProductID) returns (Product); ➎
}
message Product { ➏
    string id = 1; ➐
    string name = 2;
    string description = 3;
}
message ProductID { ➑
    string value = 1;
}

❶ 服务定义首先声明所使用的 protocol buffers 版本（proto3）。
❷ 用来防止协议消息类型之间发生命名冲突的包名，该包名也会用来生成代码。
❸ 定义 gRPC 服务的接口。
❹ 添加商品的远程方法，该方法会返回商品 ID 作为响应。
❺ 基于商品 ID 获取商品的远程方法。
❻ 定义 Product 的消息格式或类型。
❼ 保存商品 ID 的字段（名–值对），具有唯一的字段编号，该编号用来在二进制格式消息中识别字段。
❽ 用于商品标识号的用户定义类型。

服务就是可被远程调用的一组方法，比如 addProduct 方法和getProduct 方法。每个方法都有输入参数和返回类型，既可以被定义
为服务的一部分，也可以导入 protocol buffers 定义中。

输入参数和返回参数既可以是用户定义类型，比如 Product 类型和ProductID 类型，也可以是服务定义中已经定义好的 protocol buffers 已知类型。这些类型会被构造成消息，每条消息都是包含一系列名–值对信息的小型逻辑记录，这些名–值对叫作字段。这些字段都是具有唯一编号的名–值对（如 string id = 1），在二进制形式消息中，可以用编号来识别相应字段。

该服务定义会被用来构建 gRPC 应用程序的服务器端和客户端。1.1.2 节将介绍 gRPC 服务器端的实现细节。