gRPC阅读日记（三）
普通RPC
先来看看简单gRPC的实现，GetFeature处理单点消息的请求，并返回相应点的特征信息。
func (s *routeGuideServer) GetFeature(ctx context.Context, point *pb.Point) (*pb.Feature, error) { for _, feature := range s.savedFeatures { if proto.Equal(feature.Location, point) { return feature, nil } } // No feature was found, return an unnamed feature return &pb.Feature{Location: point}, nil }
该方法需要两个参数，一个是给rpc的上下文处理器，另一个就是来自客户端的point消息，也就是现在我们在.proto文件中预定义好的请求类型。返回也是先前定义的feature消息，相应类型，以及error。
从实现中可以看到，该RPC是将取到的点，与自己的数据库中的信息做比对，如果有则返回该点的内容且error为nil，如果没有则返回该点，error为nil。
服务端的流式RPC
服务侧的流式RPC会相应多条数据给客户端。
func (s *routeGuideServer) ListFeatures(rect *pb.Rectangle, stream pb.RouteGuide_ListFeaturesServer) error { for _, feature := range s.savedFeatures { if inRange(feature.Location, rect) { if err := stream.Send(feature); err != nil { return err } } } return nil }
从实现上看，这次收到的是带有经纬范围的请求，所以服务端通过流式相应返回多条数据
如果查找到范围内的数据则返回，发送失败则返回错误，如果没有查找到返回nil
更加特殊的是，相比较于简单的请求类型，和相应类型，这次使用了更加复杂的请求对象，以及另一个特殊的对象RouteGuide_ListFeaturesServer去写响应，因为我们需要使用他的方法stream.send()
还有一点不同在于，在上一个普通的rpc中，我们返回nil error去告诉客户端，响应已经写完结束了，但在这次如果send中发生了任何错误，我们就会返回非nil的error回去，gRPC层将会将它该错误翻译成恰当的rpc状态然后发送回去。
