search

Mikaelemmmm / go-zero-looklook

🔥基于go-zero(go zero) 微服务全技术栈开发最佳实践项目。Develop best practice projects based on the full technology stack of go zero (go zero) microservices.
https://go-zero.dev
MIT License
4.18k stars 789 forks source link

关于api和rpc的疑问 #130

Closed VioletCoding closed 7 months ago

VioletCoding commented 8 months ago

我是go新手，之前写java的，看了一下这个项目有几个疑惑。

比如为什么 一个rpc要对应一个api？之前用SpringCloud的时候是在spring-gateway里自动路由的，比如请求的路径是 /a-service/doSomething，gateway就自动通过a-service这个名字把请求转到 a-service 这个服务了，这个过程是自动的。 但是现在看这个项目以及02-nginx网关.md这篇文档，每加一个接口或者接口有改动，.api文件要改，然后通过goctl生成代码，rpc要改，然后又生成代码，然后还要在api的logic改一下，而貌似大部分时候这个logic只是调了一下rpc没做别的，而且大部分时候参数名都一模一样，这样不是很繁琐吗？还是说这个项目只是演示一下原理，实际上是可以自动的？

还有一个是为什么每个api服务只要用到JWT都要在配置文件写一个 AccessSecret？在我理解这个JWT的秘钥整个项目应该有且仅有一个吧？比如有个鉴权服务专门负责登录生成token，api gateway只是校验，不通过返回401等，但是项目里比如order api 和 payment api 都要在配置文件上加，个人觉得很冗余，看了一下生成的routes.go又不让改，写死了从Config里去取AccessSecret。

不知道哪里理解不对，还请赐教。

Mikaelemmmm commented 8 months ago

取决于不同公司不同时期的架构，你可以选择 一个api作为业务网关类似springcloud gateway 这种功能，或者起到一个bff作用，业务都写在下游rpc 也没什么问题，多个api拆分开 相当于把不同业务拆开了，前面在有一个nignx、kong这种网关

Mikaelemmmm commented 8 months ago

只有你说应该有一个公共授权的服务，最早1.0.0的tag，我是有一个identity的服务，在nignx中调用的 ，nginx的auth插件会先经过这个identity认证在调用下游，后来被我移除了 统一改成了go-zero默认自带的jwt

VioletCoding commented 8 months ago

取决于不同公司不同时期的架构，你可以选择 一个api作为业务网关类似springcloud gateway 这种功能，或者起到一个bff作用，业务都写在下游rpc 也没什么问题，多个api拆分开 相当于把不同业务拆开了，前面在有一个nignx、kong这种网关

看了一下go-zero里的gRPC-gateway，用法上还是需要改代码，比如rpc服务新增一个接口，网关也得去声明rpc服务然后去调接口，相当于每加一个接口，网关和下游的业务rpc都得更新代码。之前没怎么碰过 gRPC，写Java用的是OpenFeign，倒是没在意过这么多，写完一个接口也只是更新下游业务服务，网关是完全不用动的，网关无状态的都是水平拓展即可。如果用go-zero要做到这种效果的话，是不是得每个下游服务既开启HTTP又开启gRPC？这样网关反向代理过来走HTTP，下游服务与服务之间用gRPC，是否也是能做到的？

VioletCoding commented 8 months ago

取决于不同公司不同时期的架构，你可以选择 一个api作为业务网关类似springcloud gateway 这种功能，或者起到一个bff作用，业务都写在下游rpc 也没什么问题，多个api拆分开 相当于把不同业务拆开了，前面在有一个nignx、kong这种网关

看了一下go-zero里的gRPC-gateway，用法上还是需要改代码，比如rpc服务新增一个接口，网关也得去声明rpc服务然后去调接口，相当于每加一个接口，网关和下游的业务rpc都得更新代码。之前没怎么碰过 gRPC，写Java用的是OpenFeign，倒是没在意过这么多，写完一个接口也只是更新下游业务服务，网关是完全不用动的，网关无状态的都是水平拓展即可。如果用go-zero要做到这种效果的话，是不是得每个下游服务既开启HTTP又开启gRPC？这样网关反向代理过来走HTTP，下游服务与服务之间用gRPC，是否也是能做到的？

倒也不是说这样不好，就是在开发体验上有点繁琐

Mikaelemmmm commented 8 months ago

取决于不同公司不同时期的架构，你可以选择 一个api作为业务网关类似springcloud gateway 这种功能，或者起到一个bff作用，业务都写在下游rpc 也没什么问题，多个api拆分开 相当于把不同业务拆开了，前面在有一个nignx、kong这种网关

看了一下go-zero里的gRPC-gateway，用法上还是需要改代码，比如rpc服务新增一个接口，网关也得去声明rpc服务然后去调接口，相当于每加一个接口，网关和下游的业务rpc都得更新代码。之前没怎么碰过 gRPC，写Java用的是OpenFeign，倒是没在意过这么多，写完一个接口也只是更新下游业务服务，网关是完全不用动的，网关无状态的都是水平拓展即可。如果用go-zero要做到这种效果的话，是不是得每个下游服务既开启HTTP又开启gRPC？这样网关反向代理过来走HTTP，下游服务与服务之间用gRPC，是否也是能做到的？

跟框架无关，跟底层协议有关，grpc+protobuf跟http不一样，可以多了解一下