dubbo/zk
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
dubbo的那个interface，不是随便写只要provider和consumer一致就行了。而是那个应该是一个切实存在的接口，生产者消费者都能找到那个接口（依赖配置好），然后消费者先import这个接口，然后使用这个接口的方法的时候，去找生产者对这个接口的实现类
dubbo的消费者有缓存服务列表，而不是每次调用都去ZK取一次
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ZK(zookeeper)是一个分布式框架。ZK是文件式系统的组织结构（树状）。客户端监听zk服务端的节点，服务端有变化就会被客户端监听到
我们项目把ZK作为dubbo的注册中心。provider把自己的服务（接口）注册到注册中心，consumer向注册中心订阅自己需要的服务（接口）。然后注册中心返回provider的地址列表给consumer，
consumer基于负载均衡算法选一台provider进行调用
我理解是dubbo自己做了对zk的适配
同一个注册中心的多台机器。所有机器都注册了相同的服务，消费者会被均衡策略分配给一个机器去查。查不到的话就报错
http://dubbo.apache.org/zh/docs/v2.7/user/references/registry/zookeeper/
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
如果dubbo的provider应用部署在docker里，那么默认是把docker的容器IP和容器端口注册到zk，这种情况下consumer按照容器的IP和端口是找不到provider的，所以应该是把provider的宿主机的IP和端口注册到ZK，办法是设置俩环境变量，如下：
- name: DUBBO_PORT_TO_REGISTRY
value: '31666' // 这是宿主机的端口，跟容器的端口有个映射关系。这个映射关系应该是由云容器平台来维护的
- name: DUBBO_IP_TO_REGISTRY
valueFrom:
fieldRef:
apiVersion: v1
fieldPath: status.hostIP // 这就是取宿主机的IP
如果一台宿主机上有多台容器实例，配置的DUBBO_PORT_TO_REGISTRY是同一个端口，不会冲突。会有一个类似于负载均衡的分发操作，至于这个操作是谁做的，我猜是k8s？
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
可以用tag(打标签的方式)做灰度隔离