This is an automated email from the ASF dual-hosted git repository.
hyunkun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-kubernetes.git
The following commit(s) were added to refs/heads/master by this push:
new dd06ce5 updated `Service` Typo in README.md (#6)
dd06ce5 is described below
commit dd06ce5c8731c6898d3db19309f28f9e80f5c3f7
Author: Akshit Mangotra <57808363+akshit6...@users.noreply.github.com>
AuthorDate: Tue Jul 20 07:45:47 2021 +0530
updated `Service` Typo in README.md (#6)
---
README.md | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README.md b/README.md
index 662a923..ada3030 100644
--- a/README.md
+++ b/README.md
@@ -18,8 +18,8 @@ Service的IP有几种表现形式，分别是ClusterIP，NodePort,LoadBalance,In
- 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所推荐的软负载发现策略。具体可以参考代码：
+-
API：DNS是依靠DNS插件进行的，相当于额外的运维开销，所以考虑直接通过kubernetes的client来获取endpoint。事实上，通过访问kubernetes的API
server接口是可以直接获取某个service背后的endpoint列表，同时可以监听其地址列表的变化。从而实现Dubbo/HSF所推荐的软负载发现策略。具体可以参考代码：
以上两种思路都需要考虑以下两点
--
kubernetes和Dubbo对于service的名字是映射一致的。Dubbo的服务是由serviename，group，version三个来确定其唯一性，而且servicename一般其服务接口的包名称，比较长。需要映射kubernetes的servie名与dubbo的服务名。要么是像SOFA那样增加一个属性来进行定义，这个是改造大点，但最合理；要么是通过固定规则来引用部署的环境变量，可用于快速验证。
+-
kubernetes和Dubbo对于service的名字是映射一致的。Dubbo的服务是由servicename，group，version三个来确定其唯一性，而且servicename一般其服务接口的包名称，比较长。需要映射kubernetes的service名与dubbo的服务名。要么是像SOFA那样增加一个属性来进行定义，这个是改造大点，但最合理；要么是通过固定规则来引用部署的环境变量，可用于快速验证。
- 端口问题。默认Pod与Pod的网络互通算是解决了。需要验证。
