这是一个创建于 2260 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务端查询数据-->转成 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