面向微服务架构的软件系统韧性增强技术研究*

时间：2024-07-28

余航，许博

(陆军工程大学指挥控制工程学院，江苏南京 210007)

0 引言

对于软件系统，尤其是具有关键任务使命的系统而言，确保任务执行不中断、具备持续运行能力、保证使命任务的完成至关重要。事实上，许多风险都会对系统服务产生严重影响，例如自然灾害、硬件故障、性能过载、错误配置、软件漏洞、恶意程序、敌对攻击等[1]，故障风险的增加会严重降低已部署服务的质量，甚至导致服务完全中断。

在安全领域，尽管许多科研人员仍然致力于构建更加健全的外部安防体系，试图将威胁拒止于受保护的系统之外，但一旦研究人员精心构建的防被线被突破之后，所有的努力都将功亏一篑。鉴于当前网络环境的复杂性、威胁形式的多样性以及威胁的不可预测性，利用传统的外部防御手段来实现无懈可击的保护是不现实的。并且复杂的安防系统会因为过于臃肿而导致资源的严重消耗以及系统网络性能的下降[2]，因此需要改变思维方式，考虑当外部防御失败后的状况。也就是说，系统必须考虑在面对已经到来的破坏情况下，如何确保服务得以持续，保证任务使命得以完成。

1 相关背景

1.1 系统韧性

系统抵抗风险可能带来的破坏性并在灾害、故障、攻击到来时维持服务持续运行、确保使命必达的能力通常被称为系统韧性。自美国国防部于2014年提出并推行“网络韧性”以来，“韧性”一词便在计算机领域受到广泛关注。

韧性多用于表示实体或系统在发生扰动后快速恢复到常态的能力[3]。堪萨斯大学 ResiliNets 项目对于韧性的定义是“当正常操作面临故障和挑战时能够提供并维持可接受的服务水平的能力”[4]。而在软件系统中，韧性能力是指确保软件系统在遭受各种事故时，仍然能够保持关键服务的可用性与可持续性，确保任务能够完成[5]。

1.2 微服务架构

到目前为止，最常见的用于部署应用程序的体系结构是单体架构。在单体架构中，每个部署单元都是处理所有功能的自治实体。但单体架构存在扩展性差、可靠性低、可重用性低、维护成本高等问题，近年来提出的微服务架构[6]给出了一种新的解决思路。

微服务架构最早由 Fred George 在2012 年 3 月的Agile India 上提出，Martin 和 James 在 Microservices[7]文中对其进行了通俗易懂的阐述。该架构将复杂的应用程序解耦为轻量级和松散耦合的组件，较为成功地克服了单体架构的局限性。每个组件都使用单独的源代码存储库独立执行微服务，并且可以在不涉及其他组件的情况下进行更新。此外，考虑到不同应用程序组件的不同资源需求，微服务体系结构支持独立扩展每个组件。简而言之，微服务架构提供了改善应用程序开发的可伸缩性和弹性的可能性。当前，在微服务架构被广泛应用于应用程序部署之前，其仍处于起步阶段，面临许多挑战。基于容器的虚拟化技术由于其轻量级和即时性，被认为是在实践中加速微服务架构应用的良好选择。单体架构与微服务架构图如图1 所示。

图1 单体架构与微服务架构

在微服务架构中，应用程序被解耦成了服务的集合，每个微服务都有单一的功能，都是独立开发、部署和管理的[8]。在微服务架构下，软件产品的更新和新特性可以以每天数百次的频率不断发布，使应用程序非常动态。微服务这种松散耦合的特性给软件系统韧性增强带来了高度的敏捷性。

微服务架构下服务通常部署在容器中[9]，尤其是近年来 Docker 容器技术[10]的兴起，利用 Docker 技术构建微服务架构的软件系统已经成为了行业内的实际标准。为了简化容器的管理与编排，提高实际应用中的生产效率，在一段时间内出现了容器云管理平台百家争鸣的局面。目前三大主流的容器平台分别是 Swarm、Mesos 和 Kubernetes，其中 Google 公司的Kubernetes 目前已经成为了行业内的实际标准。

2 微服务架构下的韧性增强技术

由于微服务松散耦合、分散治理的理念，使得微服务架构的软件系统能够具备服务微小化、模块化设计、高度自治、可独立替换、组件可独立升级等优良特性[7]，这些特性使得在微服务架构的基础上应用大量韧性增强技术成为了可能，例如冗余、多样性、资源扩展、迁移等，本节主要介绍在微服务框架下的韧性增强技术。

2.1 冗余与多样性

基于微服务架构构建的软件系统，得益于松散耦合的优势，可以将软件系统拆分成相互独立的若干个部分，各个部分之间独立工作，结合容器技术，各个独立的部分都可以打包成不同的实例，作为构建完整软件系统的组件。这就给软件系统的韧性增强提供了巨大的潜力，在此基础之上应用多样性和冗余技术，以此来提高系统的可用性。

2.1.1 冗余

虚拟化环境和微服务架构提供的灵活性将取代传统单体架构下软件系统的刚性。在传统单体架构下，通常通过部署多个完整的软件应用来构建一个有冗余的健壮的软件系统，从而导致高昂的成本。而在基于虚拟化实现的微服务架构软件系统中，只需通过添加一组辅助或冗余组件来确保对关键组件发生故障时的恢复能力，如图2 所示。

图2 系统冗余示意图

2.1.2 多样性

2016 年欧洲电信标准协会[11]提倡开发者设计和实现多样性以作为容错的一种手段，并讨论了旨在实现自动控制软件多样性的技术方法。

多样性的基本思想在于用若干个拥有相同功能的不同实现组成的实例池替换单个实例。如图3所示，这些实例以并行方式集体地执行与原始实例相同的功能，并且同时处理与原始实例相同的业务，在这种情况下，其中部分实例的故障将不会对业务造成致命的影响。

图3 系统多样性示意图

2.1.3 冗余、多样性的相关研究

冗余和多样性的混合策略策略在服务功能链(SFC)的部署上已经得到了广泛应用，Hmaity 等人[12]在服务功能链的冗余保护机制中提出了三种冗余保护方案，分别是：(1)端到端冗余保护；(2)虚拟节点冗余保护；(3)虚拟链路冗余保护。

除此之外，使用冗余和多样性方法后还带来了实例的“放置”问题。 Herker 等人[13]开发了一种服务链嵌入算法，该算法考虑了服务可用性约束，并比较了使用不同数据中心架构的几种备份策略，提供了有关如何选择可提供高可用性的“最佳”数据中心拓扑的见解。依赖VNF 备份通常会导致路由路径更长，从而增加了端到端延迟。为了克服这个问题，Vizarreta 等人[14]提出了两种 VNF 放置策略，可以在不影响可用性和端到端延迟的前提下，降低运营商的服务部署成本。但是，基于可用性的放置会导致资源浪费，因为将永远不会使用不满足所需可用性阈值的资源。就资源利用而言，这与成本效益的最初目标相矛盾。类似地，Qu 等人[15]提出了一种解决方案，该方案使用混合流量路由策略提供了最佳的网络服务放置，同时在带宽消耗和端到端延迟性能之间取得了平衡。

Alleg 等人提出了一种联合选择多样性和定制的冗余机制[1]，以在 NFV 框架中提供韧性服务。为求解模型，作者提出了基于混合整数线性规划(MILP)的服务功能链部署解决方案，旨在满足目标SFC 可用性级别，同时降低由于多样性和冗余而导致的固有成本，这对于增强微服务架构的软件系统韧性同样具有借鉴意义。

由于大量使用冗余来保证可用性，这导致了微服务架构的软件系统中大部分微服务组件都是同质的，大量共享漏洞被引入系统[16-17]，因此容易受到利用多微服务中相同漏洞实施的多步攻击[18]的威胁。针对共享漏洞问题，Kennedy 等人提出了运用动态目标防御(MTD)的思想来解决问题[19]。为了防止攻击者利用已知目标系统的漏洞，Kennedy 等人先对微服务执行风险分析来检测漏洞并确定其优先级，再利用自动代码生成技术来转换微服务的编程语言和容器镜像，由此改变攻击面，降低被攻击成功的风险。

2.2 服务编排

关于编排问题的优化解决方案，由于时间复杂度高，研究人员已经证实，在大规模云环境中，诸如混合整数非线性规划(MINLP)或线性规划(MIP)等方法是不可行的[20]，遗传算法已被广泛用于优化资源调度，服务编排和任务分配[21]。

早期关于服务编排机制的工作主要基于QoS感知开展。 QoS 属性通常包括响应时间、可用性、可靠性和价格成本等，文献[22]专注于基于 QoS 感知的服务组合及其在中间件中的实现，然而没有定量描述带有风险的安全目标，并在实际的云环境中解决它们。

大规模分布式云环境的高度复杂性导致了大量的不确定性，而这些不确定性无法通过常规信息安全方法的可用性来建模。Wen Zhenyu 等人[23]创新地从安全性角度出发，针对内部安全威胁和外部环境不确定性进行建模，并提出了一种用于在基于云的服务组件不确定的情况下，定量测量安全级别及其可用性方面的通用方法。

传统的编排机制侧重于单个服务链的QoS 优化，而忽略了实例间的共享和竞争。为了解决这个问题，Ding 等人[24]提出了一种基于列表调度的微服务选择算法MSS。该算法采用工作流模型对服务链进行描述，分析实例的处理速度、网络传输速度和任务并发程度，计算每个任务的分期限，根据分期限和其他信息，实时计算和更新每个任务的调度紧迫性。最后，提出了基于分期限和紧迫性的两种服务选择策略，以完成微服务实例选择，构成服务链。

2.3 负载均衡

负载均衡是指在单台设备处理性能不足以支撑起系统业务需求的情况下，利用现有的设备、网络等资源，将多台设备通过一个共用的服务入口连接起来组成一个服务集群，在工作时将业务按照一定的规则分配到不同的服务节点，整个集群共同承担系统业务，从而解决了单个服务节点性能不足的问题。

负载均衡的方式巧妙地避免了因单台设备性能不足而不得不购买昂贵的高性能设备，降低了企业的部署成本。除此之外，负载均衡的另一大优势是增强了系统韧性，设备故障是不可避免的，随着使用年限的增长，设备的故障概率也随之上升，同时还有遭受非正常因素破坏带来的风险。由单个高性能设备构建的系统在面对意外与挑战时，一旦设备出现故障或遭到破坏，系统运行也将随之停止，这对于关键系统而言是不可接受的。而对使用了负载均衡技术的系统而言，单个设备或系统单个模块的问题将无法对系统造成致命打击，大大降低了系统停止服务的风险，因而进一步增强了系统韧性。

2.4 资源扩展

如图4 所示，关于资源的动态扩展，主要可以分为两类：一种是添加更多的虚拟机或容器，这被称为水平缩放，另一种方法是向已部署的虚拟节点分配更多资源，这称为垂直扩展。

图4 资源的水平扩展与垂直扩展

在实践中，已经有学者做了一些工作来利用容器部署微服务架构的应用程序。Zhou 等人[25]研究了旨在最大化部署微服务收入的微服务调度问题。Guerrero 等人[26]设计了遗传方法来确定分配给每个微服务的资源数量，以及如何在工作负载变化时有效地扩展规模。但是，大多数现有工作并未考虑容器的功能，例如以细粒度进行动态资源缩放，图像分层和库重用，这将影响资源使用效率和应用程序部署成本。 Wan 等人[2]基于以上工作存在的问题，结合Docker 容器的功能，提出一个可伸缩的框架ADMD 和一种以分布式和增量方式工作下的次优算法来确定容器放置和任务分配，以根据系统需求和状态动态调整分配给每个应用程序的资源量，并最大程度降低总成本，同时化解了全局最优带来的NP 难题，不足之处是没能避免共享漏洞问题，同样存在安全隐患。微服务架构下的资源扩展图如图5所示。

图5 微服务架构下的资源扩展

2.5 迁移技术

为了进一步保证软件系统在遭受攻击、出现故障或意外事故后仍然能够按时完成所执行的关键任务，需要在前述基于Docker 容器技术的微服务架构基础之上，进一步建立一种情境认知的服务动态部署迁移机制。其基本思想在于利用容器化微服务所实现的应用服务不再依赖于固定的物理网络和物理设备这一特点，使得网络业务可以在不同物理设备和网络之间按需进行迁移，保证了服务的可迁移性。由于服务运行于虚拟化主机和网络之上，避免了与具体的物理设备和物理网络相关联。

在动态迁移技术方面，目前已经较为成熟的迁移技术包括 Pre-copy、Post-copy、CRIU 等。除此之外，还有一些利用日志记录和重放手段实现的Docker容器热迁移[27]，但这种方法由于在容器运行时间较长的情况下宕机时间过长，并未得到业界的广泛认同。 Carpio 等人[28]基于复制和迁移技术提出了一种用于主动配置的线性模型，以提高服务的可靠性。实验结果表明，复制与迁移相结合可以提高资源利用率，而不会降低可靠性。但是，由于没有足够的备用资源，他们的恢复解决方案不能为每个VNF 支持多个副本故障。 Nadgowda 等人[29]也提出了一种容器迁移服务Voyager，该技术与文件系统、供应商无关，可为开发人员提供一致的全系统迁移。

目前关于虚拟机和容器的热迁移技术已经比较成熟，然而大量关于迁移技术的研究都只聚焦于单个虚拟机或容器，与之相对应的是，张强针对在Kubernetes 大规模应用的背景下 Pod 迁移问题提出了一种解决方案PodMS[30]，一种面向数据中心Kubernetes 环境的容器在线迁移机制，该机制支持Kubernetes 环境下的容器在线迁移，提供了 Pod 在线迁移的完整支持。美中不足的是，该机制对网络迁移的支持还存在不足，并且未对前文所提到的CRIU问题进行完善和改进。

3 存在的问题

3.1 复杂性问题

软件系统的微服务化不可避免地要对传统单体架构的软件系统进行拆分，并就微服务架构的指导思想和目前的企业实践而言，应用的服务功能拆分得越细越好，在享受组件模块化优势的同时，也不可避免地导致了系统的进一步复杂化，引入了大量复杂性问题。

3.1.1 故障检测复杂性

尽管微服务架构下系统具备一定的容错能力，但在发生故障之后必须及时发现并采取相应的手段进行恢复。在一个大型微服务架构的软件系统中，系统由大量的微服务构成，由于服务随时可能发生故障，因此能否快速实现故障检测显得至关重要。但由于系统微服务化，软件的大量组件与设备都成为了需要监视的对象，这将使得监视系统的构建与监视数据的存储、调用、组织成为了一件复杂的事情。

对于这一问题，应当基于微服务基础架构平台建立完善的监视系统，不仅包括对硬件设备的监视，同时更应着重于对应用程序各组件、正在运行的各项业务的监控，完善的监视系统可以为发生错误的情况提供预警系统，从而触发自动恢复机制，同时也有利于开发团队进行跟进和调查。

3.1.2 模块通信复杂性

当软件系统的组件具有远程通信的服务功能时，无论在系统重构上还是调用组织上都将比单体架构困难得多。简单来说，微服务化软件系统中各个组件的停机都将直接影响整个服务链上的业务运行，进而影响整个系统的业务执行，这也是开发者不得不考虑的问题。

针对这一问题，开发者应当基于统一的开发与编排平台，利用通用接口进行开发，以避免在调用时因接口不统一引发的业务逻辑问题。

3.1.3 迁移复杂性

传统的迁移只需要考虑对单个虚拟机(或容器)进行迁移，在运行中的业务系统面言，则需要考虑尽可能减小迁移所带来的影响，如造成停机则需要尽可能地缩短停机时间。而在微服务架构系统中则需要考虑一次性迁移数个容器，并且还需要配合底层平台进行相应的修改，即迁移对象将不再是简单的单个容器，而是封装在一个组件中的若干容器。当前容器迁移已经是相对比较成熟的技术，并且已有例如CRIU 等相对成熟的技术，该问题最直接的解决方式，是在已有的技术和容器编排与管理平台的条件下，进行适应性开发，形成一套新的成熟的迁移机制。

3.2 兼容性问题

3.2.1 底层操作系统不兼容

构建微服务架构的软件系统最简单的方式是基于成熟容器的编排与管理平台，如Swarm、Mesos和Kubernetes 等，但这些平台在部署时都必须要求底层设备使用相同的操作系统，这对于实现系统多样性指标将成为一种阻碍，从而无法充分利用多样性实现更加高层次的系统韧性。

3.2.2 容器不兼容

除了操作系统之外，容器多样性的实现也存在相同的问题，基于不同容器的成熟管理平台还未出现，基于容器的编排与管理平台进行实现就必须使用同一种容器技术，在这种情况下系统多样性将无法得到进一步拓展。

兼容性问题的解决不是靠个别研究人员的努力就能实现的，这需要开发者、运营商、标准制定组织共同的努力。对于研究人员而言，应当尽可能地基于统一的标准进行开发，从而获得彼此之间相互兼容的技术产品。

3.3 资源优化问题

运用冗余和多样性的目的在于应对系统部分组件可能出现的故障与风险，但同时也将不得不导致资源的浪费问题。组件的故障只是个概率问题，因此在各组件正常运行的大量时间内，出于冗余和多样性目标所消耗的大量资源都造成严重的浪费。过多的资源用于冗余和多样性可能导致部分资源将一直处于闲置状态，而用于冗余和多样性的资源不足则有可能导致无法起到保护作用或系统韧性无法满足要求。

资源优化问题的解决，一方面需要兼顾资源优化和韧性增强两个方面，使得恰好能够满足系统韧性指标，同时最小化资源消耗。另一方面，进一步增强软件的可靠性与稳定性，使得软件系统需要的冗余度进一步降低，而达到资源友好的目标。除此之外，更好地将冗余和多样性结合起来也是解决问题的关键。

3.4 安全性问题

3.4.1 容器安全问题

尽管容器的轻量级特性使得其在物理机上可以更大规模地部署，从而提供更高的性能，但是和基于 Hypervisor 的虚拟化相比，研究人员普遍认为后者比容器技术更为安全[31]。原因在于基于Hypervisor的虚拟化下每一个VM 都带有自身的内核，运行在VM 上的 APP 只需与 VM 内核通信即可，隔离了主机内核，如图 6 所示。而 Docker 之上的 APP 则可以直接与主机内核进行通信，相比前者更容易遭到攻击。在以“特权”身份运行容器时，Docker 会授予用户对该容器的最高权限，这与在主机上本地运行的进程的访问权限几乎相同。

图6 Docker 容器和虚拟机对比图

容器逃逸问题也是研究人员最关心的问题之一，内核漏洞是对操作系统安全性的巨大挑战，尽管Docker 拥有许多用于自身安全性的设计和策略，但是其共享内核的体系结构模型使一些外部安全性问题扩展到了容器中[32]。 Docker 面临着被恶意用户利用内核漏洞进行攻击的风险，一旦容器中的漏洞利用程序启动有效的逃逸攻击，就可以获得主机的根特权，将影响其他容器和整个系统的可靠性。

3.4.2 服务安全问题

由于微服务框架下软件系统由大量微服务组成，微服务之间可以根据标识对其他微服务进行调用，因此不得不考虑其中某一项微服务可能会被非法调用，即便不发生这样的情况，在系统部分微服务进行独立升级时，其中部分组件的更改也可能会破坏其他微服务。开发者需要通过合理的设计以尽可能地容忍软件系统中的变更，避免使用过多的版本控制。

4 发展趋势

当前，微服务正处于发展阶段，专门将微服务用于软件系统韧性增强领域的研究更是处于探索阶段，因此未来的发展很大程度上将考虑进一步挖掘微服务架构可用于增强系统韧性方面的特性，本节将就下一步可能的发展方向进行展望。

一是在考虑冗余和多样性的同时尽可能地减少资源消耗。当前的主要趋势是优化改进调度策略以实现更优的资源动态扩展，从而缩小冗余和多样性的规模，减轻系统在资源消耗上的负担，从而在增强韧性的同时，尽可能地缩减开支。

二是增强兼容性，包括下层操作系统的兼容和对多种容器技术的兼容。这对容器编排与管理平台提出了更高的要求，这一问题的解决将使得微服务架构下软件系统的灵活性进一步得到释放，既有利于多样性的发挥，又能使得部署更为轻松。

三是尽可能解决现存在的安全问题，包括容器的安全问题和微服务框架下服务的安全问题。其中Docker 容器的问题又需要从守护进程(Docker Deamon)、容器镜像、容器网络等多角度入手解决。如可以通过将容器放置在虚拟机内部来实现等方法。针对可能的攻击，可以在保持容器轻量级优点的同时减小攻击面，如引入攻击面转换技术。

四是更加完善的动态迁移技术。在研究迁移策略时，还需要考虑以下几个原则：(1)需要带状态迁移，即热迁移，以保证迁移完成后服务得以延续；(2)迁移带来的停机时间需尽可能短，让用户感觉不到有什么明显的变化；(3)迁移目的需是负载较轻的节点，以免带来新的过载问题。基于以上原则，研究的方向在容器迁移、虚拟机迁移的基础上，进一步对微服务架构下的服务迁移问题进行研究。