.NET Core中为gRPC服务设计消息文件 怎样在.NET Core中为gRPC服务设计消息文件（Proto）

如何在.NET Core中为gRPC服务设计消息

使用协议缓冲区规范定义gRPC服务非常容易，但从需求转换为.NET Core，然后管理服务的演变时，需要注意几件事。

创建gRPC服务的核心是.proto文件，该文件以与语言无关的格式描述了该服务。使用.proto文件，Visual Studio可以为您的服务生成基类（您只需编写特定于业务的代码），或者可以生成用于可靠访问服务的客户端类。

.proto文件必须符合Google的协议缓冲区规范（通常称为ProtoBuf）。原始文件的内容使您可以指定服务的接口。服务接口由两部分组成：

• 您的gRPC服务提供的方法
• 这些方法的参数和返回值的数据结构

您可以使用Protocol Buffers规范中[1]定义的标量类型来构建这些数据结构（在ProtoBuf中称为“消息”）。可用的类型包括布尔值，字符串，字节数组和各种数字类型（浮点型，整数型和长型）。没有日期或固定的十进制类型。在接下来的专栏中，我将向您展示如何添加时间戳类型。对于小数，您可以使用float ...并伴随着float带来的精度损失。

如果您要开始一个新项目，则要使用自2016年以来的proto3语法。但是，您必须在.proto文件的第一行“非空”行上明确指定proto3标准。引用规范[2]），否则将使用proto2规范解析您的.proto文件。指定您的文件使用proto3看起来像这样：

syntax = "proto3";

消息和C＃类

使用proto3规范，用于客户信息的消息格式可能如下所示：

message CustomerResponse {
  int32 custid = 1;
  string firstName = 2;
  string lastName = 3;
  int32 age = 4;
  fixed32 creditLimit = 5;
}

等号后的数字指定消息中字段的位置，从位置1开始（在我的示例中，firstName将是消息中的第二个字段）。这些数字在消息中必须是唯一的（即，您不能在同一位置使用两个字段）。您不必按数字顺序列出字段，但是如果您这样做的话，则可以更轻松地发现重复的字段编号（尽管Visual Studio将发现任何重复的编号，并在构建应用程序时将其报告在“错误列表”中）。如果需要，您也可以跳过职位。此定义仅使用奇数，例如：

message CustomerResponse {
  int32 custid = 1;
  string firstName = 3;
  string lastName = 5;
}

在.NET Core中，消息格式被转换为类，每个字段都成为与消息同名的类的属性。命名这些属性时，.NET Core还将字段名称的第一个字符转换为大写。因此，例如，我上一个示例中的custId字段将成为我代码中CustomerResponse类上的CustId属性。

在此过程中，还得删除字段名称中的所有下划线，并且将以下字母大写（即，Last_name字段名称变为LastName属性）。

该过程还涉及将.NET类型映射到ProtoBuf类型（例如，ProtoBuf int32变为.NET int，ProtoBuf的int64变为long，fixed32变为uint），这需要向.NET Core添加一些新类。例如，ProtoBuf支持字节数组，其类型为字节。名为ByteString的新.NET数据类型支持该字段类型。要加载ByteString，请使用ByteString类的静态CopyFrom方法，并传递一个字节数组，如下所示：

byte[] bytes = new byte[1000];
cr.Valid = ByteString.CopyFrom(bytes);

要从ByteString检索字节数组，请使用对象的CopyTo方法，并传递要将字节复制到的数组和起始位置：

cr.Valid.CopyTo(bytes,0);

数组和字典

您也可以使用【repeated】的关键字将集合包括在定义中（在ProtoBuf中，不是集合的字段称为“单数”）。如果我的客户消息需要一组重复的交易金额，则可以指定如下字段：

message Customer {
   int32 id = 1;
   repeated fixed32 transactionAmounts = 4;

重复的字段在转换为类的属性时，也使用新的类型：Google.Protobuf.RepeatedField。例如，我的示例将生成Google.Protobuf.RepeatedField（无符号整数）的属性。您可以使用{}语法来初始化数组，如下所示：

CustomerResponse cr = new CustomerResponse
            {
                CreditLimit = {10, 15, 100}    
            };

您可能更可能使用其各种Add方法将项目放入集合中：

cr.CreditLimit.Add（200）;

您可以使用LINQ方法（例如First（））或按位置访问RepeatedField中的项目。可以正常工作，例如：

uint tranAmount = cr.CreditLimit [1];

ProtoBuf还支持称为map的Dictionary-type集合，该集合允许您为字典的键和值指定类型。我的客户消息可能会使用“友好名称”来跟踪客户的各种信用卡，以定义一个字典，该字典包含密钥（“彼得卡”，“我的旅行卡”）和值（信用卡号）的字符串）：

message CustomerResponse {
  int32 custId = 1;
  map<string, string> cards = 2;

有趣的是，在Visual Studio 2019预览版中，编辑器不会像其他类型一样突出显示map对象（尽管编译得很好）。

相应的属性将为Google.Protobuf.Collections.MapField类型，您可以通过将其Add方法传递给键和一个值来加载它，就像其他任何Dictionary一样。

管理变更

上线后（客户端开始使用它）更改.proto文件相对容易。例如，您可以将具有新位置编号的字段添加到服务器端软件使用的.proto文件中，而不会打扰仍在使用该文件的早期版本的客户端：客户端只是忽略未在其.proto文件中列出的字段。

同样，在相反的情况下（当服务器.proto文件没有客户端的.proto字段具有的字段时），客户端只会发现服务器未发送的属性被设置为其默认值。顺便说一句，在服务器的.proto文件中定义的，未在客户端的.proto文件中定义的字段仍会发送到客户端，但是.NET不能提供一种方便的方式来访问它（至少现在还没有）。

确实，随着服务的发展和修改其.proto文件，您仅应遵守两个规则：

• 不要更改现有字段的位置编号
• 不要回收职位编号（即不要用新的字段3替换过时的字段3）

但是，从.proto文件生成的属性不可为空，因此，如果未将属性设置为值，则它将被设置为其默认值。这意味着数字被设置为0；数字被设置为0。将string设置为string.Empty（长度为零的字符串）；布尔变成虚假的；ByteString属性默认为ByteString对象，其IsEmpty属性设置为true；并且RepeatedField和MapField属性均默认为其对应的对象，每个对象均不包含任何项目，并且其Count属性设置为0。

由于这种行为，存在从服务的.proto文件中删除字段并且不更新所有客户端（或者只是在服务器上生成响应时未在对象上设置属性）的危险。危险是客户端无法区分未使用的字段和已设置为其默认值的属性之间的区别。如果将我的客户的有效属性设置为false，则客户端将无法确定客户是否无效或服务器是否不再生成该字段。

您可能需要考虑将属性初始化为某个“不合理的”值（例如，数字为-1），以便客户端可以区分设置为默认值的属性和已删除的字段之间的区别。因为这对于布尔值是不可能的（布尔值没有不合理的值），所以您要特别警惕删除（甚至不再使用）布尔类型的字段。

效率和局限性

正如我在较早的概述中[3]所讨论的那样[4]，gRPC服务的功能之一是它们的消息比基于HTTP的（RESTful）服务小得多。如果您真的想利用这种效率，请注意位置1到15仅需要一个字节的额外开销（即超出存储值的数据），而位置16到2047则需要两个字节。将消息格式保持在16位以下似乎是个好主意。

有关将数据打包到尽可能小的空间的选择类型方面的其他效率提示，请参阅规范中的标量类型说明[5]。

顺便说一句，您不能使用以下任何一种作为字段位置编号：负数，0、19,000到19,999（保留给ProtoBuf使用）或大于536,870,911的数字。我是否也可以建议，如果您想使用这些数字，那么您将遇到在本专栏中我无法解决的问题。

真的。别那样做。