JAVA总结--dubbo与zookeeper

读累了就看看实操http://www.javashuo.com/article/p-ugnyhqlq-s.html 

1、SOA

概念：SOA：Service-Oriented Architecture，面向服务的架构，将应用程序的不一样功能(服务)经过定义的接口来实现数据通讯；服务治理；服务调度中心和治理中心；

架构演变：单一应用架构ORM  |  垂直应用架构MVC  |  分布式服务架构RPC  |  流动计算架构SOA

ORM ：流量小，单一应用，部署一块儿；关注于简化增删改查的对象关系映射，

MVC ：流量增长，应用拆分；关注于提升前端开发速度；

RPC ：远程过程调用；经过网络进行远程计算机服务的请求；核心业务抽取；关注于业务的复用和整合；

由统一到分布式：

使用场景由混乱到统一：

 SOA又叫服务治理，SOA就是帮助咱们把服务之间调用的乱七八糟的关系给治理起来，而后提供一个统一的标准；

统一标准：各系统的协议、地址、交互方式。

新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其余子系统时，咱们并不关心若是找到其余子系统，咱们只招数据总线，数据总线再根据统一标准找其余子系统，因此数据总线在这里充当一个只路人的做用。

数据总线是起到调度服务的做用，数据总线不是集成服务，数据总线更新一个调度框架，每一个服务须要根据约定向数据总线注册服务；服务不是通过总线的，是直接向client响应；

 2、dubbo

概念：dubbo：一个解决大规模服务治理的高性能分布式服务框架；分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架；

流程与说明： 

dubbo的架构图以下：

其中，

· Provider: 暴露服务的服务提供方。

· Consumer: 调用远程服务的服务消费方。

· Registry: 服务注册与发现的注册中心。

· Monitor: 统计服务的调用次调和调用时间的监控中心。

· Container: 服务运行容器。

调用关系说明：

1. 服务容器负责启动，加载，运行服务提供者。

2. 服务提供者在启动时，向注册中心注册本身提供的服务。

3. 服务消费者在启动时，向注册中心订阅本身所需的服务。

4. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。

5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。

6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

   Dubbo提供了不少协议，Dubbo协议、RMI协议、Hessian协议，Dubbo源代码有各类协议的实现，咱们以前没用Dubbo以前时，大部分都用Hessian来使用咱们服务的暴露和调用，利用HessianProxyFactory调用远程接口。

原理：

初始化过程细节：

 　　　　第一步，就是将服务装载容器中，而后准备注册服务。和spring中启动过程相似，spring启动时，将bean装载进容器中的时候，首先要解析bean。因此dubbo也是先读配置文件解析服务。

解析服务：

　　　　1）、基于dubbo.jar内的Meta-inf/spring.handlers配置，spring在遇到dubbo名称空间时，会回调DubboNamespaceHandler类。

　　　　2）、全部的dubbo标签，都统一用DubboBeanDefinitionParser进行解析，基于一对一属性映射，将XML标签解析为Bean对象。生产者或者消费者初始化的时候，会将Bean对象转会为url格式，将全部Bean属性转成url的参数。 而后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不一样协议的服务暴露和引用。

暴露服务：

　　　　a、 直接暴露服务端口

　　　　在没有使用注册中心的状况，这种状况通常适用在开发环境下，服务的调用这和提供在同一个IP上，只须要打开服务的端口便可。 即，当配置 or ServiceConfig解析出的URL的格式为： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0 基于扩展点的Adaptiver机制，经过URL的“dubbo：//”协议头识别，直接调用DubboProtocol的export（）方法，打开服务端口。

　　　　b、向注册中心暴露服务：

　　　　和上一种的区别：须要将服务的IP和端口一同暴露给注册中心。 ServiceConfig解析出的url格式为： registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

基于扩展点的Adaptive机制，经过URL的“registry：//”协议头识别，调用RegistryProtocol的export方法，将export参数中的提供者URL先注册到注册中心，再从新传给Protocol扩展点进行暴露： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

引用服务：

　　　　a、直接引用服务：

　　　　在没有注册中心的，直连提供者状况下， ReferenceConfig解析出的URL格式为： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

基于扩展点的Adaptive机制，经过url的“dubbo：//”协议头识别，直接调用DubboProtocol的refer方法，返回提供者引用。

　　　　b、从注册中心发现引用服务：

　　　　此时，ReferenceConfig解析出的URL的格式为： registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(“consumer://consumer-host/com.foo.FooService?version=1.0.0”)

　　　　基于扩展点的Apaptive机制，经过URL的“registry：//”协议头识别，就会调用RegistryProtocol的refer方法，基于refer参数总的条件，查询提供者URL，如： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

　　　　基于扩展点的Adaptive机制，经过提供者URL的“dubbo：//”协议头识别，就会调用DubboProtocol的refer（）方法，获得提供者引用。 而后RegistryProtocol将多个提供者引用，经过Cluster扩展点，假装成单个提供这引用返回。

暴露服务的主过程：

　　　　首先ServiceConfig类拿到对外提供服务的实际类ref，而后将ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例，到这一步就完成具体服务到invoker的转化。接下来就是Invoker转换到Exporter的过程。 Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程，下面咱们以Dubbo和rmi这两种典型协议的实现来进行说明： Dubbo的实现： Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法，它主要是打开socket侦听服务，并接收客户端发来的各类请求，通信细节由dubbo本身实现。 Rmi的实现： RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法，他经过Spring或Dubbo或JDK来实现服务，通信细节由JDK底层来实现。

服务消费的主过程：

　　　　首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例。接下来把Invoker转为客户端须要的接口

 3、zookeeper(可做为Dubbo的注册中心使用)

概念zookeeper：为分布式应用程序提供协调服务；为其余分布式程序提供协调服务；自己也是分布式程序；

zookeeper提供的服务：配置维护、域名服务、分布式同步、组服务；其实只提供了两个功能（管理数据和监听数据）： 管理(存储，读取)用户程序提交的数据； 并为用户程序提供数据节点监听服务；

应用场景：

Zookeeper主要是作注册中心用；基于Dubbo框架开发的提供者、消费者都向Zookeeper注册本身的URL，消费者还能拿到并订阅提供者的注册URL，以便在后续程序的执行中去调用提供者。而提供者发生了变更，也会经过Zookeeper向订阅的消费者发送通知；

用于担任服务生产者和服务消费者的注册中心，服务生产者将本身提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息以后，再去调用服务生产者的内容与数据；

zookeeper数据模型

Znode：目录结构；节点；

数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个ZNode，如/hbase/master,其中hbase和master都是ZNode；

每一个Znode节点都包含了该节点的数据、状态信息、子节点。状态信息用来记录每次节点变动后的时间戳、版本等信息。所以，当版本发生变动的时候，ZooKeeper会同步修改该节点的状态信息。

Znode有以下特征：

1. 监视（Watch）

   客户端能够在Znode上面增长监视事件，当Znode发生变化的时候，ZooKeeper就会触发watch，并向客户端发送且仅通知一次，watch只能被触发一次。

2. 数据访问

   节点数据访问是原子性，每一个节点都有ACL（权限列表），规定了用户的权限，能够划分权限设定。

3. 节点类型

   节点类型分为两种，永久性和临时性。临时性节点在每次会话结束的时候，自动删除。也能够手动删除临时节点，并且临时节点无法创建子节点。

4. 顺序节点

   每一个节点建立的时候，都会给新建立的节点增长1个身份数字，从1开始。它的格式“%10d”，计数超过2^32-1时，会有溢出风险。

   Znode类型有4种：永久性节点、临时性节点、永久性有序节点、临时性有序节点

ZooKeeper采用ACL（Access Control Lists）策略来进行权限控制；

zookeeper的5种权限：

·CREATE: 建立子节点的权限。

·READ: 获取节点数据和子节点列表的权限。

·WRITE：更新节点数据的权限。

·DELETE: 删除子节点的权限。

·ADMIN: 设置节点ACL的权限。

注意：CREATE 和 DELETE 都是针对子节点的权限控制。

zookeeper原理：

（1）ZooKeeper分为服务器端（Server） 和客户端（Client），客户端能够链接到整个 ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不容许接受客户端链接）。

（2）客户端使用并维护一个 TCP 链接，经过这个链接发送请求、接受响应、获取观察的事件以及发送心跳。若是这个 TCP 链接中断，客户端将自动尝试链接到另外的 ZooKeeper服务器。客户端第一次链接到 ZooKeeper服务时，接受这个链接的 ZooKeeper服务器会为这个客户端创建一个会话。当这个客户端链接到另外的服务器时，这个会话会被新的服务器从新创建。

（3）上图中每个Server表明一个安装Zookeeper服务的机器，便是整个提供Zookeeper服务的集群（或者是由伪集群组成）；

（4）组成ZooKeeper服务的服务器必须彼此了解。 它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照， 只要大多数服务器可用，ZooKeeper服务就可用；

（5）ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责处理数据更新等操做，一个更新操做成功的标志是当且仅当大多数Server在内存中成功修改数据。每一个Server 在内存中存储了一份数据。

（6）Zookeeper是能够集群复制的，集群间经过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；

（7）Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段。

• a) 集群中将选举出一个leader，其余的机器则称为follower，全部的写操做都被传送给leader，并经过brodcast将全部的更新告诉给follower。

• b) 当leader崩溃或者leader失去大多数的follower时，须要从新选举出一个新的leader，让全部的服务器都恢复到一个正确的状态。

• c) 当leader被选举出来，且大多数服务器完成了 和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。

• d) Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具备形同的系统状态。\

Leader算法：以Fast Paxos算法为基础的

 

zookeeper角色：Leader、learner或follower、ObServer 

领导者(Leader)：负责进行投票的发起和决议，更新系统状态；

学习者(Learner)或跟随者(Follower)：接收客户端请求，并向客户端返回结果，在选主过程当中参与投票；若是接收到的客户端请求为写请求，将转发给Leader来完成系统状态的更新；

观察者(ObServer)：接收客户端的链接，将写请求转发给Leader；不参与选主过程的投票，仅同步Leader状态；扩展系统，提升读写速度；

应用场景

1 统一命名服务(如Dubbo服务注册中心)

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是阿里巴巴SOA服务化治理方案的核心框架，天天为2,000+个服务提供3,000,000,000+次访问量支持，并被普遍应用于阿里巴巴集团的各成员站点。

在Dubbo实现中：

服务提供者在启动的时候，向ZK上的指定节点/dubbo/${serviceName}/providers目录下写入本身的URL地址，这个操做就完成了服务的发布。

服务消费者启动的时候，订阅/dubbo/${serviceName}/providers目录下的提供者URL地址， 并向/dubbo/${serviceName} /consumers目录下写入本身的URL地址。

注意，全部向ZK上注册的地址都是临时节点，这样就可以保证服务提供者和消费者可以自动感应资源的变化。 另外，Dubbo还有针对服务粒度的监控，方法是订阅/dubbo/${serviceName}目录下全部提供者和消费者的信息。

2 配置管理 (如淘宝开源配置管理框架Diamond)

在大型的分布式系统中，为了服务海量的请求，同一个应用经常须要多个实例。若是存在配置更新的需求，经常须要逐台更新，给运维增长了很大的负担同时带来必定的风险(配置会存在不一致的窗口期，或者个别节点忘记更新)。zookeeper能够用来作集中的配置管理，存储在zookeeper鸡群中的配置，若是发生变动会主动推送到链接配置中心的应用节点，实现一处更新到处更新的效果。

3 分布式集群管理 (Hadoop分布式集群管理)

这一般用于那种对集群中机器状态，机器在线率有较高要求的场景，可以快速对集群中机器变化做出响应。这样的场景中，每每有一个监控系统，实时检测集群机器是否存活。过去的作法一般是：监控系统经过某种手段（好比ping）定时检测每一个机器，或者每一个机器本身定时向监控系统汇报“我还活着”。 这种作法可行，可是存在两个比较明显的问题：

(1) 集群中机器有变更的时候，牵连修改的东西比较多。

(2) 有必定的延时。

利用ZooKeeper有两个特性，就能够实现另外一种集群机器存活性监控系统：

(1) 客户端在节点 x 上注册一个Watcher，那么若是 x?的子节点变化了，会通知该客户端。

(2) 建立EPHEMERAL类型的节点，一旦客户端和服务器的会话结束或过时，那么该节点就会消失。

例如，监控系统在 /clusterServers 节点上注册一个Watcher，之后每动态加机器，那么就往 /clusterServers 下建立一个 EPHEMERAL类型的节点：/clusterServers/{hostname}. 这样，监控系统就可以实时知道机器的增减状况，至于后续处理就是监控系统的业务了。

4 分布式锁(强一致性)

这个主要得益于ZooKeeper为咱们保证了数据的强一致性。锁服务能够分为两类，一个是 保持独占，另外一个是 控制时序。

(1) 所谓保持独占，就是全部试图来获取这个锁的客户端，最终只有一个能够成功得到这把锁。一般的作法是把zk上的一个znode看做是一把锁，经过create znode的方式来实现。全部客户端都去建立 /distribute_lock 节点，最终成功建立的那个客户端也即拥有了这把锁。

(2) 控制时序，就是全部视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。作法和上面基本相似，只是这里 /distribute_lock 已经预先存在，客户端在它下面建立临时有序节点（这个能够经过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点建立的时序性，从而也造成了每一个客户端的全局时序。