服务发现和资源发现

1 几种服务器/客户端工作模式

1.1 一对多CS模式

一对多CS模式虽然构建简单，但是缺陷也很明显，就是整个App只依靠一个服务器进行工作，唯一一台服务器承担着整个系统的负载，一旦这台服务器异常宕机，那么整个App就无法正常使用

1.2 CS模式下的服务器集群

为了避免一对多CS模式的缺陷，可以搭建服务器集群，即多台服务器一起支撑整个App的工作

通过搭建服务器集群，可以提高整个App的容错率，但是这样的模式也存在着弊端：
1，某台客户端从上线，登录，发起请求到下线的整个过程和服务器都是采用长连接的方式，过于消耗系统资源
2，如果多台客户端连接到同一台服务器，那么这台服务器会一直承受较高的负载，无法高效率工作

1.3 BS模式下的服务器集群

为了解决CS模式下服务器集群带来的弊端，可以采用BS模式下搭建服务器集群的方式来解决：

通过在客户端建立一个服务器地址列表，通过RMI技术，让客户端的每次请求发向“随机”的服务器，如某台客户端A的上线请求被发到了服务器1，资源请求被发向了服务器2，查询数据请求被发向了服务器3，由于RMI(远程方法调用是通过代理实现的)，所以每次请求都是一次短连接，这样就避免了持续长连接带来的系统资源消耗，且请求被“随机”发向了不同的服务器，能保证每台服务器承受合理的压力，即负载均衡

这种结构的核心在于客户端拥有一个及时更新的服务器地址列表，每次请求“随机”从该列表中选取一个服务器地址发送请求，这样不但能实现负载均衡还能实现服务器热插拔

负载均衡:
	服务器集群中的每台服务器保持合理的工作负载
	即尽量保证每台服务器收到差不多数量的请求

服务器热插拔:
	当某台服务器需要更新，或需要增加一台新的服务器加入App网络
	只需要直接更新客户端的服务器地址列表即可
	就能让服务器轻松的下线维护，或直接上线就投入工作

2 服务发现

了解上述几种服务器工作模式后，可以看到BS模式的服务器集群貌似是最优解，这种模式的优点如下:

1，更强的系统安全
	避免单一服务器异常宕机导致整个App崩溃

2，服务器负载均衡
	每个服务器处理差不多数量的请求，保证每台服务器高效率工作

3，服务器热插拔
	在线维护/增加服务器，且不影响客户端使用体验

现在考虑这样的一种应用场景：
一个机房有若干台服务器，但这里的服务器并不是为一个App提供服务，即机房里的一些服务器属于App1，一些属于App2…，那么客户端该如何找到属于自己的服务器？这也是BS模式下服务器集群方式的问题，客户端如何得到一个能及时更新的服务器地址列表？

2.1 注册中心

为此可以在整个网络中引入一个额外的服务器，作为注册中心，机房内的每台服务器都在注册中心内进行注册(将自己的地址和端口号，以及当前的负载状况交给注册中心)，客户端通过定时访问注册中心或注册中心主动向客户端推送服务器地址列表

有了注册中心，客户端就能得到服务器地址列表，从中“随机”取得某个服务器地址发送请求

注册中心的功能：

1，对服务器:
	管理服务器地址的注册，注销

2，对客户端:
	进行服务器地址的广播

注册中心不参与任何的业务逻辑处理，只负责管理服务器地址和向客户端返回服务器地址列表

2.2 发现服务

服务发现=发现服务(器)，即客户端能获知合理的服务器地址列表，从中“随机”选择某个服务器地址发起请求，服务发现的核心就是注册中心，注册中心管理多种服务器，注册中心负责管理服务器地址的注册/销毁和向客户端返回合理的服务器地址列表

注册中心在整个网络中是独立于业务逻辑的，且它能管理多种服务器，也就是说注册中心能为多种App提供服务

3 《多文件自平衡断点续传云传输》项目简介

3.1 需求场景

在Web工程中，资源的请求(图片，音视频，文本…)是十分常见的，而所谓的资源就是一个个文件，考虑如下的一个视频应用：

客户端能向服务器发起资源请求，服务器收到后响应该请求，并回传资源，
但是此时如果有30个客户端同时请求同一个视频文件，
那么拥有该视频的服务器就需要将该视频发送30次，
这样的操作虽然在逻辑上并无大碍，但是明显有更好的解决方案

如果现在客户端A请求了1.MP4文件，服务器响应了该请求，客户端成功接收到了1.MP4文件，但此时客户端B发起了对1.MP4的请求，此时能否让拥有1.MP4的客户端和服务器同时向客户端B发送1.MP4的片段，即模糊了服务器和客户端的界限，将整个网路中的机器分为资源拥有者和资源请求者

每当一个资源请求者发起对某个资源的请求，拥有该资源的资源拥有者将各自发送该资源的一部分片段，资源请求者持续地接收这些文件片段，直到能组织成完整正确地文件，资源拥有者停止发送，这个资源请求者变成了该资源的资源拥有者，当下一次出现对该资源的请求时，这台机器也会加入到发送资源片段的队列中

通过这样的方式，能极大的降低服务器的负载，且能够高效快速传输大量文件，整个App中的机器物尽其用，服务器和客户端之间差别被模糊

3.2 功能简介

上述发送文件的构思就是《多文件自平衡断点续传云传输》的功能，在《多文件》中：

多文件: 不仅仅能传输一个文件，甚至能传输整个目录下某个系统的所有文件
	(如将整个视频系统传输，不仅仅是视频，还有支持视频播放的各种文件)

自平衡: 动态控制分发资源的资源拥有者数量
	(当某台机器请求资源时，动态控制资源拥有者发送资源
		让每台机器都合理公平地参与资源发送，不过度影响自己的工作效率)

断点续传: 传输出现异常时，能及时记录传输断点
	(资源请求者/资源拥有者关机，能够记录接收资源的进度
		以便下次从断点开始继续接收资源)

云传输: App中没有核心，每台机器都可以发送资源
	(免传统模式中唯一拥有资源的服务器重复的分发资源
		极大降低了服务器的负载)	

而《多文件》的实现就需要依靠资源发现

4 资源发现

考虑《多文件》的功能，其中一个关键点是资源请求者如何得知哪些机器拥有自己请求的资源？

这个问题很像之前的服务发现，因为只有知道资源拥有者地址列表，才能要求它们给资源请求者发送文件片段，而资源请求者获取资源拥有者地址列表的过程，自然可以通过一个额外的服务器，即资源中心来完成

3.1 资源中心

对比服务发现中的注册中心，那么资源中心就是用来管理某个资源的资源拥有者地址列表，并将资源拥有者地址列表返回给资源请求者

资源中心也不会关心任何的业务逻辑，只需要注册/销毁资源拥有者，向资源请求者返回资源拥有者地址列表

3.2 发现资源

资源发现也就是发现资源(拥有者)，即资源中心能够管理某个资源的所有资源拥有者，当某个资源请求者请求该资源时，那么资源中心会返回给该资源请求者一个资源拥有者地址列表，接着资源请求者会向这些资源拥有者发起请求，当该资源请求者获得了完整的资源后，它会将自己注册到资源中心内，成为该资源的资源拥有者

资源中心不关心任何的业务逻辑，只负责资源拥有者的管理和资源请求者广播资源拥有者地址列表

资源发现不仅仅能管理一个App内的资源，甚至能跨越App，如App1中的客户端能通过资源中心向App2的服务器发起资源请求，App2的客户端能发送资源给App3的客户端，在资源发现中，服务器和客户端的关系变得模糊，取而代之的是资源拥有者和资源请求者，每台机器都能够发送资源，极大降低了服务器的负载，使得整个App高效运作