You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shenyu.apache.org by midnight <ll...@163.com> on 2021/06/01 15:01:24 UTC
Re: Access gprc services in the gateway in a better way.
Hi eyeryone. Thank you for your active discussion. The final way to achieve this is to expose JSON wrap services at the shenyu-client-grpc module,
dynamically generate the method descriptors on the shenyu-plugin-grpc side, and then invoke the grpc service. The final code has been merged. Here is PR(https://github.com/dromara/shenyu/pull/1556).
At 2021-05-26 12:41:22, "midnight" <ll...@163.com> wrote:
Okay, I will continue to try, please give me some more time. Thanks again for giving me this opportunity.
在 2021-05-26 10:28:45，"XiaoYu" <xi...@apache.org> 写道：
>Hi midnight
>
>I am very sorry, my previous reply was wrong, I meant to support 5 .
>
>Just do it .. go on.
>
>midnight <ll...@163.com> 于2021年5月25日周二 下午9:43写道：
>
>> Hi, everyone. thanks for your discuss.
>>
>> I want to talk the 5 point.
>>
>> The shenyu-client-grpc module has already provided the json grpc service
>> that wrap the origin grpc service.
>>
>> If the request message and response message of the json service can be
>> dynamically constructed in the shenyu-plugin-grpc module, we may be able to
>> call the server.
>>
>> Currently, I haven't implemented this method yet, I don't know if it is
>> feasible.What about other people's views?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 在 2021-05-25 16:19:59，"XiaoYu" <xi...@apache.org> 写道：
>> >Hi
>> >
>> >Ok , I probably understand what you mean, so I agree with 4, what about
>> >other people's opinions?
>> >
>> >zhangleispring <zh...@gmail.com> 于2021年5月25日周二 下午4:04写道：
>> >
>> >> Because of the message in the protocol buffer is a series of key-value
>> >> pairs.
>> >> The binary version of message just uses the field number (field's number
>> >> and wire_type) as the key.
>> >> The name and declaration type of each field can only be determined by
>> >> referencing the definition of the message type (proto file) on the
>> decoding
>> >> side
>> >> So it is very difficult to deserialize and deserialize based on metadata
>> >>
>> >>
>> >>
>> >>
>> >> 在 2021年5月25日 15:20，XiaoYu<xi...@apache.org> 写道：
>> >>
>> >>
>> >> Hi , zhangleispring & wei liu 4. The client side reports the grpc
>> service
>> >> metadata to the registry center. Is this solution not feasible and what
>> is
>> >> the difficulty of it? thanks, wei liu <lw...@apache.org>
>> >> 于2021年5月25日周二 下午2:49写道： > 3. Upload the proto file in the background or
>> >> store it in the form of > metadata, and parse the proto generation
>> method
>> >> descriptor. > > > - > > It seems like a good idea > > > zhangleispring <
>> >> zhangleispring@gmail.com> 于2021年5月25日周二 下午2:28写道： > > > I've researched
>> >> apisix and enovy,They all upload proto files in the > > gateway or
>> generate
>> >> them through scripts. > > I think this is a feasible way > > > > > > >
>> > >
>> >> > > > > > 在 2021年5月25日 12:57，midnight<ll...@163.com> 写道： > > > > > >
>> >> Hello everyone. There are still some problems with the way the > >
>> >> shneyu-gateway connects to grpc. The shneyu-plugin-grpc and > >
>> >> shneyu-client-grpc modules need to dependency on the shneyu-common >
>> >> module. > > Is there any better way to implement grpc service access?
>> The
>> >> methods > > collected are: 1. Obtain the descriptor by reflect, and then
>> >> call the > > service, but there is one more rpc call. 2. Simulate the
>> grpc
>> >> protocol, > but > > it is more difficult, and the generated class is too
>> >> complicated. 3. > Upload > > the proto file in the background or store
>> it
>> >> in the form of metadata, and > > parse the proto generation method
>> >> descriptor. 4. The client side reports > > the grpc service metadata to
>> the
>> >> registry center. 5. Define the same > proto > > file on the plugin and
>> the
>> >> client side, and the client side exposes the > > service by the proto
>> file.
>> >> Welcome everyone to discuss the above methods, > > or express your
>> point,
>> >> in a better way to access gprc service in the > > gateway. >
>>
Re: Access gprc services in the gateway in a better way.
Posted by XiaoYu <xi...@apache.org>.
Hi midnight
Is good job. Thank you for your important contribution to grpc plugin!
midnight <ll...@163.com> 于2021年6月1日周二 下午11:01写道：
> Hi eyeryone. Thank you for your active discussion. The final way to
> achieve this is to expose JSON wrap services at the shenyu-client-grpc
> module,
>
> dynamically generate the method descriptors on the shenyu-plugin-grpc
> side, and then invoke the grpc service. The final code has been merged.
> Here is PR(https://github.com/dromara/shenyu/pull/1556).
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> At 2021-05-26 12:41:22, "midnight" <ll...@163.com> wrote:
>
> Okay, I will continue to try, please give me some more time. Thanks again
> for giving me this opportunity.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 在 2021-05-26 10:28:45，"XiaoYu" <xi...@apache.org> 写道：
> >Hi midnight
> >
> >I am very sorry, my previous reply was wrong, I meant to support 5 .
> >
> >Just do it .. go on.
> >
> >midnight <ll...@163.com> 于2021年5月25日周二 下午9:43写道：
> >
> >> Hi, everyone. thanks for your discuss.
> >>
> >> I want to talk the 5 point.
> >>
> >> The shenyu-client-grpc module has already provided the json grpc service
> >> that wrap the origin grpc service.
> >>
> >> If the request message and response message of the json service can be
> >> dynamically constructed in the shenyu-plugin-grpc module, we may be
> able to
> >> call the server.
> >>
> >> Currently, I haven't implemented this method yet, I don't know if it is
> >> feasible.What about other people's views?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 在 2021-05-25 16:19:59，"XiaoYu" <xi...@apache.org> 写道：
> >> >Hi
> >> >
> >> >Ok , I probably understand what you mean, so I agree with 4, what about
> >> >other people's opinions?
> >> >
> >> >zhangleispring <zh...@gmail.com> 于2021年5月25日周二 下午4:04写道：
> >> >
> >> >> Because of the message in the protocol buffer is a series of
> key-value
> >> >> pairs.
> >> >> The binary version of message just uses the field number (field's
> number
> >> >> and wire_type) as the key.
> >> >> The name and declaration type of each field can only be determined by
> >> >> referencing the definition of the message type (proto file) on the
> >> decoding
> >> >> side
> >> >> So it is very difficult to deserialize and deserialize based on
> metadata
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> 在 2021年5月25日 15:20，XiaoYu<xi...@apache.org> 写道：
> >> >>
> >> >>
> >> >> Hi , zhangleispring & wei liu 4. The client side reports the grpc
> >> service
> >> >> metadata to the registry center. Is this solution not feasible and
> what
> >> is
> >> >> the difficulty of it? thanks, wei liu <lw...@apache.org>
> >> >> 于2021年5月25日周二 下午2:49写道： > 3. Upload the proto file in the background
> or
> >> >> store it in the form of > metadata, and parse the proto generation
> >> method
> >> >> descriptor. > > > - > > It seems like a good idea > > >
> zhangleispring <
> >> >> zhangleispring@gmail.com> 于2021年5月25日周二 下午2:28写道： > > > I've
> researched
> >> >> apisix and enovy,They all upload proto files in the > > gateway or
> >> generate
> >> >> them through scripts. > > I think this is a feasible way > > > > > >
> >
> >> > >
> >> >> > > > > > 在 2021年5月25日 12:57，midnight<ll...@163.com> 写道： > > > > >
> >
> >> >> Hello everyone. There are still some problems with the way the > >
> >> >> shneyu-gateway connects to grpc. The shneyu-plugin-grpc and > >
> >> >> shneyu-client-grpc modules need to dependency on the shneyu-common >
> >> >> module. > > Is there any better way to implement grpc service access?
> >> The
> >> >> methods > > collected are: 1. Obtain the descriptor by reflect, and
> then
> >> >> call the > > service, but there is one more rpc call. 2. Simulate the
> >> grpc
> >> >> protocol, > but > > it is more difficult, and the generated class is
> too
> >> >> complicated. 3. > Upload > > the proto file in the background or
> store
> >> it
> >> >> in the form of metadata, and > > parse the proto generation method
> >> >> descriptor. 4. The client side reports > > the grpc service metadata
> to
> >> the
> >> >> registry center. 5. Define the same > proto > > file on the plugin
> and
> >> the
> >> >> client side, and the client side exposes the > > service by the proto
> >> file.
> >> >> Welcome everyone to discuss the above methods, > > or express your
> >> point,
> >> >> in a better way to access gprc service in the > > gateway. >
> >>
>
>
>
>
>
>