项目在微服务中的结构 基于 K8S istio 部署
方案一 A 项目 分为 A-http A-grpc 2 个工程 同理 B B-http B-grpc a 的 http 调用 a-grpc 和 b-grpc c-grpc b-http 调用 c-grpc...
方案二 A-http-grpc 一个工程提供 http 和 grpc 服务和 b-http-grpc 相互调用
方案一 这样是比较清晰,但是本项目内 a 还要调用一层 grpc 服务 ,还有就是工程数量有点多 部署麻烦 方案二 工程数量少,内部项目调用不用走 grpc 服务, http 和 grpc 调用处理会混在一起
我们现在采用的是方案一,由于服务有点多了,导致工程数量会多一倍,在纠结要不要合并为方案二 希望各位大佬说明一下实际情况中的工程结构,那种方案相对合适
1
HanMeiM 2021-09-27 10:33:49 +08:00 1
嫌工程数量有点多那为什么要用微服务呢。。
|
2
goushenggege 2021-09-27 10:47:18 +08:00 1
grpc 网关了解下?
|
4
waising OP @goushenggege #2 grpc-gateway 有看
|
5
javapythongo 2021-09-27 11:19:05 +08:00 1
业务服务统一 grpc 协议,让网关去做协议之间的转换
|
6
abcbuzhiming 2021-09-27 11:38:29 +08:00 1
明确的和你说吧,微服务就是典型的用空间换时间和吞吐量的套路,如果接受不了就不要上微服务,开发者规模不够大的时候上微服务绝对是灾难,微服务的其中一条代价就是你的组织规模是必须跟着项目数量膨胀的
|
7
chenqh 2021-09-27 12:23:02 +08:00
部署在被人内网,用微服务好还是不好呢
|
8
ychost 2021-09-27 16:20:51 +08:00
方案二比较好,我司这边默认的微服务项目就是 Api(对外接口)+Provider(RPC)+Web(HTTP 接口,可选)
|
10
waising OP @ychost #9 调用其他服务的 rpc 接口是在哪个 package 下处理,如果调用的其他 rpc 服务比较多会不会太乱
|
11
ychost 2021-09-27 16:45:29 +08:00 1
@waising RPC 接口定义在 Api 里面,消费在 Provider 里面,里面 Provider 比较重一点一方面提供 RPC 实现(继承 Api 包),另一方面还会消费其它的 PRC 接口,Web 包相对比较轻仅把 Provider 包里面的服务封装成 HTTP 接口
|
12
JYii 2021-09-27 16:49:05 +08:00
以前做 dubbo 项目时跟#25 比较像,服务之间通过 rpc,会有一个 server 服务整合提供 http 接口
|
13
JYii 2021-09-27 16:50:01 +08:00
后面做 springcloud 后,服务之间完全独立,只通过 openFeign 互相调用
|