基于DevOps的云平台微服务架构可靠性研究

罗欢，陈仁泽，刘明伟，徐律冠

（南方电网数字电网研究院有限公司，广州 510000）

引言

在互联网与计算机逐渐扩展应用之后，人类就进入了信息化的时代，在信息社会里，计算机系统逐渐进入到生活与生产的每一个角落，大到探索宇宙的飞船，小到生活中的家用电器，都含有计算机系统与芯片，特别是随着近年来出现的云计算理念，已经成为了生活中的普遍资源。其中云平台微服务架构更是计算机里较为重要的软件架构，而在微信息环境下出现的微服务，其大致模式更是个性化与差异化的，同时也可作为一种新兴的媒体服务。微服务能够提供随身、随地、随时的服务，其服务的方式会因为人的流动而改变。但是云平台微服务架构也存在一些固有的弊端，因此需要对其进行可靠性研究。

文献[1]对微服务之间的复杂依赖关联进行建模，从而得到含有有向无环图描述的微服务调用关联模型，通过该模型对所有微服务请求的频率进行估算，同时根据排队论中的队列拟定微服务的处理流程，从而拟定出一种以微服务等级协议满足度为评估指标的服务收益函数，最后使用拥塞博弈模型拟定资源利用关系，通过对比资源利用关系与收益指标函数来完成对云平台微服务架构的可靠性研究。但是该方法只通过收益指标来度量架构的可靠性，无法有效地分析出云平台微服务架构整体的可靠性。

文献[2]依据在失效可恢复的状态中，能够清晰观察资源失效规律的动态转变原理，并融入失效恢复机制，利用两参数将其放置在不同的时段资源节点与传输链路中进行描述，再凭借并行任务之间含有的交互关系，拟定出资源可靠性评估模型，最后把该模型融入到粒子群算法中，通过粒子群算法对该模型样本进行分析，进而完成对云平台微服务架构可靠性的研究。但是该方法只是使用样本模型来进行可靠性研究，但是在现实情况中还会存在一些其他因素的影响，这就导致该方法在现实环境中会出现研究可靠性不精准的问题。

上述方法中均存在分析结果不精准的问题，对云平台微服务架构可靠性研究造成一些不必要的影响，为此提出一种基于DevOps的云平台微服务架构可靠性研究方法，该方法够准确、有效分析出云平台微服务架构的可靠性。

1 传统应用架构与微服务架构对比

传统的Web应用在完成开发后，打包为War包，并放置在Web容器里发布运行。传统应用架构的整体结构如图1所示。

图1 传统应用架构整体结构

传统应用架构有多种有点，例如能够在开发环境中完成本地测试、代码集的完成度较高、有利于团队的协同开发、项目容易打包等。但是传统应用架构也存在多种缺点，这种传统应用架构较为适用于中小型项目，在项目转换较为复杂时会出现难以控制的问题，其主要的表现为：随着业务复杂化与业务难度的提升，项目就会变得较为笨重，需要修改局部并重新测试相关的业务数据，传统应用架构的更新变得非常困难，项目整体[3]频繁发布，传统应用架构的负载程度有限，难以满足频繁发布的需求。

微服务架构是将一种复杂系统里较为独立的应用划分为不同的服务，所有的服务都独立放置[4]，服务与服务之间保持相互独立的状态。所有服务能够放置在一种物理服务器中，也能够单独的分布在不同主机内，所有服务由容器进行统一的管理控制，云平台微服务架构的结构图如图2所示。

图2 云平台微服务架构整体结构

云平台微服务架构的优点有：单一服务高内聚、代码[5]容易理解、开发的速度快、服务之间能够独立放置，单独的服务调试不会干扰到整体项目的运行、每一种服务能够凭借开发者的需求放置到适合的服务器中、容错率较高、个别服务bug不干扰整体系统等。但是，云平台微服务架构也含有不能回避的问题，即服务管理成本上升、复杂性增加、需要管理容器里多种不同的服务实例。但随着一些应用架构的开发，这些问题也得到了较好的解决。

1.1 云平台微服务架构设计模式

云平台微服务架构在具体使用时包含多种设计模式，这些模式中最为常见的模式是代理微服务[6]设计模式与链式微服务设计模式，这两种设计模式分别如图3（a）、（b）所示。在代理微服务设计模式中，客户端并不会聚合数据，代理接口凭借业务需求差别调用不同的微服务，同时把数据反馈至客户端，代理接口在此过程中需要完成请求委派与数据转换的工作。在链式微服务设计模式中，服务A收到请求后会和服务B进行通信，相似的，服务n-1会和服务n进行通信，在通信流程中传递全部的服务利用同步信息。在整体链式调用结束前，客户端需长时间等待。除了上述两种经典的微服务设计模式外，根据具体的设计要求还会出现更多的设计模式，比如聚合微服务设计模式。

图3 两种微服务设计模式

1.2 可靠性评估模型构建

云平台微服务架构的可靠性模型，是由网络可靠性模型扩展得到的，以图论域[7]几率论作为研究工具。融合云平台微服务架构的特点，存在以下三种基本的假设条件：

第一，节点与链路都含有物理意义，都含有能够正常运作的几率；

第二，节点与链路只存在两种情况，即失效与正常；第三，节点与链路之间的几率统计都是相互独立的。因此，云平台微服务架构可以用G=（V，E）表示，V表示云平台微服务架构中节点的集合，E表示云平台节点之间的链路集合。

已经提出的模型大部分都是凭借图的连通向量来评估云平台微服务架构的可靠性。凭借连通向量的可靠性模型研究内容为图的连通几率，分析角度共有三种，分别是：

1）两终端可靠性：在图G里，特定源节点s和任务节点t之间最少要含有一条路径连通的几率，拟作R1(G)。

2）k终端可靠性：在图G里，通过k种节点构建顶点子集，其中，随机两种节点都可以连通的几率，拟定成Rk(G)。

3）全终端可靠性：在图G里，每一种节点之间都连通的几率，拟定成RA(G)。

典型凭借连通向量的可靠性估算方式有，状态枚举法、不交织和法、容斥原理法与因子分解法，四种方法的原理如下。

1）状态枚举法

拟定出云平台微服务架构可靠的全部状态，获得的可靠度是：

2）容斥原理法

容斥原理法通过组合数字中的容斥原理[8]公式估算可靠度，其中最为典型的就是小路集法。一种路集对应云平台网络的一种正常状态，如果网络G中含有m种最小路集，Ai代表第i种最小路集，那么最少含有一种最小路集就能够确保网络处于正常情况。拟定网络正常事件是S，则可靠度的计算公式为：

3）不交织和法

不交织和法是容斥原理的一种改进，通过不交织公式，计算云平台微服务架构中所有最小路集[9]的和，计算表达式为：

4）因子分解法

针对规模较大的云平台微服务，因式分解法通过式（4）将其划分为若干种简单网络[10]，一直持续至不能够在划分为止。

在图G中，G*e为图G将边e缩小后获得的新图，G-e代表图G剔除边e获得的新图，Pe代表边正常工作的几率。

因为云平台微服务架构的使用范围、资源有限，为了将感知区域至少被k种不同节点同时覆盖，需要放置大量的节点，进而确保信息可以被可靠的传输至Sink节点。和传统的应用架构可靠模型相比，云平台微服务架构可靠模型不仅考虑节点之间的连通性，还要考虑网络的覆盖性。

1.3 云平台微服务架构可靠性评估

为了能够准确分析云平台微服务架构的可靠性，通过云平台微服务传输的数据安全性进行评估。首先挑选一种合适的评估指标，计算每一种敏感数据输送路径输入和输出传送端缓冲区的数据计算效率，快速的感知每一种数据输送路径当前的输送状况，并且测评每一种数据输送路径的数据处理能力，根据不同输送路径对数据的处理能力进行敏感数据流量动态匹配，从而安全的传输数据。

依据路径当前的数据输送能力，为每一种敏感数据输送路径匹配各不相同的缓冲区空间尺寸，利用以下方程估算数据输送路径的质量：

式中：

Tfi—敏感数据中路径i的输送端缓冲区时间；

ilT—敏感数据内最后一种数据离开路径i的传送段缓冲区时间；

Mi—路径i的输送端缓冲区尺寸；

Qi—路径i输送端缓冲区的数据处理速度。

采集一种不存在敏感数据包损失[11]的时间间隔作为原始样本，并与历史区间样本进行组合，能够估算出敏感数据传输所有路径的置信区间，代表一条输送路径的时间间隔样本，利用以下公式估算敏感数据输送时间间隔样本的均衡值：

式中：

ix—时间样本里没有发现确实敏感数据包的成功输送区间；

N—样本的总量；

XN—平均时间间隔的均衡值。为了能够剔除敏感数据输送端储存的收集样本[12]，依靠下列方程估算敏感数据输送路径的时间迭代均衡值。

其中：

SN—表所有样本的指标差。

可以利用迭代法估算标准差，进而删除敏感数据在输送端存储的样本：

通过式（7）与式（9）内获得的均衡值与标准差后，融合估算敏感数据成功输送的变异系数Z1−a/2，完成中心极限定理估算出置信范围：

式中：

1−a—置信标准；

u—置信区间；

S、X—每一种样本的均衡值和指标差。

进而得到置信范围，并将其作为进一步测评的根据，更新敏感数据预测趋势并提高输送路径质量。

2 实验证明

上述评估是通过简易的计算数值来进行平台可靠性评估，但在现实环境中还会出现一些其他的影响因素，为此进行仿真实验。实验环境为Intel(R) Core (TM)i5-3470 CPU，3.20 GHz，8 GB内 存 的PC化，通 过MATLAB7.6编程实现，LIBSVM为支持向量机软件。

当云平台微服务架构处于运行状态时，因为各种优先级数据传输占用总线时间与所研究数据占用总线时间的影响，任何数据的时间参数均是一种随机的变量向量。拟定云平台微服务架构里某三种实时数据的每种时间参数，如表1所示。

表1 数据传输时间参数

为了方便对比验证可靠度的估算结果，通过Matlab编制程序进行10次Monte-Carlo模拟，获得数据（a）的传输可靠度R=0.888 8。

如图4（a）里时间余量零线以上的*代表传输失败的微服务数据，时间余量零线以下的·代表传输成功的微服务数据。进过Monte-Cralo模拟对比，能够发现估算结果和Monte-Cralo实验结果完全吻合。

同理凭借式（7）与式（8）能够进一步的获得数据（b）的云平台微服务可靠度R=0.888 2，同理使用Matlab拟定的程序进行Monte-Cralo实验模拟，获得的可靠度R=0.888 3，比对发现他们之间的误差很小。

数据（c）传输的可靠度通过估算查表获得R=0.885 1，通过Monte-Cralo模拟实验，获得可靠度R=0.884 6，结果完全吻合。

通过图4三组云平台微服务数据传输可靠度估算和实验模拟结果可以看出，通过式（7）与式（8）估算得到的云平台微服务数架构可靠度，与使用Matlab编程进行实验模拟获得的可靠度结果非常吻合，相对的误差较小，表明本文推导估算结果的正确性。经过对比上述三组实验可靠度可以得出，数据Ⅲ的可靠度相对较低，而数据Ⅰ、Ⅱ的可靠度较高。这就要求在以后的研究中，要重点研究数据Ⅲ的可靠度成功率，经过分析拟定提升云平台微服务架构的可靠度。以上实验考虑了云平台微服务架构中三种实时性数据，而现实的云平台微服务架构中需要传输的数据种类非常多，同样能够使用该方法对平台中所有数据的可靠度进行依次估算，从而获得整体的云平台微服务可靠度。

3 结论

针对传统云平台微服务可靠性差的问题，提出一种基于DevOps的云平台微服务架构可靠性研究方法，对传统的应用架构和微服务架构进行对比分析，构建可靠性评估模型，利用图论域几率论分析云平台微服务架构的特点，实现云平台微服务架构可靠性的研究。为了能够进一步评价云平台微服务架构的可靠性，设计对比实验，实验结果表明，所提方法能够有效的分析出云平台微服务架构的可靠性，具有较高的实际应用价值。

图4 云平台微服务可靠度Monte-Cralo实验模拟