这是一个创建于 1969 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务端查询数据-->转成 grpc model-->响应给客户端-->客户端吧 grpc 解析成可序列化 model
把我整吐了，太浪费时间了，核心逻辑代码量都没这些转换的代码多，Java 程序员千万别用 grpc，还是老老实实 dubbo 等
纯吐槽，不知道有没有用过 grpc 的老铁有好的技巧分享一下
 |
1
qiyuey 2019-08-08 12:10:10 +08:00 via Android
IDL 的 RPC 都有这些问题
|
 |
2
bobuick 2019-08-08 12:12:47 +08:00
grpc 跨语言上优势. dubbo 实现一份, 客户端, 服务端都能用来解码和传输层协议通用. 你各自来一份 python, go, cpp, php 你试试看 dubbo 会还有多少事需要做进去的
|
 |
3
Raymon111111 2019-08-08 12:39:58 +08:00
那想跨语言没别的办法了吧?
|
 |
4
index90 2019-08-08 13:15:05 +08:00  2
你用什么框架不需要序列化和反序列化啊？
不明白你究竟面临什么问题。我猜，可能你原来的逻辑代码依赖了你自定义的 Message 对象，现在要转成 ProtoMessage 而已。 |
 |
5
mango88 2019-08-08 14:09:51 +08:00
全部 json 一把梭
|
 |
6
brucewuio 2019-08-08 14:12:01 +08:00
跨语言就方便咯
|
 |
7
Cbdy 2019-08-08 14:12:56 +08:00 via Android
json 一把梭
|
 |
8
guolaopi 2019-08-08 14:14:53 +08:00
@index90 +1.
而且转成 grpc model 和客户端把 grpc 解析成可序列化 model 的文件不都是 grpc 生成的吗？客户端服务端直接调用就行了？还是说 java 和 C#不一样， 这些玩意儿要手写？ |
 |
9
linxl 2019-08-08 14:15:56 +08:00
grpc 是服务端写起来麻烦点(不过我也没用过别的 rpc), 客户端使用起来是真舒服, 只要服务端把 protobuf 注释写好点(当作客户端的文档), 基本上也不用再写什么文档了.
|
 |
10
wysnylc 2019-08-08 14:59:15 +08:00
spring cloud 是推荐使用 Restful
|
 |
11
chendy 2019-08-08 15:04:53 +08:00
RPC 都是这个流程吧，而且有 IDL 还能生成，裸 http+json 的还要自己写数据类
核心逻辑没有这些多可能是因为业务简单吧，业务简单业务代码可能都没有 SQL 代码多… |
 |
12
passerbytiny 2019-08-08 15:06:24 +08:00
请用 RESTful，或者叫做原始 HTTP。
|
 |
13
dengtongcai OP |
|
14
passerbytiny 2019-08-08 15:10:20 +08:00
好吧，我粗略查了一下，grpc 谷歌出的。谷歌出品，除非你的产品打算服务几十亿人，否则别给自己找麻烦。
|
 |
15
iPhoneXI 2019-08-08 15:10:56 +08:00 via Android
dubbo 其他语言的客户端还是个渣吧
|
 |
17
laminux29 2019-08-08 15:16:00 +08:00 1
grpc、thrift 这些框架的优势就是，根据数据结构的定义，自动生成代码。
然而你却说 [核心逻辑代码量都没这些转换的代码多] ？？？？ 就好比，你用美团外卖，然后来吐槽自己跑了很远去取外卖，很累很远；或者是找了女朋友，却吐槽说自己天天撸管太累。 |
 |
18
Moming 2019-08-08 15:20:57 +08:00 1
用 gRPC 不都配套 ProtocolBuffer 吗？为什么你还要自己处理序列化问题？
不过我真不习惯 Java 的项目管理，还是 cargo 爽…… |
 |
19
reus 2019-08-08 15:47:07 +08:00 1
你水平太低
|
 |
20
danielmiao 2019-08-08 17:27:43 +08:00
不应该自己封装一层通用转换么？？？涉及到接口的不做通用化的处理不是给自己找麻烦么
|
 |
22
iEverX 2019-08-08 19:02:32 +08:00 via Android
如果业务逻辑是自己的类，那么就是需要写很多的 wrapper，并且 proto 类的确不适合直接用在业务代码里，thrift 好很多
|
 |
23
hsuehsen 2019-08-08 19:03:32 +08:00
Java （如 spring ）自带的框架，自动把查询的数据转换成 json 格式，所以 java 技术栈用 rest api 基本都是不用自己封包数据的。但是，grpc 是要自己调用 protobuf 生成的接口进行处理
其实，可以将 java 自动产生的 json 通过 json2grpc 网关做转换的（我记得是有类似的框架） |
|
24
hsuehsen 2019-08-08 19:05:52 +08:00
grpc 最大的优势是跨语言，是从整个系统层面（各种服务 /各种客户端），节省序列化反序列化的工作量与兼容性
特别是涉及多种通讯协议的情况下 |
 |
25
momocraft 2019-08-08 19:06:37 +08:00
如果不需要多服务多语言 可能 grpc (以及 openapi protobuf 这些东西) 好处真的不大
|
 |
26
impl 2019-08-08 19:48:18 +08:00 via Android
Java 真的不适合人类使用
|
 |
27
richard1122 2019-08-08 21:44:53 +08:00
我们用 kotlin + grpc，感觉没什么问题。 楼主是说 build message 的那一个个 set 用起来很麻烦吗？
|
 |
28
qoras 2019-08-08 23:36:41 +08:00
客户端和服务端交互用 http, 服务端内部交互用 grpc
|
 |
29
mreasonyang 2019-08-09 00:50:39 +08:00 via iPhone
这种字段完全一样的数据结构转化当然是用 Mapstruct 来做啊
|
 |
30
friddle 2019-08-09 09:49:19 +08:00
没懂。为啥服务端要解析成 model。服务端调用的是 http+json 吗。
当时我直接撸了个基于特定业务规则的 json 转 grpc 请求。一个拦截层就可以做到的事情。 需要可以把代码给你参考。不打算开源。因为业务还是绑定的太深。 还有 go 版本的 grpc-GateWay。这个也不错 |
 |
31
YzSama 2019-08-09 10:15:56 +08:00
我以前用过 wsdl cxf 来写。和 其他服务端 C#\Python 还蛮匹配的
|
Select Language