科技服务系统高可用探索与实践——以京津冀制造业智库服务系统为例

冯婷婷，毕延洁，胡宇明，杨宏亮，刘卫兵

1. 清华大学天津高端装备研究院，天津 300300

2. 泰山智能制造产业研究院，山东 泰安 271000

引 言

随着京津冀协同发展的不断深化，科技服务业对地区产业升级的作用日益突出。京津冀装备制造业科技服务资源分布不均衡，部分地区传统产业转型升级需求迫切，创新创业对科技服务的需求较为突出，亟需促进科技服务资源的共建共享。通过建立一个京津冀装备制造业智库系统和资源库，完善服务系统，培育科技服务业，推动科技服务资源与实际需求的精准对接，对提升京津冀科技服务协同支撑能力具有重要意义。

京津冀装备制造业智库服务系统，依托三地装备制造业大数据资源汇聚建设，由数据资源池管理系统、智库门户系统和会员精准服务系统等三个子系统组成。平台以科技成果转化为实际效益为目标，汇聚优势智库资源，面向装备制造业提供规划咨询、技术转移、检验认证、成果转化等智力服务。如何在信息安全的前提下，通过合理的架构设计和管理方式的优化，来确保系统低故障率运行，从而提升服务质量，是平台长期运营所不可回避的问题[1]。

高可用性(High Availability, HA)作为衡量应用系统质量的重要指标之一，通常被定义为应用系统保持正常运行的时间占比。衡量应用系统是否具备高可用性，主要的指标包括平均无故障时间(MTTF)和可维护性平均维修时间(MTTR)，可采用如下公式计算：High Availability = MTTF/(MTTF+MTTR) * 100%[2]。通过对网络环境、硬件设施、应用系统架构等的优化设计，降低系统的故障率和停机率是提升可用性的主要手段。

1 可用性影响因素分析

京津冀制造业智库服务系统采用基于JavaEE 的微服务架构实现，面向公众、科研院所、中小企业提供一站式精准的互联网科技服务。为保证用户粘度和服务质量，要求系统7×24 小时不间断，而且需要具备较高的并发处理能力和易维护性，所以在研究提升系统可用性之前，首先要将运行风险进行总结归纳，做到有的放矢。

据统计，造成软件系统服务中止的主要原因占比，一般为硬件40%、软件30%、人为20%、环境10%。而影响应用系统服务持续性的因素有很多，有技术因素也有管理因素，归纳如下：

1.1 基础设施因素

基础设施包括网络链路、服务器、服务器托管、防火墙等硬件设备或服务。故障所造成应用系统中断问题主要集中在：计划外断电、网络攻击、服务器硬盘损坏、DNS 服务中断、存储空间不足等。基础设施故障相对容易排查。

1.2 公共服务及应用支撑系统因素

除了要保障基础的应用软件环境外，还要保障服务支撑平台应用的正常，此类故障对系统可用性影响较大，归纳如表1 所示。

表1 公共服务及应用支撑系统常见故障一览表Table 1 List of common failures of public service and application support systems

日常维护中，应用软件环境和应用支撑出问题的几率比较高，大多通过定期巡检和利用监控软件进行预防。

1.3 应用程序因素

在程序架构设计无重大缺陷的情况下，应用程序自身在从试运行转为运维期后，大多已经历了多轮测试和BUG 修补，故障风险相对较低。而子系统按照业务特点不同，高可用性设计的侧重也不同。例如，智库门户系统面向公众开放，有较高的数据安全性、访问终端兼容性和服务持续性要求；对于会员精准服务系统等需要与外部系统进行频繁数据交换的系统，则在保证应用系统本身可用的基础上，还要关注数据接口应用的稳定性。此外，系统功能迭代、流程优化等因素，也会在一定周期内，不同程度地影响服务的持续性。

1.4 网络与信息安全因素

安全风险贯穿基础设施、应用支撑系统、应用系统等诸多环节，安全隐患和突发的安全事件所导致的服务中断时有发生。为落实国家网络与信息安全的工作部署，平台建立了完善的管理制度、规范，定期对应用系统进行安全漏洞扫描，存在安全风险时需要进行安全加固。在严格管理下虽然安全性得到了一定提升，但由于增加了安全管理环节，也会使应急响应效率受到一定影响。

2 高可用性技术

提升高可用性的方法主要是通过提高平均无故障时间(MTTF)，同时降低可维护性平均维修时间(MTTR)来实现。一般从以下五个方面重点设计：（1）降低耦合度减少局部故障对全局影响，同时提升日常和突发故障修复效率；（2）充分考虑按应用场景运行情况随时可扩展；（3）将操作系统、数据库、网络连接、软件部署等系统运行风险降至最低； （4）提升服务器、参数配置变化、应用程序性能和突发预警的监控可用性；（5）做好定期巡检，降低周期性运行故障风险。

高可用的系统离不开高可用的软硬件架构设计，无论是集群系统还是分布式系统，目标都是资源冗余，避免供电、磁盘、网络、应用服务器、应用程序等要素的单点故障风险[3]。对相关技术因地制宜地组合应用，是提升智库服务系统可用性的关键[4]。

2.1 私有云

云计算，能够通过虚拟化、网络计算、分布式等技术，提供IaaS（基础设施即服务）、PaaS（平台即服务）、SaaS（软件即服务）等架构的云网络、服务器、存储等基础设施资源服务[5]。随着技术领域和商业环境的发展，除了一些大型互联网公司提供公有云服务外，企业事业单位自建的私有云平台的应用也日渐成熟。私有云平台一般由数据中心采用基于集群的集中化管理，由多台物理服务器和存储聚合组成，不仅降低了管理的复杂度，还为应用系统提供了更经济、有效、私密且可扩展的基础设施保障[6]。私有云平台可以按照业务需求，来配置带宽、内存、存储资源，而且主机克隆、主机漂移、动态调整等特性，能够有效提升服务的持续性并缩短停机恢复周期。

2.2 负载均衡

在集群和分布式系统中都是利用多点协同，来规避单点服务的风险。负载均衡利用轮寻、随机、源地址散列等算法，将请求任务分发给各个可用节点进行处理。负载均衡分为 DNS 负载均衡、IP 负载均衡、反向代理等模式，可以按照不同的应用场景通过软件或硬件实现。在实际应用中，硬件的负载均衡由于独立于应用系统部署，更适用于没有源码授权的集中式软件产品构建集群系统，性能和可靠性更好[7]。而软件负载均衡更适用于架构设计、源码可控的自主开发的软件系统，成本相对低且应用灵活。

2.3 集群与分布式应用架构

集群技术是通过网络将多台提供相同服务的服务器连接在一起，组成的大型服务计算系统，面向客户端提供统一的应用服务，从而解决高并发时的服务稳定性。集群技术本身就是一套高可用性的系统，具备提供服务故障监控和故障处理的能力，通过资源的冗余和利用率的监控，利用负载均衡的方式降低应用中止的概率[8]。分布式与集群系统不同，是指将系统中的不同业务单元拆分，并分布在多个节点上部署，面向客户端提供统一服务。为防止某个节点服务中止所导致的整体应用中断，分布式中的每个业务节点都可以做集群。

集群可用于多种应用服务，中间件方面 Apache, Ngix, Weblogic 都提供了集群配置方案，数据库方面 Oracle Rac, Mysql Cluster 也都提供了数据库的集群部署方案。集群是比较常用的高可用方案，尤其通过硬件负载均衡设备能够简单、快速地搭建集群应用系统。分布式系统由于复杂的技术特性，具备分布式思想的微服务架构更适合科技服务类软件系统的构建。

2.4 微服务架构

作为一种架构风格，微服务是以专注于单一责任的小型功能模块为基础，通过 API 集相互通信的方式完成复杂系统搭建的一种设计思想[9]。大型的软件系统可以由多个微服务组成，而且它是松耦合的，可被独立部署[10]。与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。通过微服务的分布式/版本化配置、服务发现、路由、断路器、服务网关、分布式消息传递等应用组建的提供， Spring Cloud 能够完整地提供整体解决方案[11]。

该架构已在电子商务平台、工业互联网等对并发性能和系统稳定性要求极高的应用领域得到了广泛应用[10]。团队协同开发便捷、服务的可复用性和高可用等特点，使之非常适合智库系统的构建。

3 高可用技术应用实践

具备高可用性的系统架构设计，是从技术角度降低运行风险的基础，而系统架构也是需要结合具体的应用场景和基础条件综合考虑。下面结合京津冀制造业智库服务系统的两个应用案例，简要介绍负载均衡集群和微服务架构的应用。

3.1 负载均衡集群在京津冀制造业智库服务系统中的应用

智库门户系统是平台面向用户的服务入口，也是系统平台各子系统的高度集成。门户系统依托智库平台数据资源池建设，以京津冀制造业企业为主体，面向公众提供智库资源的分类导航、知识数据资源、全文检索、会员登录等服务。智库资源池数据管理系统，是平台整体的运行和管理中心，由各级系统管理员负责管理，按照角色进行权限控制，主要用于维护平台数据资源。

在系统高可用性方面，需要考虑的主要问题： （1）系统由关系型数据库持久化存储，数据量较大对数据库并发处理性能要求较高；（2）智库资源池数据管理系统，如暴露在外网访问存在潜在的数据安全风险；（3）两系统均采用单体应用模式建设，系统耦合度高，容易出现局部故障导致的整体服务中止；（4）门户系统面向公众服务，用户数量激增的情况下，应保障系统的并发处理能力。综合上述需求，系统架构设计如图1 所示。

由于两个子系统均为单体应用，采用硬件负载均衡的方式搭建集群架构系统，无需对应用本身进行改造，同时能够满足应用的高可用性。负载均衡设备为系统划分了两个域，分别由两个二级域名 DNS 指向，形成“智库资源池数据管理系统集群”、“智库门户系统集群”两个应用集群组。应用服务各子系统业务功能相对独立，而又需要面向会员提供一体化的协同服务。

图1 负载均衡集群Fig.1 Load balancing cluster

由于硬件负载集群对基础设施资源数量需求比较高，所以在系统高可用方面，考虑更轻巧、扩展性的采用应用级架构。设计开发之初，应用程序被拆分为多个“服务聚合模式”的微服务组，分别是智能消息、智能问答与在线咨询、需求承接、资源调用服务等。每个“服务聚合”按照业务特点被拆分为若干个微服务应用。如图2 所示。

上述微服务，可按照业务应用负载情况进行灵活部署，可以部署在1 台或多台云主机应用服务器上。微服务拆分方面，在平台有高并发需求，可按需求扩展部署，另外附件上传、附件导出、照片显示等资源类操作的功能也被拆分为微服务独立部署，可供其他聚合服务调用，通过统一的服务提供来避免重复开发带来的多点故障风险。

微服务架构在会员精准服务系统的应用，能够器方面，采用6 台私有云主机配置到两个集群组中。“智库资源池数据管理集群”由2 台云主机组成，面向各类管理员提供服务。另一组由4 台虚拟机组成“智库门户系统集群”，面向公众提供服务。数据库方面，出于性能考虑由2 台主机搭建 Mysql Cluster 集群，缓解数据并发压力。在网络安全策略方面，智库资源池数据管理系统，限制在内网访问，外网可通过 VPN 使用系统。系统符合网络安全三级等保要求，利用漏洞扫描工具对操作系统级和应用程序进行了多轮漏洞扫描并完成了全部“低危”及以上漏洞的修补，保证了系统的安全性。

3.2 微服务架构在会员精准服务系统中的应用

图2 微服务拆分示例Fig.2 Microservices split display

会员精准服务系统集成于门户系统中，面向会员提供智能化的精准服务，由专家在线咨询、智能消息推送、智能问答、需求承接等多个子系统组成，使应用的高可用性资源成本有效降低，并且可以根据应用运行情况随意扩展硬件资源，是一套可伸缩的轻量级应用程序架构，非常适合在科技服务平台建设中推广和应用。

3.3 高可用性测试技术实践

高可用测试是在系统上线运营前，通过人工和自动化测试手段，模拟系统出现故障异常情况，验证局部异常阀值和制定异常恢复正常状态方案的重要手段。

对于科技服务类系统而言，为保障服务持续性，避免因此导致用户粘度损失，测试策略上主要围绕直接面向用户服务的功能测试和服务开展。功能测试方面，重点在智库服务系统和会员精准服务系统两个子系统制定测试用例，编写单元测试脚本，迭代分析功能缺陷，输入内容边界值等关键内容；恢复测试方面，主要面向整体平台验证在单位时间范围内修正错误和回复服务的可操作性，从而针对重新初始化，数据恢复，应用启动制定综合方案；压力测试方面，则是利用Apache JMeter+Badboy 自动测试工具进行，通过Badboy 录制门户系统、专家在线咨询等高并发场景应用的测试脚本，导出至JMeter完成应用级和数据库自动化压力测试；安全测试方面，对标网络安全三级保护的要求，从数据安全、应用安全、应用服务器安全三个方面进行自动化漏洞扫描，按照高危、中危、低危漏洞评级，指导迭代修补漏洞。

4 结语

通过负载均衡集群、微服务架构等高可用性技术的应用，京津冀制造业智库服务系统运行故障率低，服务质量得到提升。随着京津冀一体化的进程加快，制造业智库系统高可用性研究将结合平台业务发展和应用场景变化，长期跟踪系统构建技术，因地制宜地进行迭代设计。本文所提及的探索与应用，希望能够为同行们提供参考。

利益冲突声明

所有作者声明不存在利益冲突关系。