对HTTP服务的远程调用
| Apache | Square | Netflix | |
| 组件 | HttpClient | OkHttp | Feign |
RestTemplate 是 Spring 提供的用来访问 REST 服务的客户端，利用了 JDK 或HttpClient 、OkHttp 等来实现 http 远程调用
ClientHttpRequestFactory接口的主要实现类
| JDK | Apache | OkHttp3 | |
SimpleClientHttpRequestFactory | HttpComponentsClientHttpRequestFactory | OkHttp3ClientHttpRequestFactory |
HTTP 和 RPC 框架的区别
| HTTP | RPC |
| 成熟稳定、使用实现简单、被广泛支持、兼容性良好、防火墙友好、 消息的可读性高。所以 http 协议在开放 API、跨平台的服务间调用、对性能要求不苛刻的场景中有着广泛的使用。 | 高效的网络传输模型（常使用 NIO 来实现），以及针对服务调用场景专门设 计协议和高效的序列化技术 |
注册中心的实现
Dubbo 体系中的 Zookeeper、Spring Cloud 中的 Eureka 和 Consul
分布式一致性的本质，就是在分布式系统中，多个节点就某一个提议如何达成一致
zookeeper 的设计
防止单点故障 , 常见的解决单点问题的方式就是集群
集群需要满足的功能
1. 集群中要有主节点和从节点（也就是集群要有角色）
2. 集群要能做到数据同步，当主节点出现故障时，从节点能够顶替主节点继续工作， 数据必须要主节点保持一直
3. 主节点挂了以后，从节点如何接替成为主节点？ 是人工干预？还是自动选举
Leader 角色
Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项
1. 事物请求的唯一调度和处理者，保证集群事物处理的顺序性
2. 集群内部各服务器的调度者
Follower 角色
Follower 角色的主要职责是
1. 处理客户端非事物请求(查询)、转发事物请求(更新、删除、新增)给 leader 服务器
2. 参与事物请求 Proposal 的投票（需要半数以上服务器通过才能通知 leader commit 数据; Leader 发起的提案，要求 Follower 投票）
3. 参与 Leader 选举的投票
数据同步
要实现各个节点的数据 一致性，就势必要一个 leader 节点负责协调和数据同步操作
分布式事务的数据一致性
Observer 角色
Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当 了观察者的角色。
观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于observer 不参与任何形式的投票，包括事物请求 Proposal 的投票和 leader 选举的投票。简单来说，observer 服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力
leader 选举
当 leader 挂了，需要从其他 follower 节点中选择一个新的节点进行处理，这个时候就需要涉 及到 leader 选举
集群组成
通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。每个 server 都维护的内存状态镜像以及持久化存储的事务日志和快照。对于 2n+1 台 server，只要有 n+1台（大多数）server 可用，整个系统保持可用。一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有 过半 的机器正常工作并且彼此之间能够正常通信，因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台机器后依然正常工作。一个 5 台机器集群的服务，能够对 2 台机器怪调的情况下进行容灾。如果一台由 6 台服务构成的集群，同样只能挂掉 2 台机器。因此，5 台和 6 台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台server 为 Leader，其它的就作为 follower（这里先不考虑 observer 角色）。 一个节点要成为集群中的 leader，需要有超过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票