Skip to content
Permalink
Browse files
add demo instruction
  • Loading branch information
kongming committed Sep 24, 2019
1 parent 1a2b4cc commit 83d7f79baae619178b5618b8b6240dd41a42bbe1
Showing 1 changed file with 23 additions and 0 deletions.
@@ -0,0 +1,23 @@
### 基本点
- provider只要把端口打开就行,不用自己注册。是通过pod注册到k8s的。
- consumer是需要通过k8s的fabric client来获取对应的服务地址。

### 问答

------------
- A:我理解的是一个Pod一个Provider或者Consumer进程,剩下的那个k8s init-container 不会帮业务进程做任何事情的。那Provider怎么把自己注册到k8s中?
- B:好问题。是k8s的 service.yaml 中发布的。用k8s的 方式定义出来的。为了复用k8s的service能力,就需要用k8s的方式发布服务。
- A: provider问题解了, consumer订阅的时候就需要知道 k8s的API server地址。之前的话,不管是zk还是其他k/v介质,都是dubbo进程启动之后自己主动写进去注册中心的,所以我一直以为provider和consumer都是自个儿把自己的meta数据写到kubernetes。原来不是。。


------------
- 问:需要手工写yaml然后kubectl apply -f 么?
- 答:目前是的, 当然你可以写个maven插件什么的,通过扫描dubbo的配置来自动生成。我感觉是需要开发一个额外的Operator。

------------
- 问:还有个问题是 k8s发布的服务名与dubbo的服务名的转换问题。
- 答:这个转换映射目前是通过 -D参数配置的方式, 也是比较初级。假设dubbo服务名是 com.abc.service.XYZ, 那需要启动时配置 -Dcom.abc.service.XYZ_target=XYZ.service.com 之类的。k8s的服务命名方式一般是正序, 而dubbo是包名。

------------
- 问:目前有一个规范么?不然dubbo-go这边和dubbo如果不使用同一种方式,出来的 Provider/Consumer 无法正常工作。
- 答:规范需要大家一起来完善。

0 comments on commit 83d7f79

Please sign in to comment.