分布式服务动态上下线感知
分布式服务动态上下线感知
首先，我们要从解决问题的角度得知分布式服务的由来，从单机服务到分布式服务经历了哪些过程
起初，服务是比较单一的，在一个工程包之中会包含所有的模块，但随着互联网的快速发展，客户流量的增多，点击量数据量的增多，导致对架构方面的冲击较大，想要在用户量和数据量较大的情况下做到即时相应的话，就需要去提升后端架构的性能。早期我们会去提升服务器硬件设备，但是还是无法达到预期的效果，只能通过水平扩展，将应用进行拆分，每一个应用都可以独立存储、独立计算。每一个服务都会比较小、比较细、更好的去实现功能，微服务也就应运而生。如下图所示：
当服务较多时，服务与服务直接的调用会变得凌乱，过于复杂化，为了解决该问题，出现了SOA这一概念
关于soa，这里引用其他博客中的一个例子，讲的很好，原文链接：
https://www.cnblogs.com/renzhitian/p/6853289.html
深入浅出SOA
SOA是什么？SOA全英文是Service-Oriented Architecture，中文意思是中文面向服务编程，是一种思想，一种方法论，一种分布式的服务架构（具体可以百度）。
用途：SOA解决多服务凌乱问题，SOA架构解决数据服务的复杂程度，同时SOA又有一个名字，叫做服务治理。
通过一个系统我们看一下架构的演变过程（由统一到分布式）：
当我们的项目比较小时，我们只有一个系统，并且把他们写到一起，放在一个服务器上，但是随着平台越来越大，数据量越来越大，我们不得不通过分库，把多个模块的数据库分别放在对应得服务器上，每个模块调用自己的子系统即可。
随着我们系统的进一步复杂度的提升，我们不得不进一步对系统的性能进行提升，我们将多个模块分成多个子系统，多个子系统直接互相调用（因为SOA一般用于大型项目，比较复杂，所以一般总系统不会再集成，会拆分多个，分别做成服务，相互调用）。当我们的电商UI进行一个下订单的任务时，多个服务直接互相调用，系统通过数据总线，分别调用对于的子系统即可。
企业数据总线：企业数据总线不是对多个子模块的集成，他在这里充当数据通道的作用，数据总线不关心业务，数据总线根据给的地址和协议去调服务，上端不关心服务在哪里是什么，只找数据总线。
上面几个图应该算是比较清楚了，随着业务的深入，我们不得不对系统进行调整，分别是对数据和业务的拆分，最后每个子系统对面提供服务。
还要提的一点就是下面那个图，下面的IP库以及几个子系统是公共服务，分别向上提供功能，也是SOA方法论的一部分。
二、SOA主要的使用场景，如下图：
通过上面的图我们可以看出，多个子系统直接相互交互，相互调用非常凌乱，这样我们就很不爽，所以我们就用到了我们的SOA架构，SOA又叫服务治理，SOA就是帮助我们把服务之间调用的乱七八糟的关系给治理起来，然后提供一个统一的标准，把我们的服务治理成下图所示，以前我们的服务是互相交互，现在是只对数据总线进行交互，这样系统就变得统一起来。
统一标准：各系统的协议、地址、交互方式。
新的交互方式：各个系统分别根据统一标准向数据总线进行注册，各子系统调用其他子系统时，我们并不关心如果找到其他子系统，我们只招数据总线，数据总线再根据统一标准找其他子系统，所以数据总线在这里充当一个只路人的作用。
SOA的好处：
1、降低用户成本，用户不需要关心各服务之间是什么语言的、不需要知道如果调用他们，只要通过统一标准找数据总线就可以了。
2、程序之间关系服务简单
3、识别哪些程序有问题（挂掉）
缺点：提示了系统的复杂程度，性能有相应影响。
三、数据总线是什么？
其实我在上面写了，数据总线是起到调度服务的作用，数据总线不是集成服务，数据总线更新一个调度框架，每个服务需要根据约定向数据总线注册服务，那么如何注册那？其实数据总线就像一个字典结构，
数据总线里面一个key对于一个value，key指的是服务名，value则是服务的调度方式，还有一点需要说明的是，数据总线只是指路人，服务是不经过数据总线的，如上图的黄色线的路径。
数据总线通过域名解析实现:一个域名绑定多台服务器，ajax也可以，dns也可以，解析域名嘛。
其实数据总线还有一些高级应用，比如心跳检测，实现负载均衡等等，就不细说了，目前应用数据总线的有阿里的dubbo,还有zookeeper。
了解完soa之后，还是回到服务之间的调用问题，每一个服务跨进程调用其他服务会用到一种技术----------------------
RPC
RPC，全称为Remote Procedure Call，即远程过程调用，它是一个计算机通信协议。它允许像调用本地服务一样调用远程服务。它可以有不同的实现方式。如RMI(远程方法调用)、Hessian、Http invoker等。另外，RPC是与语言无关的。
如上图所示，假设Computer1在调用sayHi()方法，对于Computer1而言调用sayHi()方法就像调用本地方法一样，调用 –>返回。但从后续调用可以看出Computer1调用的是Computer2中的sayHi()方法，RPC屏蔽了底层的实现细节，让调用者无需关注网络通信，数据传输等细节。rpc的实现方式和原理先不谈，总之服务之间是通过rpc（远程过程调用）来相互调用的。
现在多个服务之间进行调用，每一个服务去调用或者获取另一个服务的时候会有很多的地址信息，如果某一服务做了集群，会有更多的地址信息。还有，如果，一个服务发送了地址信息，如ip：port请求，但是另一服务down机了怎么办，该怎么感知服务节点状态的变化呢？总结一下问题所在是：
1.消费端如何对多个地址进行负载
服务之间互相发送请求时的地址可以注册在统一的一个地方，每个服务只需要知道这个服务中心的地址ip就可以拿到所有其他服务的地址簿。这个地址维护服务中心很常见，如zookeeper，eureka，etcd、redis等。如下图所示
2.如何动态感知服务节点的变化
在这里，主要介绍一下ZooKeeper的实现原理
1.简介
ZooKeeper 是一个开源的分布式协调服务，由雅虎创建，是 Google Chubby 的开源实现。分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
2.Zookeeper文件系统
每个子目录项如 NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：
<1>、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
<2>、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
<3>、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
<4>、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
3.Zookeeper通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
4.Zookeeper的作用
（1）.命名服务
在zookeeper的文件系统里创建一个目录，即有唯一的path。
其中较为常见的就是一些分布式服务框架（如RPC、RMI）中的服务地址列表。通过在ZooKeepr里创建顺序节点，能够很容易创建一个全局唯一的路径，这个路径就可以作为一个名字。
ZooKeeper 的命名服务即生成全局唯一的ID。
（2）.配置管理
程序总是需要配置的，如果程序或者服务分散部署在多台机器上时，要逐个改变配置就变得困难。现在把这些配置全部放在zookeeper上去，保存在zookeeper的某个目录中去，然后所有的目录文件都对这个目录文件进行监听（watch，和监视一样，哈哈），一旦配置信息发生变化，每个应用程序都会收到zookeeper的通知，然后从zookeeper获取新的配置信息到系统中去就好，如下图所示。
（3）.Zookeeper集群管理
所谓集群管理无在乎两点：是否有机器退出和加入、选举master
就像帮派一样，管理帮派无非也是两点，第一点就是帮派人员的退出和加入，还有就是帮派老大的选举
对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。
新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了，对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
（4）.Zookeeper分布式锁
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
（5）.Zookeeper队列管理
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
（6）.分布式与数据复制
Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。
从客户端读写访问的透明度来看，数据复制集群系统分下面两种：
1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；
2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
对zookeeper来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
（7）.Zookeeper角色描述
（8）.Zookeeper与客户端
（9）.Zookeeper设计目的
1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
2.可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
（10）.Zookeeper工作原理
Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
