帝国网站的互动专栏怎么做,wordpress 模板使用,进销存软件,东莞网站建设 牛魔网如何在.NET Core中为gRPC服务设计消息使用协议缓冲区规范定义gRPC服务非常容易#xff0c;但从需求转换为.NET Core#xff0c;然后管理服务的演变时#xff0c;需要注意几件事。创建gRPC服务的核心是.proto文件#xff0c;该文件以与语言无关的格式描述了该服务。使用.pro… 如何在.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 intProtoBuf的int64变为longfixed32变为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.Add200;
您可以使用LINQ方法例如First或按位置访问RepeatedField中的项目。可以正常工作例如uint tranAmount cr.CreditLimit [1];
ProtoBuf还支持称为map的Dictionary-type集合该集合允许您为字典的键和值指定类型。我的客户消息可能会使用“友好名称”来跟踪客户的各种信用卡以定义一个字典该字典包含密钥“彼得卡”“我的旅行卡”和值信用卡号的字符串message CustomerResponse {int32 custId 1;mapstring, 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的数字。我是否也可以建议如果您想使用这些数字那么您将遇到在本专栏中我无法解决的问题。真的。别那样做。References[1] Protocol Buffers规范中: https://developers.google.com/protocol-buffers/docs/proto3#scalar[2] 规范: https://developers.google.com/protocol-buffers/docs/proto3[3] 较早的概述中: https://visualstudiomagazine.com/articles/2019/08/28/grpc-web-services.aspx[4] 那样: https://visualstudiomagazine.com/articles/2019/08/28/grpc-web-services.aspx[5] 标量类型说明: https://developers.google.com/protocol-buffers/docs/proto3#scalar
