zk配置和管理
高并发分布式系统的特征：同一服务需要部署多个。整个大的业务系统由多个子业务系统构成，彼此之间需要相互调用。
产生的问题
- 同一服务多台服务器，如何管理服务配置。
- 服务的消费者如何动态的发现服务提供者。
- 怎么知道部署了多少业务系统以及每个业务系统提供了多少个服务接口。
dubbo
逻辑结构
节点角色说明
- “Provider”: 暴露服务的服务提供方。
- “Consumer”: 调用远程服务的服务消费方。
- “Registry”: 服务注册与发现的注册中心。
- “Monitor”: 统计服务的调用次调和调用时间的监控中心。
- “Container”: 服务运行容器。
调用关系说明：
1 | 0. 服务容器负责启动，加载，运行服务提供者。 |
- (1) 连通性：
1 | 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小 |
- (2) 健状性：
1 | 监控中心宕掉不影响使用，只是丢失部分采样数据 |
(3) 伸缩性：
1
2注册中心为对等集群，可动态增加机器部署实例，所有客户端将自动发现新的注册中心
服务提供者无状态，可动态增加机器部署实例，注册中心将推送新的服务提供者信息给消费者(4) 升级性：
1
当服务集群规模进一步扩大，带动IT治理结构进一步升级，需要实现动态部署，进行流动计算，现有分布式服务架构不会带来阻力。
DUBBO核心分析：通过注册中心，实现服务动态注册、发现以及配置的管理。
基于zk设计的配置管理中心
基于zk，使用zk父节点作为服务名，临时子节点作为服务提供者信息。示例：
1 | +userService[data:服务信息描述，json格式会或者其他格式，包含版本，方法列表，方法描述] |
最简单的可以不是rpc，可以使用restful，微服务概念的兴起，基于spring boot的restful兴起。可将请求的url作为服务名称写入父节点，eg:/user/reg，然后provider启动时，自动获取应用中的映射连接，向zk约定好的节点下去注册自身ip地址，端口等信息。consumer启动后，连接zk，读取约定好的节点下的所有url服务以及此时已有的提供者信息列表，并缓存、维护。
服务提供者和消费者必须达成服务列表的一致性，即有哪些服务必须明确，就如同RPC一样，调用者和被调用者必须明确接口以及接口方法和方法参数，Thrift，gRpc，ZeroC ice中使用IDL来做到
服务提供者【provider】
服务提供者连接到zk服务节点，当前结点没有则创建，然后创建临时子节点并写入自身节点信息。
消费者【consumer】
消费者连接到zk服务节点，读取服务列表（可以只读取自己所需要的）以及服务对应的提供者的信息，并缓存、维护服务提供者状态。可将服务提供者按服务指标进行管理，基于服务的执行，收集信息并对服务提供者进行优先级排序，优先使用可靠、高效、优先级靠前的服务提供者。