微服务中项目结构规划哪种方案比较好一点

[waising]

项目在微服务中的结构 基于 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 调用处理会混在一起

我们现在采用的是方案一,由于服务有点多了,导致工程数量会多一倍,在纠结要不要合并为方案二 希望各位大佬说明一下实际情况中的工程结构,那种方案相对合适

[HanMeiM]

嫌工程数量有点多那为什么要用微服务呢。。

[goushenggege]

grpc 网关了解下？

[waising]

@HanMeiM #1 原来是部署在云上的 现在有些客户要部署到内网,也不一定要减少吧,看哪种更合理

[waising]

@goushenggege #2 grpc-gateway 有看

[javapythongo]

业务服务统一 grpc 协议，让网关去做协议之间的转换

[abcbuzhiming]

明确的和你说吧，微服务就是典型的用空间换时间和吞吐量的套路，如果接受不了就不要上微服务，开发者规模不够大的时候上微服务绝对是灾难，微服务的其中一条代价就是你的组织规模是必须跟着项目数量膨胀的

[simple2025]

部署在被人内网,用微服务好还是不好呢

[ychost]

方案二比较好，我司这边默认的微服务项目就是 Api(对外接口)+Provider(RPC)+Web(HTTP 接口，可选)

[ychost]

@ychost 一个项目含有这三个 package

[waising]

@ychost #9 调用其他服务的 rpc 接口是在哪个 package 下处理,如果调用的其他 rpc 服务比较多会不会太乱

[ychost]

@waising RPC 接口定义在 Api 里面，消费在 Provider 里面，里面 Provider 比较重一点一方面提供 RPC 实现（继承 Api 包），另一方面还会消费其它的 PRC 接口，Web 包相对比较轻仅把 Provider 包里面的服务封装成 HTTP 接口

[JYii]

以前做 dubbo 项目时跟#25 比较像，服务之间通过 rpc，会有一个 server 服务整合提供 http 接口

[JYii]

后面做 springcloud 后，服务之间完全独立，只通过 openFeign 互相调用

[waising]

@JYii #13 openFeign 以前也用过 通过注解还是很方便的,我还是考虑下怎么合并,结构怎么规划

[waising]

@ychost #11 可以参考,合并后应该和这个结构差不多