基于云原生应用平台实现应用服务可造性

刘 超 ，宋 健 ，崔 杰 ，马 野 ，王宇轩

（1国网吉林省电力有限公司信息通信公司 吉林 长春 130000）

（2国网吉林省电力有限公司 吉林 长春 130000）

0 引言

云原生技术能够充分发挥云平台的弹性与分布式技术的优势，从而实现快速部署任务细化项目结构的目的。但是该技术在享受快速部署新业务能力的同时，还需要承担严重的业务风险承受能力，在出现错误与解决错误的过程中同样会消耗大量工作时间，为企业带来额外的业务劳动。对此，为提高云原生应用平台在实际应用中的效率，本文将进一步对云原生平台下数据接入管理问题进行研究，通过融合云原生相关技术对其进行改造，以期提高该技术在实际应用中的应用效率。

1 方案设计

1.1 系统架构设计

高效数据访问层的组成结构主要包括：监控管理模块、通信协议模块、结果集处理模块、路由解析模块、SQL执行模块以及数据库链接模块。各模块间的信息流通见图1。

其中，监控管理模块主要承担与高效数据访问层的连接，并对内存资源等数据进行监控与管理，实现方式主要以管理命令为主，对轮询事件以判断是否需要释放资源存储空间。通信协议模块主要负责系统底层的收发数据以及各任务线程的回调处理，使用Poractor模式实现提高效率的目的[1]。结果集处理模块负责对各云端跨分片任务产生的结果进行收集和整理，因云原生数据具备跨云迁移的能力，所以需要对跨分片产生数据进行汇总管理。路由解析模块承担系统对SQL命令的解析，解析内容包括MySQL协议中引用到该模块的SQL语句、类型以及关键字等，以此生成最优路径结合路由计算单元进行计算。SQL执行模块承担连接池与对应目标的连接，在与目标连接之后完成信息同步，结合路由解析模块的解析结果，将SQL命令语句下至对应节点执行。数据库连接模块承担系统产生数据的存储、维护和管理[2]。

1.2 总体的执行流程

数据访问层的主要流程由结构下通信协议模块开始，由回调线程对读写事件的具体内容进行读写处理，此时管理模块会调动定时器对事件资源进行检查并对判断完成的事件进行资源释放[3]。客户端层面由用户调用虚拟IP地址链接登录到负载均衡器，由负载均衡器结合预制算法链接到事件对应的数据访问层，此时数据访问层的活动将交由NAS盘管理，并在事件链接到对应的数据库后将结果返回给客户端[4]，详细流程见图2。

该结构下后端数据库的返回数据会通过相关协议解析后重新发送至回调模块，若返回过程涵盖多个节点数据，则返回的执行结果会先进行汇集和预排序，然后将数据经由通信协议模块反馈至客户端。

2 应用服务可造性

2.1 云原生应用流行度分析

虽然有关云原生相关技术的研究已经初具成果，但是从云原生发展角度来看，该项技术仍处于研究的初级阶段，因此通过对云原生应用流行度的调查分析，可明确现阶段云原生用户的喜好，以此设计更加简洁的数据访问层结构框架，并为云原生应用平台的能耗提供进行判断依据。由此可认为云原生流行程度越高，各功能方向的用户偏好性就越强，用户访问云原生应用平台的次数便会增加[5]，所造成的数据访问层功率负荷就越高。因此，在考虑云原生平台应用可造性之前，应当引入应用流行度指标，以此使应用可造性结果能够更加贴合云原生发展初期的微服务租用比例，进而提升其结构变化产生的收益。由此，可假设在某环境下存在N个不同应用，应用集合可用“A”表示，则第n个应用在时刻下的流行度可表示为“Dn”。因应用不同会使得不同时刻下存在不同的流行度，若云原生应用供应商的应用集可结合应用的流行度进行排列，则用户对某项应用发送需求请求的概率为“DN”，且其服从Zipf分布[6]。考虑到云原生应用的发展时间，本文将在DN的计算中引入调节因子“θ”，以此方式平衡发展较早云原生应用对用户产生的影响，进而稳定用户偏好和访问次数与频率。DN的表达式为：

上式中：α表示云原生应用在时段下的流行度指数。

2.2 用户偏好性

结合上述分析可得到该地区云原生应用的用户偏好性，用户偏好性的大小可直接影响云原生结构所发挥的效益，即若用户对某项应用的偏好性较低，则该地区云原生应用所产生的收益便会不断下降，由此会造成偏好性较低应用闲置占用系统内存，而偏好性较高的应用存在系统负荷工作的情况[7]。因此，为提高云原生应用的服务质量，本文将融合当地用户偏好性指标作为可造性评价的衡量标准，为降低系统能耗并提高数据访问层数据调用效率奠定基础。用户偏好性受用户体验水平、应用时延、能耗以及满足需求程度等多方面因素影响。对此，若设每个独立应用均存在M个评价指标，且所有评价指标皆存在R个离散取值，由此可构建应用所对应的偏好矩阵“G”：

上式中：gmr代表用户对某个应用特性m的偏好程度，gmr∈ [0，1]。

若用0表示用户对某项特性的反感，1表用户喜欢某项特性，则m∈｛1,2，…,M｝，r∈｛1,2…,R｝。W=[W1W2…WM]，表示评价指标M的权重值矩阵，则用户对云原生下第n个应用的偏好性为：

上式中：ε表示用户的偏好性影响因子；λ表示云原生应用商对某项微服务给出的租用比例。

若设“Q”为评价指标的取值数量，且Q能够自行设定，则结合大数定律可认为当Q趋于无穷大时，存在收敛常数值“Bn”，即：

2.3 云原生应用能耗

用能耗表示云原生应用平台在应用中可造性的取舍值，即取舍值越大表示改造后的云原生应用平台仍存在数据资源访问不均的问题，需要重新进行改进，取舍值越小表示改造后云原生应用平台数据访问均匀，数据调用响应率高。从云原生应用平台的开发角度来看，开发方向主要以微服务开发为主，并以维持云原生应用平台稳定运行为工作方向，推进该技术的发展。由此，可将云原生应用平台的能耗用运行能耗Er和微服务开发能耗Ed进行代替，则云原生应用平台的能耗总量为：

上式中：emr表示单位时间内微服务运行产生的能耗；etr表示单位时间内传统应用运行产生的能耗；tdev表示微服务开发的时间；trun表示应用运行的时间；eidle表示系统空闲时应用待机所带来的能耗；Ttotal表示云原生平台应用开发与运行的总耗时。

2.4 应用无状态化

无状态应用（Stateless Application）指不会在会话中保存下次会话中需要的客户端数据，每个会话都像首次执行一样，不会依赖之前的数据响应，其使分布式水平扩展成为可能。应用无状态化的优势在于能在应用平台出现故障时轻松部署，并且能自由的水平扩展来适应负载，在组建之间也可通过API进行通信。云原生应用平台中微服务是重要组成元素之一，无状态应用可以很好地结合微服务来完成各项服务[8]。

2.5 热数据缓存

根据数据的使用频度可分为热数据、温数据、冷数据，热数据一般指半年以内的数据，此类数据经常会被用户查询，适合放在数据库中存储。在实际的应用中，传统的方式是在程序启动时调用热数据，从而提高数据的访问速度，但由于数据的量不受控制，若数据量过大，可能就会导致程序启动过慢，影响程序的使用感。基于此，云原生应用平台将热数据放到缓存中，一方面减少了数据库的存储量，另一方面能提高程序的启动速度，使程序的可用性提高。

2.6 网络梳理

应用容器化之后需进行相应的网络梳理和规划，用以保证其正常运行。在进行网络梳理时，首先应根据容器平台的情况将其进行分类，通常可分为管理集群master、计算集群slave、系统服务集群（包括各种日志、监控、镜像仓库等），根据网络的使用，可将管理集群和系统服务集群划入管理IP网段，将计算机群划入业务IP网段，通过区分不同集群所处的IP网段，对各组件的端口进行规划，从而保证网络运行通畅。同时，针对不同应用的特性，应选择不同的网络模式，从而使其能提供更好的服务。

2.7 docker的改进优化

云原生下docker容器服务器集群的响应性能可影响其平台的延时波动，可通过动态负载容器服务器算法给予优化。该方法以WRR负载算法为基础，通过融合实时权值理念弥补WRR算法权值给定上的缺失。通过优化容器连接数、CPU、内存、网络IO以及平均相应的方式得出docker的实时权值，由此得到docker容器服务器的最优ID，以此承担云原生应用活动的负载。通过分摊流量的方式均衡访问造成数据流的过载问题，利用容器服务器和算法的弹性优势吸纳服务器集群并发产生的访问压力。由此，可在用户偏好集中在某一活动，且无法通过上述方法给予分量时，维持云原生平台应用的响应效率。

2.8 确定域名、端口、TCP和HTTP协议

考虑到云原生平台的特殊性，在平台下各应用容器化之后应当保证每个服务只承担一个服务内容。避免采用IP的方式，因服务与其他目标服务进行通讯会受到容器IP不固定因素影响而出现无法通讯的情况。对此，本文建议应当在程序中通过使用域名的方式代替IP地址，并借助Kubernetes的负债均衡给予优化。在系统的监听固定端口方面，对于一个标准的服务应当只为其提供一个对外的端口，因部分服务在运行时会自主产生一些对外的端口，并且产生概率具有较高的随机性，会对之后的平台管理造成极大地困扰。在通信协议方面应当尽量采用TCP和HTTP协议进行交互，而避免使用EJB调用t3协议，进而避免无法借助负载均衡器的方式进行有效的负载均衡。对此，本文建议使用TCP或HTTP协议的方式进行通信，以此提高使用负载均衡器的有效负载均衡效果。

3 实验验证

为验证上述改造架构的可行性与实用性，将构建仿真地域云原生应用平台的实验环境，主体架构使用当地原有结构框架，选取某阶段下用户实际需求作为评价参数。测试实验主要以端到端形式为主，通过仿真模拟外围环境发起的需求相应数据调用测试环境，验证改造后访问层的解析效率，进而判断改造后数据访问层的实际能力。为彰显本文所提方法的优化效果，本文将以普通数据库作为实验对照，将两种方法置于相同实验环境下进行测试，以需求响应时间为判断标准，测试结果见表1和表2。

表1 本文所提方法的性能测试结果

表2 普通数据库的性能测试结果

由上表1和表2中数据可知，云原生平台应用数据访问层改造后响应效率较高，当并发数增加值90时，平均请求反应时间仍未超过95 ms，而普通数据库的需求命令数据调用效率在并发数处于40时便超过95 ms。将测试数据转化为折线图见图3。

由上图数据可看出，两种方法在并发数增加至60时整体性能处于相对稳定状态，改造后的数据访问层需求响应速率性能是普通数据库性能的1.3倍。由此可证明本文所提方法具有较高的实用性，可应用于云原生应用平台的优化项目当中。

4 结语

综上所述，本文通过对云原生平台应用可造性的研究，提高其数据访问层的响应速率。结合现阶段云原生应用现状引入应用流行度、用户偏好性和应用能耗等改造指标，通过对任务需求效率分析，明确空间下云原生平台应用数据调用效率的影响因素，以此分析解决改造后云原生平台出现的异常情况。从实验结果可看出，本文所提方法能够有效提高系统数据调用的响应效率，证明所提方法具有较高的可行性与实用性，能够为相关人员或单位提供参考。