今天发现一个问题,就是 grpc 是不能支持像 http 那种 path 一样的,https://github.com/grpc/grpc/issues/14900 如果我开发一个服务 A 配了一个域名 A 服务 B 得再配个域名 B,这样显然是很不合理的。
所以针对这样有两个解决办法 1.使用统一网关。 2.本地从服务注册中心维护一份其它服务的 ip+端口,然后直接本地随机选取一个调用,这样就不需要网关了。 就有点类似于 service mesh 。它的理念是网关本地化,其实也是这么个道理- -
对内的服务的话可能不一定需要统一的鉴权之类的,所以网关感觉就很鸡肋
对外的 API 的话 我感觉还是有必要有一层网关的
1
luckyrayyy 2021-08-04 11:19:05 +08:00
没搞懂为什么一个服务要配两个 path
|
2
0576coder OP @luckyrayyy
两个服务 |
3
Rocketer 2021-08-04 11:34:38 +08:00 via iPhone
正规来讲,对内也需要鉴权。
每个服务访问其他服务都需要权限,但都是内网地址。API Gateway 是个路由器,负责把外部地址翻译成内网地址。Gateway 可以有自己的权限(默认权限),也可以由调用方提供权限。 说得比较抽象,具体看一下各大云的函数计算就明白了,都是这个套路。以 AWS 为例,内部调用函数时(比如定时任务),用的是函数的 ARN,而 API Gateway 负责外部 path 和 ARN 的映射 |
4
xuanbg 2021-08-04 13:49:35 +08:00
网关是对外的,内部服务间调用当然不需要网关,有注册中心就够了。
|
5
SmiteChow 2021-08-04 14:25:45 +08:00
你先搞清楚网关的概念再来纠结
网关=协议变换 |
6
0576coder OP @SmiteChow
网关不一定非要协议变换吧 我想请问下有 gateway 的 RFC 吗 我想拜读下 不然这个概念就还是目前人为理解的 没有权威的描述 |
7
no1xsyzy 2021-08-04 15:21:44 +08:00
@0576coder 「 RFC 」的意思是「征求意见稿」,显然不是「权威描述」(不过跟行政和立法不同,它保持征求意见稿就能投入生产使用,因为 RFC 通常描述接口,这就会形成一个协调博弈)。
另一方面,通常所说的 RFC 是 IETF RFC 备忘录,这组又不管业务层面的设计,只负责形态的设计。 不过搜索一下姑且有 1009 描述 Internet Gateway 的要求和 1772 提案 BGP 。共通之处似乎是一种关于地址的转换和对应,也就是路由(本地就是 hosts )。 话说回来,实际上也有用域名的,也有服务发现的。内部全走统一网关可能造成性能单点故障,你要建网关集群又有成倍的维护。 |