一种高可用性、高性能、高实时性的服务器架构设计
【主要从期货市场的需求获取灵感】
一、需求
(一)、高可用性
1、持续运行无间断
2、单点故障不影响
3、运行期间可监控
4、故障可跟踪排查
5、失败恢复无间隔
(二)、高性能
6、负载均衡高并行
(三)、高实时性
7、请求响应低时延
8、变化可主动通知
二、关键点分析
1、网络故障的处理
(1)、网络线路故障
(2)、网络传输失败
(3)、网络应用阻塞
(4)、网络应用异常
2、应用故障的处理
(1)、应用系统崩溃
(2)、应用逻辑处理失败
(3)、应用资源分配失败
(4)、应用请求调度拒绝
3、负载均衡和多点传输
(1)、请求的多点分配
(2)、报文缓冲失败重路由
(3)、负载均衡和事务的可延续性
4、实体标识
(1)、标识的全局唯一性
(2)、实体的可定位性
(3)、实体名字、实体标识、实体位置
三、一些构想
1、构建一个虚拟网络，这个网络基于TCP/UDP传输层之上，保证在这个网络中传输的数据是完全、可靠、快速的。
2、在这个网络中网络的所有实体都有一个唯一的名字，这个名字可以是固定的，也可以是动态，但是作为提供服务的实体必须有固定的名字
3、实体标识是由某个管理器统一分配的，在实体在网络的存续期间是固定的，可以在管理器负责的范围内必须是唯一的，但不要求全局唯一
4、实体位置可以是动态的，只要实体的接入点知道就可以了。他必须由实体标识绑定
5、任何一个实体，他的数据来源可以是多个的，相当于安装了多个网卡。
6、多个实体之间可以互相绑定，支持名字的重新绑定。当某个实体发生故障，可以由这一组中的任意一个实体绑定发生失败的那个实体的名字，来模拟原实体处理后续的报文。
7、在这个虚拟网络中，建立一个负载均衡器，每个均衡器负责调度若干个实体，均衡器负责分配所有的请求，返回的结果可以通过均衡器转发，也直接由这些实体输入到虚拟网络中。
8、多个均衡器可以连接到同一个负载实体，均衡器和负载实体的通讯协议由他们之间规定，和虚拟网络中各个实体的通讯协议可以不同。
9、保证每个实体可以从多个网络路径接入虚拟网络，避免单个网络路径故障，导致服务无法继续。
10、在虚拟网络，所有的实体具有唯一的标识，这个标识可以为网络直接识别和路由。实体名字不为虚拟网络识别，但可以转化为实体标识。
11、虚拟网络建立的是一个数据传输通道，负载均衡器和实体名字动态绑定是网络高可用性和高性能的一个策略。
12、当虚拟网络建立之后，可以在这个网络上建立服务管理器平台。服务管理器平台只提供服务的运行环境，他本身不直接实现业务逻辑，每个业务逻辑可以独立实现，或者共存于同一个服务管理器平台上。
13、业务逻辑不是虚拟网络上的实体，所以他没有虚拟网络上实体名字，但他也是同样是有名字，不过需要通过网络实体来先定位，然后通过网络实体来再定位服务名字。
14、如果是服务管理器平台通过均衡器连接入虚拟网络中，那么均衡器充当的是网关的作用，他将目标位置修改为某个服务管理器，就可以将包转发到正确的服务器上。
15、事务性是这个服务器必须处理的问题，如果记录和存储某个请求的上下文关系呢？显然，在一般情况，由执行具体业务逻辑的服务来记录是最好的选择，但一旦通过均衡性来连接网络，就必须保证后续的请求到达同一个业务逻辑的服务。
16、对于服务管理器平台来说，当他通过均衡器连接虚拟网络或者直接连接虚拟网络时，如何采用相同的策略保证事务性呢是必须考虑的问题。显然，服务管理器平台本身负责需要负责事务状态性的维护，但是均衡器也必须对状态性进行维护，否则他无法保证正确发送事务后续报文到到指定的服务。
17、由于处于负载均衡和高可用性的考虑，必须允许服务之间可以互相接管。当一个服务被其他服务接管时，那么这个服务原来操作的信息同样也可以被其他服务使用，于是必须允许信息在服务之间进行转移。
18、实体名字可以采用URI协议，通用资源标识，格式为PROTOCOL://SERVER_PATH/SERVER_NAME，默认情况下，PROTOCOL为FILE。文件、套接字等，都可以通过这个标识来识别。名字的解析和定位可以通过专门的组件来负责。
19、服务和服务之间的通讯同样可以通过URI来定位。由于虚拟网络只能识别标识符，所以名字到标识符之间的转换同样是必须的。
20、事务的可靠性可以通过存储、重发、重新路由。但是这种可靠性是否需要由路由器来完成，还是直接由发送端或者接收端负责呢，这个问题需要斟酌。如果由路由器完成可靠性，那么当报文到达接收端的时候，可能已经超出发送端可接受的程度，那么对发送端来说，如果认为他已经失败了，而重发了新的请求，那么已经传输到接收端的报文应该如何处理呢。
21、当一个事务报文到达服务管理器时，可以认为这个报文已经传输完毕，这个报文允许停留在管理器里，由调度系统分配给具体服务实体。管理器在调度报文时，必须注意报文可能存在的合并规则。
22、当一个报文的处理环境要求上下文支持时，允许从服务管理器提取上下文环境。这个上下文应该可以支持特定用户的，或者说应该是会话级的，甚至是更小粒度的事务级的。
23、对服务实体来说，最好是单进程的，可以避免服务实体之间的互相影响，也便于服务管理器对他们的操作。当然，将服务实体以共享库的方式嵌入到管理器中，作为一个子模块也是允许的。参考WINDOWS的MMC和LINUX的XINETD这样的管理方式，APACHE以及JABBERD都是将模块运行在主进程中，这样的方式也是可以的。每个方式都有利弊，需要使用辅助的手段趋利避害，增加可用性。
24、如果是单进程的，那么可以启动另外一个进程来STANDBY，当主进程失败时，那么STANDBY进程马上接管。这种方式必须处理进程的数据可以共享，以及哪些数据需要共享。因为当STANDBY进程成为主进程时，必须尽量少初始化环境而尽量多地使用原来主进程的数据。
25、如果是多进程的，那么高可用性同样也可以借鉴STANDBY方式，但重新启动失败进程也是可以考虑，只要在可接受时间内完成。正在处理时的事务必须能够取消，重新开始，或者从失败点继续完成。关于事务进展的粒度和状况就必须是可跟踪而且是可记录的。
26、不同负载体之间的均衡可能存在某些会话或者事务在负载体之间进行转移，允许部分数据或者全部数据在负载体之间进行交换是必须考虑的问题。
27、状态的可监控性，错误的可跟踪性是保证系统高可用性的一个重要措施。增加系统接口，保证服务实体可以对自己的正确性、完整性、一致性进行监控。
28、当某个条件被触发时，必须主动通知需要知道这些事件的实体，这样可以提高实体反应的实体性。
29、实时触发的事件以及对这个事件的反应时间差必须很短,反应时间差是实时性的一个重要标识。事件驱动以及如何处理低速过程或者是长等待过程和高速过程之间的矛盾是必须注意的。这个可以借鉴WINDOWS的完成端口方式或者是LINUX的EPOLL模型。先注册需要关注的事件，当这些事件出现的时候，管理器将这些完成的事件及其附加信息返回给请求者。服务实体或者管理器将资源请求过程转交给其他进程、线程，然后继续处理。只能当资源被满足后，才处理特定的事务。
30、自动升级也是建议被支持的，这对系统的维护至关重要。不过同样需要注意的是，自动升级后，在不同版本之间的兼容性。必须允许存在不同的版本协同运行。升级失败和可在失败点继续也是需要考虑的问题。即使升级失败了，保持原系统依然可用是必须保证的。
31、虚拟网络、服务管理器、服务实体的升级必须有不同考虑，虚拟网络本身升级的话是能否通过自身传输是需要重要考虑的。通过应用层传输升级文件，然后自动重新启动，这个过程有点象操作系统的自动重启。在虚拟网络重新启动的时候最好能够被无缝接管，当虚拟网络启动完成后，向其他实体宣告自身。
32、服务管理器、服务实体的升级是在应用级别的系统。这些系统的升级和虚拟网络稍微简单一点。如果将自动升级视为一个服务，那么服务管理器也面临和虚拟网络同样的问题，不过这些采取和虚拟网络一样的策略。由上层应用传输数据，然后执行本层系统一个指令来完成自动升级这个过程。
33、虚拟网络主要负责寻址和报文传输的过程，这个过程可以基于不同的传输层协议，如TCP、UDP、IPX等。所以虚拟网络中传输的报文可以是独立的，报文的边界最好参考UDP那样，直接由网络层保证。TCP的数据流在很多方面有不少限制，多数情况下，应用的报文应该是有边界的。将现在网络的功能模块可以部分移植到虚拟网络上，虚拟网络的功能模块实际有部分可以借鉴现实网络的功能模块。
34、XML的扩展性和灵活性是很有优势的，但是的解析速度在高实时性的要求下有很有缺陷。在系统内部可以使用类XML，但是处理速度更加迅速的格式，我们可以通过接口将我们内部的格式输出为XML格式，并且将外部的XML格式转化为内部自己的格式。
35、一个类XML格式，类型1＋长度＋类型2，可以标定一个标签。如果类型2是个数据类型，那么后继的缓冲区是类型1标签携带的数据。我们可以将类型预先定义几个公共类型，同时必须提供扩展接口供其他需求使用。由于XML的字符必须符合一定的规范，所以需要考虑双向转化的问题。
36、必须提供辅助工具，将原来的、基于传统网络协议的应用连接到虚拟网络中，这样可以无缝连接和转化。比如HTTP、FTP等应用。
四、模块设计
1、系统级接口，主要实现类操作系统的功能，可以在这个层次实现跨平台功能。
2、资源管理器，将所有的资源访问按统一格式处理，类似于LINUX的文件系统，提供一个简单的访问接口。
3、资源标识分析器，按统一格式对资源进行归类，可以将资源使用一定格式的字符串进行标识。对这个字符串可以反向解读出他的实际含义，并调用相应的处理机制。
4、虚拟网络路由以及报文传输。
5、进程间的互相守护，互相检测，进行主副备份。
6、负载均衡器和多路由接收器
7、事件管理器，允许注册监听器。
8、连续区间的多段可连续增长和回收。
9、编码和解码算法，主要考虑算法时间复杂度和加密强度
一、需求
(一)、高可用性
1、持续运行无间断
2、单点故障不影响
3、运行期间可监控
4、故障可跟踪排查
5、失败恢复无间隔
(二)、高性能
6、负载均衡高并行
(三)、高实时性
7、请求响应低时延
8、变化可主动通知
二、关键点分析
1、网络故障的处理
(1)、网络线路故障
(2)、网络传输失败
(3)、网络应用阻塞
(4)、网络应用异常
2、应用故障的处理
(1)、应用系统崩溃
(2)、应用逻辑处理失败
(3)、应用资源分配失败
(4)、应用请求调度拒绝
3、负载均衡和多点传输
(1)、请求的多点分配
(2)、报文缓冲失败重路由
(3)、负载均衡和事务的可延续性
4、实体标识
(1)、标识的全局唯一性
(2)、实体的可定位性
(3)、实体名字、实体标识、实体位置
三、一些构想
1、构建一个虚拟网络，这个网络基于TCP/UDP传输层之上，保证在这个网络中传输的数据是完全、可靠、快速的。
2、在这个网络中网络的所有实体都有一个唯一的名字，这个名字可以是固定的，也可以是动态，但是作为提供服务的实体必须有固定的名字
3、实体标识是由某个管理器统一分配的，在实体在网络的存续期间是固定的，可以在管理器负责的范围内必须是唯一的，但不要求全局唯一
4、实体位置可以是动态的，只要实体的接入点知道就可以了。他必须由实体标识绑定
5、任何一个实体，他的数据来源可以是多个的，相当于安装了多个网卡。
6、多个实体之间可以互相绑定，支持名字的重新绑定。当某个实体发生故障，可以由这一组中的任意一个实体绑定发生失败的那个实体的名字，来模拟原实体处理后续的报文。
7、在这个虚拟网络中，建立一个负载均衡器，每个均衡器负责调度若干个实体，均衡器负责分配所有的请求，返回的结果可以通过均衡器转发，也直接由这些实体输入到虚拟网络中。
8、多个均衡器可以连接到同一个负载实体，均衡器和负载实体的通讯协议由他们之间规定，和虚拟网络中各个实体的通讯协议可以不同。
9、保证每个实体可以从多个网络路径接入虚拟网络，避免单个网络路径故障，导致服务无法继续。
10、在虚拟网络，所有的实体具有唯一的标识，这个标识可以为网络直接识别和路由。实体名字不为虚拟网络识别，但可以转化为实体标识。
11、虚拟网络建立的是一个数据传输通道，负载均衡器和实体名字动态绑定是网络高可用性和高性能的一个策略。
12、当虚拟网络建立之后，可以在这个网络上建立服务管理器平台。服务管理器平台只提供服务的运行环境，他本身不直接实现业务逻辑，每个业务逻辑可以独立实现，或者共存于同一个服务管理器平台上。
13、业务逻辑不是虚拟网络上的实体，所以他没有虚拟网络上实体名字，但他也是同样是有名字，不过需要通过网络实体来先定位，然后通过网络实体来再定位服务名字。
14、如果是服务管理器平台通过均衡器连接入虚拟网络中，那么均衡器充当的是网关的作用，他将目标位置修改为某个服务管理器，就可以将包转发到正确的服务器上。
15、事务性是这个服务器必须处理的问题，如果记录和存储某个请求的上下文关系呢？显然，在一般情况，由执行具体业务逻辑的服务来记录是最好的选择，但一旦通过均衡性来连接网络，就必须保证后续的请求到达同一个业务逻辑的服务。
16、对于服务管理器平台来说，当他通过均衡器连接虚拟网络或者直接连接虚拟网络时，如何采用相同的策略保证事务性呢是必须考虑的问题。显然，服务管理器平台本身负责需要负责事务状态性的维护，但是均衡器也必须对状态性进行维护，否则他无法保证正确发送事务后续报文到到指定的服务。
17、由于处于负载均衡和高可用性的考虑，必须允许服务之间可以互相接管。当一个服务被其他服务接管时，那么这个服务原来操作的信息同样也可以被其他服务使用，于是必须允许信息在服务之间进行转移。
18、实体名字可以采用URI协议，通用资源标识，格式为PROTOCOL://SERVER_PATH/SERVER_NAME，默认情况下，PROTOCOL为FILE。文件、套接字等，都可以通过这个标识来识别。名字的解析和定位可以通过专门的组件来负责。
19、服务和服务之间的通讯同样可以通过URI来定位。由于虚拟网络只能识别标识符，所以名字到标识符之间的转换同样是必须的。
20、事务的可靠性可以通过存储、重发、重新路由。但是这种可靠性是否需要由路由器来完成，还是直接由发送端或者接收端负责呢，这个问题需要斟酌。如果由路由器完成可靠性，那么当报文到达接收端的时候，可能已经超出发送端可接受的程度，那么对发送端来说，如果认为他已经失败了，而重发了新的请求，那么已经传输到接收端的报文应该如何处理呢。
21、当一个事务报文到达服务管理器时，可以认为这个报文已经传输完毕，这个报文允许停留在管理器里，由调度系统分配给具体服务实体。管理器在调度报文时，必须注意报文可能存在的合并规则。
22、当一个报文的处理环境要求上下文支持时，允许从服务管理器提取上下文环境。这个上下文应该可以支持特定用户的，或者说应该是会话级的，甚至是更小粒度的事务级的。
23、对服务实体来说，最好是单进程的，可以避免服务实体之间的互相影响，也便于服务管理器对他们的操作。当然，将服务实体以共享库的方式嵌入到管理器中，作为一个子模块也是允许的。参考WINDOWS的MMC和LINUX的XINETD这样的管理方式，APACHE以及JABBERD都是将模块运行在主进程中，这样的方式也是可以的。每个方式都有利弊，需要使用辅助的手段趋利避害，增加可用性。
24、如果是单进程的，那么可以启动另外一个进程来STANDBY，当主进程失败时，那么STANDBY进程马上接管。这种方式必须处理进程的数据可以共享，以及哪些数据需要共享。因为当STANDBY进程成为主进程时，必须尽量少初始化环境而尽量多地使用原来主进程的数据。
25、如果是多进程的，那么高可用性同样也可以借鉴STANDBY方式，但重新启动失败进程也是可以考虑，只要在可接受时间内完成。正在处理时的事务必须能够取消，重新开始，或者从失败点继续完成。关于事务进展的粒度和状况就必须是可跟踪而且是可记录的。
26、不同负载体之间的均衡可能存在某些会话或者事务在负载体之间进行转移，允许部分数据或者全部数据在负载体之间进行交换是必须考虑的问题。
27、状态的可监控性，错误的可跟踪性是保证系统高可用性的一个重要措施。增加系统接口，保证服务实体可以对自己的正确性、完整性、一致性进行监控。
28、当某个条件被触发时，必须主动通知需要知道这些事件的实体，这样可以提高实体反应的实体性。
29、实时触发的事件以及对这个事件的反应时间差必须很短,反应时间差是实时性的一个重要标识。事件驱动以及如何处理低速过程或者是长等待过程和高速过程之间的矛盾是必须注意的。这个可以借鉴WINDOWS的完成端口方式或者是LINUX的EPOLL模型。先注册需要关注的事件，当这些事件出现的时候，管理器将这些完成的事件及其附加信息返回给请求者。服务实体或者管理器将资源请求过程转交给其他进程、线程，然后继续处理。只能当资源被满足后，才处理特定的事务。
30、自动升级也是建议被支持的，这对系统的维护至关重要。不过同样需要注意的是，自动升级后，在不同版本之间的兼容性。必须允许存在不同的版本协同运行。升级失败和可在失败点继续也是需要考虑的问题。即使升级失败了，保持原系统依然可用是必须保证的。
31、虚拟网络、服务管理器、服务实体的升级必须有不同考虑，虚拟网络本身升级的话是能否通过自身传输是需要重要考虑的。通过应用层传输升级文件，然后自动重新启动，这个过程有点象操作系统的自动重启。在虚拟网络重新启动的时候最好能够被无缝接管，当虚拟网络启动完成后，向其他实体宣告自身。
32、服务管理器、服务实体的升级是在应用级别的系统。这些系统的升级和虚拟网络稍微简单一点。如果将自动升级视为一个服务，那么服务管理器也面临和虚拟网络同样的问题，不过这些采取和虚拟网络一样的策略。由上层应用传输数据，然后执行本层系统一个指令来完成自动升级这个过程。
33、虚拟网络主要负责寻址和报文传输的过程，这个过程可以基于不同的传输层协议，如TCP、UDP、IPX等。所以虚拟网络中传输的报文可以是独立的，报文的边界最好参考UDP那样，直接由网络层保证。TCP的数据流在很多方面有不少限制，多数情况下，应用的报文应该是有边界的。将现在网络的功能模块可以部分移植到虚拟网络上，虚拟网络的功能模块实际有部分可以借鉴现实网络的功能模块。
34、XML的扩展性和灵活性是很有优势的，但是的解析速度在高实时性的要求下有很有缺陷。在系统内部可以使用类XML，但是处理速度更加迅速的格式，我们可以通过接口将我们内部的格式输出为XML格式，并且将外部的XML格式转化为内部自己的格式。
35、一个类XML格式，类型1＋长度＋类型2，可以标定一个标签。如果类型2是个数据类型，那么后继的缓冲区是类型1标签携带的数据。我们可以将类型预先定义几个公共类型，同时必须提供扩展接口供其他需求使用。由于XML的字符必须符合一定的规范，所以需要考虑双向转化的问题。
36、必须提供辅助工具，将原来的、基于传统网络协议的应用连接到虚拟网络中，这样可以无缝连接和转化。比如HTTP、FTP等应用。
四、模块设计
1、系统级接口，主要实现类操作系统的功能，可以在这个层次实现跨平台功能。
2、资源管理器，将所有的资源访问按统一格式处理，类似于LINUX的文件系统，提供一个简单的访问接口。
3、资源标识分析器，按统一格式对资源进行归类，可以将资源使用一定格式的字符串进行标识。对这个字符串可以反向解读出他的实际含义，并调用相应的处理机制。
4、虚拟网络路由以及报文传输。
5、进程间的互相守护，互相检测，进行主副备份。
6、负载均衡器和多路由接收器
7、事件管理器，允许注册监听器。
8、连续区间的多段可连续增长和回收。
9、编码和解码算法，主要考虑算法时间复杂度和加密强度