转至元数据结尾
WebService接口调度平台实现高可行性方案
作者：郑房新 文档编号：SUNLIGHT20160630F013
启用日期：2016-06-30
文档状态：【■】草稿 【 】正在修改 【 】正式发布
审批人：
版本：V4.0
目录
一、概述... 3
1.1 计算机的高可用性... 3
1.2 负载均衡服务器的高可用性... 3
1.3 高可用性HA的容错备援运作过程... 3
1.4 HA三种工作方式... 3
1.5 高可用性高可用性的衡量指标... 3
1.6 高可用性高可用性系统的设计... 3
1.7 高可用性导致计划内的停机因素有... 4
1.8 高可用性导致计划外停机的因素有... 4
1.9 高可用性创建高可用性的计算机系统... 4
二、可行性方案设计... 5
2.1 WebService接口调度平台高可用可行性方案模型图... 5
2.1.1 调度平台整体设计（全局）：... 5
2.1.2 DCS服务器端调度高可用可行性方案模型图（局部）... 6
2.2 需要考虑的四个问题... 7
(1) 如何避免调度程序读取DMS Portal数据库数据时出现重复读。... 7
(2) 如何避免调度程序读取文件数据时出现重复读... 7
(3) 如何确保文件若采用FTP方式进行读写时产生效率问题。... 7
(4) 是否能够使用数据库替代文件进行数据存储。... 7
(5) 如何确保每个调度程序都被充分使用。... 7
2.3 可行性判断... 7
1 如何避免调度程序读取DMS Portal数据库数据时出现重复读。... 7
2 如何避免调度程序读取文件数据时出现重复读。... 7
3 如何确保文件若采用FTP方式进行读写时产生效率问题。... 7
4 是否能够使用数据库替代文件进行数据存储。... 9
5 如何确保每个调度程序都在被使用。... 10
一、概述
“高可用性”（HA：High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。
1.1 计算机的高可用性
计算机系统的可靠性用平均无故障时间（MTTF）来度量，即计算机系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。可维护性用平均维修时间（MTTR）来度量，即系统发生故障后维修和重新恢复正常运行平均花费的时间。系统的可维护性越好，平均维修时间越短。计算机系统的可用性定义为：MTTF/(MTTF+MTTR) * 100%。由此可见，计算机系统的可用性定义为系统保持正常运行时间的百分比。
1.2 负载均衡服务器的高可用性
为了屏蔽负载均衡服务器的失效，需要建立一个备份机。主服务器和备份机上都运行High Availability监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主管理器就开始再次进行集群管理的工作了。为在主服务器失效的情况下系统能正常工作，我们在主、备份机之间实现负载集群系统配置信息的同步与备份，保持二者系统的基本一致。
1.3 高可用性HA的容错备援运作过程
自动侦测(Auto-Detect)阶段由主机上的软件通过冗余侦测线，经由复杂的监听程序。逻辑判断，来相互侦测对方运行的情况，所检查的项目有：主机硬件(CPU和周边)、主机网络、主机操作系统、数据库引擎及其它应用程序、主机与磁盘阵列连线。为确保侦测的正确性，而防止错误的判断，可设定安全侦测时间，包括侦测时间间隔，侦测次数以调整安全系数，并且由主机的冗余通信连线，将所汇集的讯息记录下来，以供维护参考。
自动切换(Auto-Switch)阶段 某一主机如果确认对方故障，则正常主机除继续进行原来的任务，还将依据各种容错备援模式接管预先设定的备援作业程序，并进行后续的程序及服务。
自动恢复(Auto-Recovery)阶段在正常主机代替故障主机工作后，故障主机可离线进行修复工作。在故障主机修复后，透过冗余通讯线与原正常主机连线，自动切换回修复完成的主机上。整个恢复过程完成由EDI-HA自动完成，亦可依据预先配置，选择回复动作为半自动或不恢复。
为了实现平台的高效性和稳定性以及安全性，DCS服务端调度配置多台机器同时运行，参考负载均衡的原理，设计本方案。
1.4 HA三种工作方式
（1）主从方式 （非对称方式）
工作原理：主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
（2）双机双工方式（互备互援）
工作原理：两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
（3）集群工作方式（多服务器互备方式）
工作原理：多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。
什么是高可用性（HA）
1.5 高可用性高可用性的衡量指标
可用性的计算公式：
availability=（Total Elapsed Time－Sum of Inoperative Times）/ Total Elapsed Time
elapsed time为operating time+downtime。
可用性和系统组件的失败率相关。衡量系统设备失败率的一个指标是“失败间隔平均时间”MTBF（mean time between failures）。通常这个指标衡量系统的组件，如磁盘。
MTBF=Total Operating Time / Total No. of Failures
Operating time为系统在使用的时间（不包含停机情况）。
1.6 高可用性高可用性系统的设计
设计系统的可用性，最重要的是满足用户的需求。系统的失败只有当其导致服务的失效性足以影响到系统用户的需求时才会影响其可用性的指标。用户的敏感性决定于系统提供的应用。例如，在一个能在1秒钟之内被修复的失败在一些联机事务处理系统中并不会被感知到，但如果是对于一个实时的科学计算应用系统，则是不可被接受的。
系统的高可用性设计决定于您的应用。例如，如果几个小时的计划停机时间是可接受的，也许存储系统就不用设计为磁盘可热插拔的。反之，你可能就应该采用可热插拔、热交换和镜像的磁盘系统。
所以涉及高可用系统需要考虑：
决定业务中断的持续时间。根据公式计算出的衡量HA的指标，可以得到一段时间内可以中断的时间。但可能很大量的短时间中断是可以忍受的，而少量长时间的中断却是不可忍受的。
在统计中表明，造成非计划的宕机因素并非都是硬件问题。硬件问题只占40%，软件问题占30%，人为因素占20%，环境因素占10%。您的高可用性系统应该能尽可能地考虑到上述所有因素。
当出现业务中断时，尽快恢复的手段。
1.7 高可用性导致计划内的停机因素有
周期性的备份
软件升级
硬件扩充或维修
系统配置更改
数据更改
1.8 高可用性导致计划外停机的因素有
硬件失败
文件系统满错误
备份失败
磁盘满
供电失败
网络失败
应用失败
自然灾害
操作或管理失误
通过有针对性的设计，可以避免上述全部或部分因素带来的损失。当然，100%的高可用系统是不存在的。
1.9 高可用性创建高可用性的计算机系统
在系统上创建高可用性计算机系统，业界的通行做法，也是非常有效的做法，就是采用群集系统（Cluster），将各个主机系统通过网络或其他手段有机地组成一个群体，共同对外提供服务。创建群集系统，通过实现高可用性的软件将冗余的高可用性的硬件组件和软件组件组合起来，消除单点故障：
消除供电的单点故障
消除磁盘的单点故障
消除SPU（System Process Unit）单点故障
消除网络单点故障
消除软件单点故障
尽量消除单系统运行时的单点故障
二、可行性方案设计
2.1 WebService接口调度平台高可用可行性方案模型图
为实现WebService接口调度平台的高可用性，设计WebService接口平台高可用可行性方案，模型如如下所示：
2.1.1 调度平台整体设计（全局）：
(1) 设置DMS Portal调度程序组（Windows Service）：由两个及两个以上的调度程序组成，采用双机双工方式（互备互援），工作原理：两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
(2) 设置DMS Portal接口组(Web Service)：两个及两个以上DMS Portal接口采用双机双工方式（互备互援）。
(3) 设置调度接口组(Web Service)：两个及两个以上调度接口 采用双机双工方式（互备互援）。
(4) 设置文件，数据文件数据库：数据在DMS Portal数据库和DMS数据库之间传递时，一个作为中间数据存储的数据存储区域。可以使用文件方式存储数据，此次方案中也考虑添加数据库作为中间数据存储的数据存储区域。
2.1.2 DCS服务器端调度高可用可行性方案模型图（局部）
在局部模型图中，我们更关注的是DMS Portal接口组(Web Service)以及DMS Portal接口组(Web Service)如何能够实现双机双工方式（互备互援）。既要保证每个DMS Portal接口和调度接口都被充分利用，同时保证他们能够有效分工，不会因重复工作而导致效率降低或者出现数据重复的错误。也就是2.2需要考虑的问题。
2.2 需要考虑的四个问题
(1) 如何避免调度程序读取DMS Portal数据库数据时出现重复读。
(2) 如何避免调度程序读取文件数据时出现重复读
(3) 如何确保文件若采用FTP方式进行读写时产生效率问题。
(4) 是否能够使用数据库替代文件进行数据存储。
(5) 如何确保每个调度程序都被充分使用。
2.3 可行性判断
对于2.2 需要考虑的问题，做出以下回答：
1 如何避免调度程序读取DMS Portal数据库数据时出现重复读。
对于该问题，可以在数据库层次进行解决：在原有的同步总表中加入两个字段：LockStatus, LockTime以及LockInterval。在DMS Portal接口添进行控制如下：
(1) 加一个共有方法 public bool CheckLock，若发现锁查询同步总表中LockStatus是1（已锁定）且当前时小于LockTime。CheckLock返回false，则接口代码dateset返回值为null。接口信息返回调用成功。若否执行（2）。
(2) 对同步总表查询到的该行加入排它锁，把LockStatus修改为0（未锁定），LockTime修改为当前时间+LockInterval (LockInterval为整型，建议为5分钟，具体可以根据自身需求进行修改)
(3) 执行业务代码，获取到对应数据成功后，更新序号，并把LockStatus修改为0（未锁定）。
附:
--执行1：
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
--insert into dbo.Product select * from Product
begin tran
select * from Product with (rowlock,UpdLock,HOLDLOCK) where id=3
update Product with (rowlock,UpdLock,HOLDLOCK) set name='30' where id=3
waitfor delay '00:00:30' --等待秒
select * from Product where id=3
commit tran
--执行2：
select * from Product where id=3
--先执行，再执行2，2会等待1 执行完之后才能查询到结果。
2 如何避免调度程序读取文件数据时出现重复读。
对于该问题。在原有的文件夹下添加一个文件夹ExcutingFiles进行文件隔离。既在读取Unsent文件列表后，先把需要读取的文件转移到ExcutingFiles，然后读取成功的文件放入SaveFile，执行失败的放入ErrorFiles。
执行中存档目录结构：
3 如何确保文件若采用FTP方式进行读写时产生效率问题。
对于该问题。在原有的文件夹下添加一个文件夹ExcutingFiles进行文件隔离。既在读取Unsent文件列表后，先把需要读取的文件转移到ExcutingFiles，然后读取成功的文件放入SaveFile，执行失败的放入ErrorFiles。
执行中存档目录结构：
（1）下发700个文件到文件系统耗时：
采用磁盘模式:耗时39秒
采用FTP模式:耗时40秒。
（2）读取700个文件并把信息上传到数据库：
采用磁盘方式耗时690秒。
采用FTP方式耗时700秒。
（3）使用FlashFXP程序进行FTP上传下载测试：
上传速度达到：11.02MB/S
下载速度达到：10.38MB/S
本地磁盘读写可以达到40.5MB/S
可见，在局域网类，最大上传速度：11.02MB/S，下载速度达到：10.38MB/S，而本地磁盘可以达到40.5MB/S，是虽然最大的读写效率相差会比较大，但是在未达到FTP上传下载的最大上限之前。对系统的整体运行并不大。而我们存储的数据文件大小一般只是几KB到几十KB的大小，也就是说相当于每秒几百上千个文件。当然，无论使用的是独立FTP服务器还是本地磁盘作为文件服务器，当文件服务器出现故障时，将会出现数据丢失。
4 是否能够使用数据库替代文件进行数据存储。
若使用数据库替代文件进行存储，也就是把数据文件以stream的形式存入数据库的一个字段中。需要回答以下三个问题：
(1) 需要怎样的数据库库表结构存储数据文件。
(2) 如何保证数据从DMS数据库—>数据文件数据库—>DMS Portal数据库 不被重复读取。
(3) 在DMS Portal数据库下发给DMS组，采用怎样的下发方式，保证效率最高，且不会相互影响。
(4) 对于已经标记为存档的数据，如何存入备份表中，如何定时删减备份表数据。
(5) 使用数据库库表结构存储数据文件，效率是否会更高，最大的能承受的输入输出能力。
问题(1)需要怎样的数据库表结构存储数据文件：创建库表结构如下
创建五张表：InterfaceLock，FilesUrl，FilesUrlBak ，FileContext，FileContextBak
InterfaceLock：对于需要顺序执行的接口，会在此表中生成数据，用于判断该接口指定的源系统编号，是否锁定（已有程序在执行）
|
字段 |
类型 |
允许为空 |
说明 |
值说明 |
|
Id |
bigint |
否 |
自增长，pk |
|
|
BusinessCode |
nvarchar(100) |
否 |
业务编号 |
|
|
InterfaceCode |
nvarchar(100) |
否 |
接口编号 |
|
|
FromSystem |
nvarchar(100) |
否 |
源系统编号 |
|
|
LockStatus |
int |
否 |
锁定状态 |
0 未锁定,1 已锁定 |
|
LockTime |
datetime |
否 |
锁定结束时间 |
|
|
LockInterval |
int |
否 |
锁定有效间隔 |
|
FilesUrl：存储文件业务信息及状态。
|
字段 |
类型 |
允许为空 |
说明 |
值说明 |
|
Id |
bigint |
否 |
自增长，pk |
|
|
UrlGuid |
varchar(36) |
否 |
UrlGuid |
索引 |
|
BusinessCode |
nvarchar(100) |
否 |
业务编号 |
索引 |
|
InterfaceCode |
nvarchar(100) |
否 |
接口编号 |
索引 |
|
FromSystem |
nvarchar(100) |
否 |
来源系统编号 |
索引 |
|
ToSystem |
nvarchar(100) |
否 |
目标系统编号 |
索引 |
|
FileName |
nvarchar(200) |
否 |
文件名称 |
索引 |
|
Status |
int |
否 |
文件状态 |
1 unsent 未发送；2 Lock 锁定；3 save 存档；4 Error错误； |
|
CreateTime |
datetime |
否 |
创建时间 |
|
|
SaveTime |
datetime |
否 |
存档时间 |
|
|
ErrorTime |
datetime |
否 |
错误时间 |
|
|
LockTime |
datetime |
是 |
锁定时间 |
|
FilesUrlBak：FilesUrl的备份表，将FilesUrl状态为save的文件，定期转移到FilesUrlBak进行备份。
|
字段 |
类型 |
允许为空 |
说明 |
值说明 |
|
Id |
bigint |
否 |
自增长，pk |
|
|
UrlGuid |
varchar(36) |
否 |
UrlGuid |
索引 |
|
BusinessCode |
nvarchar(100) |
否 |
业务编号 |
索引 |
|
InterfaceCode |
nvarchar(100) |
否 |
接口编号 |
索引 |
|
FromSystem |
nvarchar(100) |
否 |
来源系统编号 |
索引 |
|
ToSystem |
nvarchar(100) |
否 |
目标系统编号 |
索引 |
|
FileName |
nvarchar(200) |
否 |
文件名称 |
索引 |
|
Status |
int |
否 |
文件状态 |
1 unsent 未发送；2 Lock 锁定；3 save 存档；4 Error错误； |
|
CreateTime |
datetime |
否 |
创建时间 |
|
|
SaveTime |
datetime |
否 |
存档时间 |
|
|
ErrorTime |
datetime |
否 |
错误时间 |
|
|
LockTime |
datetime |
是 |
锁定时间 |
|
FileContext：存储文件内容
|
字段 |
类型 |
允许为空 |
说明 |
值说明 |
|
Id |
bigint |
否 |
自增长，pk |
|
|
UrlGuid |
varchar(36) |
否 |
UrlGuid |
索引 |
|
DataContext |
varbinary(MAX) |
否 |
数据内容 |
|
|
FileName |
nvarchar(200) |
否 |
文件名称 |
|
FileContextBak：存储文件内容的备份文件
|
字段 |
类型 |
允许为空 |
说明 |
值说明 |
|
Id |
bigint |
否 |
自增长，pk |
|
|
UrlGuid |
varchar(36) |
否 |
UrlGuid |
索引 |
|
DataContext |
varbinary(MAX) |
否 |
数据内容 |
|
|
FileName |
nvarchar(200) |
否 |
文件名称 |
|
问题(2)如何保证数据从DMS数据库—>数据文件数据库—>DMS Portal数据库 不被重复读取：
对于不需要按照顺序执行的接口：先加入排它锁查询到FilesUrl表中对应的BusinessCode，InterfaceCode且（Status为1 或 (Status=2 && LockTime< 当前时间)）的指定的多条数据，更改Status=2 and LockTime=当前时间+锁定时间间隔（该参数是接口配置参数，推荐设置为5分钟）。
通过查询到结果，根据UrlGuid获取到表FileContext中对应的DataContext，完成业务逻辑后，在根据UrlGuid，把FilesUrl中对应行的Status修改为3 存档。
对于需要按照顺序执行的接口： InterfaceLock中的BusinessCode，InterfaceCode，FromSystem会由FilesUrl的Insert触发器初始化生成。生成策略，只有ToSystem目标为DCS，且BusinessCode，InterfaceCode，FromSystem组成的唯一标记不存在于InterfaceLock会生插入初始化的数据。
同样的，先加入排它锁，查询InterfaceLock表中条件符合BusinessCode，InterfaceCode，且（LockStatus=0 || (LockStatus=1
&& LockTime< 当前时间)的数据和表FilesUrl 进行关联，关联条件BusinessCode，InterfaceCode，FromSystem相等，且（Status为1 或 (Status=2 && LockTime< 当前时间)）的指定的多条数据，Order By FromSystem,选择前N条作为本次执行的数据，通过Group By BusinessCode，InterfaceCode，FromSystem对InterfaceLock表修改LockStatus=1 and LockTime=当前时间+锁定时间间隔。
通过查询到结果，根据UrlGuid获取到表FileContext中对应的DataContext，完成业务逻辑后，在根据UrlGuid，把FilesUrl中对应行的Status修改为3 存档。当所有业务完成后，把InterfaceLock表之前修改过的BusinessCode，InterfaceCode，FromSystem组的状态修改LockStatus=0。
问题(3) 在DMS Portal数据库下发给DMS组，采用怎样的下发方式，保证效率最高，且不会相互影响。
在DMS Portal数据库下发时，在FilesUrl表中插入对应得的N条记录，只在FileContext插入一条数据即可。
问题(4) 对于已经标记为存档的数据，如何存入备份表中，如何定时删减备份表数据。
对于FilesUrl已标记为3（save存档）的数据，每天定时结转到FilesUrlBak，删除原表记录。同样的每天FileContext，当FileContext的UrlGuid在FilesUrl无法找到时，则将FileContext转移到FileContextBak，删除原表记录。
对于FilesUrlBak，则每天对于当前时间-SaveTime>35的数据直接删除，删除时，利用触发器删除FileContextBak对应的数据。
问题(5) 使用数据库库表结构存储数据文件，效率是否会更高，最大的能承受的输入输出能力。
对于该问题，使用Sql Server2008R2在局域网进行测试，可以每分钟读写12000条30K大小的数据文件。具体读写效率会根据局域网带宽，数据库磁盘和数据库所在服务器CPU等硬件情况，上下波动。
5 如何确保每个调度程序都在被使用。
对于该问题。可以设置调度程序的最大线程数，避免了一台机器独揽工作。同样的，对于已经标记为正在执行的接口接口及文件，调度程序可以直接跳过执行，去执行从而避免重复工作。达到有效每台机器的有效分工。