GRPC 消息结构

Golang不知道大家是否熟悉？今天我将给大家介绍《GRPC 消息结构》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

我正在将遗留应用程序（微服务和整体应用程序的一部分）迁移到使用 grpc。整个代码库目前都在 go 中。

我已经开始对我的消息进行建模，它们看起来与我在应用程序代码中使用的结构非常相似。我定义了两次相同的对象似乎很奇怪，但使用消息对象作为核心结构也似乎很奇怪。不过，似乎我会有大量的内存密集型数据整理。下面是消息和结构的示例以及它们的相似之处。

对于决定如何对我的消息进行建模，有什么建议/最佳实践吗？它们应该与我的核心结构保持一致吗？我是否应该不关心从 golang 结构到消息的所有编组？

如果我问这样一个基本问题，请原谅我，因为我对协议缓冲区和 grpc 非常陌生。

消息原型定义：

message profile {
    string uid = 1;
    string contactemail = 2;
    google.protobuf.timestamp dateofbirth = 3;
    float weightinkilos = 4;
    string gender = 5;
    string unit = 6;
    string currentstatus = 7;
    string country = 8;
    string experiencetype = 9;
    google.protobuf.timestamp datejoined = 10;
    repeated ability abilities = 11;
    repeated role roles = 12;
    repeated termsandconditionsacceptance termsandconditionsacceptances = 13;
    string timezone = 14;
    repeated baselinetestresults baselinetests =15;
    //excluded updateddate as other domains shouldn't need it
    string firstname =16;
    string lastname =17;
    string displayname = 18;
    string state = 19;
    repeated google.protobuf.any preferences = 20;
    thresholds thresholds = 21;
    string stripecustomerid = 22;
}

结构定义：

type Profile struct {
    UID                           string                         `json:"UID" firestore:"UID"`
    ContactEmail                  string                         `json:"ContactEmail,omitempty" firestore:"ContactEmail"`
    DateOfBirth                   time.Time                      `json:"DateOfBirth,omitempty" firestore:"DateOfBirth"`
    WeightInKilos                 float64                        `json:"WeightInKilos,omitempty" firestore:"WeightInKilos"`
    Gender                        string                         `json:"Gender,omitempty" firestore:"Gender"`
    Unit                          string                         `json:"Unit,omitempty" firestore:"Unit"`
    CurrentStatus                 string                         `json:"CurrentStatus,omitempty" firestore:"CurrentStatus"`
    Country                       string                         `json:"Country,omitempty" firestore:"Country"`
    ExperienceType                string                         `json:"ExperienceType,omitempty" firestore:"ExperienceType"`
    DateJoined                    time.Time                      `json:"DateJoined,omitempty" firestore:"DateJoined"`
    Abilities                     []Ability                      `json:"Abilities,omitempty" firestore:"Abilities"`
    Goals                         Goals                          `json:"Goals,omitempty" firestore:"Goals"`
    Roles                         []Role                         `json:"Roles,omitempty" firestore:"Roles"`
    TermsAndConditionsAcceptances []TermsAndConditionsAcceptance `json:"TermsAndConditionsAcceptances,omitempty" firestore:"TermsAndConditionsAcceptances"`
    TimeZone                      string                         `json:"TimeZone,omitempty" firestore:"TimeZone"`
    BaselineTests                 []BaselineTestResults          `json:"BaselineTests,omitempty" firestore:"BaselineTests"`
    UpdatedDate                   time.Time                      `json:"UpdatedDate,omitempty" firestore:"UpdatedDate"`
    FirstName                     *string                        `json:"FirstName,omitempty" firestore:"FirstName"`
    LastName                      string                         `json:"LastName,omitempty" firestore:"LastName"`
    DisplayName                   string                         `json:"DisplayName,omitempty" firestore:"DisplayName"`
    State                         string                         `json:"State"`
    Preferences                   map[string]interface{}         `json:"Preferences"`
    Thresholds                    Thresholds                     `json:"Thresholds"`
    StripeCustomerID              string                         `json:"-"` //Tells it to ignore exporting
}

解决方案

虽然是一个非常基本的问题，但也是一个非常好的问题。人们通常会跳过它，并且随着代码库的增长，以后不得不与它作斗争。

当然，当处理请求所需的数据在消息中完全可用时，使用消息作为核心结构将会很有帮助。但在您需要从其他来源获取数据的情况下就没有帮助了。

通常消息数据由边界层/控制器处理，边界层/控制器进一步使用多个服务来创建响应。因此，服务层/逻辑层独立于控制器层，消息结构和核心结构也应该如此。

始终尝试减少层之间的耦合，以便它们可以重用。

因此，如果您有一个处理数据库的层，您也应该有单独的结构。

您不需要在应用代码中创建结构。只需使用 proto 文件的消息即可。 这是 Go 中 GRPC 的快速入门。

本篇关于《GRPC 消息结构》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！