感觉对外的 API 层需要 gateway 网关，对内部核心服务是不是可以不需要网关

[0576coder]

今天发现一个问题，就是 grpc 是不能支持像 http 那种 path 一样的，https://github.com/grpc/grpc/issues/14900 如果我开发一个服务 A 配了一个域名 A 服务 B 得再配个域名 B，这样显然是很不合理的。

所以针对这样有两个解决办法 1.使用统一网关。 2.本地从服务注册中心维护一份其它服务的 ip+端口，然后直接本地随机选取一个调用，这样就不需要网关了。 就有点类似于 service mesh 。它的理念是网关本地化，其实也是这么个道理- -

对内的服务的话可能不一定需要统一的鉴权之类的，所以网关感觉就很鸡肋

对外的 API 的话 我感觉还是有必要有一层网关的

[luckyrayyy]

没搞懂为什么一个服务要配两个 path

[0576coder]

@luckyrayyy
两个服务

[Rocketer]

正规来讲，对内也需要鉴权。

每个服务访问其他服务都需要权限，但都是内网地址。API Gateway 是个路由器，负责把外部地址翻译成内网地址。Gateway 可以有自己的权限（默认权限），也可以由调用方提供权限。

说得比较抽象，具体看一下各大云的函数计算就明白了，都是这个套路。以 AWS 为例，内部调用函数时（比如定时任务），用的是函数的 ARN，而 API Gateway 负责外部 path 和 ARN 的映射

[xuanbg]

网关是对外的，内部服务间调用当然不需要网关，有注册中心就够了。

[SmiteChow]

你先搞清楚网关的概念再来纠结
网关=协议变换

[0576coder]

@SmiteChow
网关不一定非要协议变换吧 我想请问下有 gateway 的 RFC 吗 我想拜读下 不然这个概念就还是目前人为理解的 没有权威的描述

[no1xsyzy]

@0576coder 「 RFC 」的意思是「征求意见稿」，显然不是「权威描述」（不过跟行政和立法不同，它保持征求意见稿就能投入生产使用，因为 RFC 通常描述接口，这就会形成一个协调博弈）。
另一方面，通常所说的 RFC 是 IETF RFC 备忘录，这组又不管业务层面的设计，只负责形态的设计。
不过搜索一下姑且有 1009 描述 Internet Gateway 的要求和 1772 提案 BGP 。共通之处似乎是一种关于地址的转换和对应，也就是路由（本地就是 hosts ）。
话说回来，实际上也有用域名的，也有服务发现的。内部全走统一网关可能造成性能单点故障，你要建网关集群又有成倍的维护。