Skip to content
Permalink
Browse files
Update README.md
  • Loading branch information
Jeff-Lv committed Mar 13, 2019
1 parent 12fd416 commit d4495debfb948daf64023527104f2a232e0e6347
Showing 1 changed file with 1 addition and 1 deletion.
@@ -16,7 +16,7 @@ Service的IP有几种表现形式,分别是ClusterIP,NodePort,LoadBalance,In

此处只讨论集群内的Dubbo服务在同一个kubernetes集群内访问;至于kubernetes外的consumer访问kubernetes内的provider,涉及到网络地址空间的问题,一般需要GateWay/loadbalance来做映射转换,不展开讨论。针对kubernetes内有两种方案可选:

- DNS: 默认kubernetes的service是靠DNS插件(最新版推荐是coreDNS), Dubbo上有个(proposal)[https://github.com/apache/incubator-dubbo/issues/2043]是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service discovery机制,具体也可以参考Envoy在此的观点,由于HSF/Dubbo一直突出其软负载的地址发现能力,反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略,那一个SOFA工程的工程片段做一个解释。这样做有两个好处,1)当软负载中心crash不可用造成无法获取地址列表时,有一定的机制Failover到此策略来处理一定的请求。 2)在LDC/单元化下,蚂蚁的负载中心集群是机房/区域内收敛部署的,首先保证软负载中心的LDC化了进而稳定可控,当单元需要请求中心时,此VIP的地址发现就排上用场了。
- DNS: 默认kubernetes的service是靠DNS插件(最新版推荐是coreDNS), Dubbo上有个 [proposal](https://github.com/apache/incubator-dubbo/issues/2043) 是关于这个的。我的理解是static resolution的机制是最简单最需要支持的一种service discovery机制,具体也可以参考Envoy在此的观点,由于HSF/Dubbo一直突出其软负载的地址发现能力,反而忽略Static的策略。同时蚂蚁的SOFA一直是支持此种策略,那一个SOFA工程的工程片段做一个解释。这样做有两个好处,1)当软负载中心crash不可用造成无法获取地址列表时,有一定的机制Failover到此策略来处理一定的请求。 2)在LDC/单元化下,蚂蚁的负载中心集群是机房/区域内收敛部署的,首先保证软负载中心的LDC化了进而稳定可控,当单元需要请求中心时,此VIP的地址发现就排上用场了。

- API:DNS是依靠DNS插件进行的,相当于额外的运维开销,所以考虑直接通过kubernetes的client来获取endpoint。事实上,通过访问kubernetes的API server接口是可以直接获取某个servie背后的endpoint列表,同时可以监听其地址列表的变化。从而实现Dubbo/HSF所推荐的软负载发现策略。具体可以参考代码:

0 comments on commit d4495de

Please sign in to comment.