ＭｉｃｒｏｃｏｍｐｕｔｅｒＡｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２．Ｎｏ．７．２０１６ 文章编号：１００７—７５７Ｘ（２０１６）０７．００２９—０５ 项Ｉ ｌ微型电脑应用２０１６年第３２卷第７期 基于ＳＯＡ架构的新型云平台服务管理中间件 陈世宜，叶德建 摘要；随着云计算技术的发展，针对细分行业的云平台不断涌现。以流媒体云平台为代表的私有云，为了降低成本、兼容 原系统，通常采用整合服务的方式实现，随着系统的升级、模块集群化的增强，传统的负载均衡中间件难以有效处理服务间 的频繁长链调用。针对传统流媒体云平台采用负载均衡中间件实现子服务调用存在的灵活性差、效率低、可用性低等问题， 设计并实现了一种新型的针对基于ＳＯＡ构架的流媒体云平台应用层服务管理系统，该系统采用生产者／消费者模型，通过注 册中心配对的方式实现高效灵活的服务调用，提高云平台整体性能。 关键词：ＳＯＡ；云平台；服务管理；负载均衡中间件 中图分类号：ＴＰ３１２ 文献标志码：Ａ ＳＯＡ—ｂａｓｅｄ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ Ｍｉｄｄｌｅｗａｒｅ ｏｆ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ Ｃｈｅｎ Ｓｈｉｙｉ，Ｙｅ Ｄｅｊｉａｎ （Ｃｏｌｌｅｇｅ ｏｆ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ，Ｎｏｒｔｈｅａｓｔ Ｐｅｔｒｏｌｅｕｍ Ｕｎｉｖｅｒｓｉｔｙ，Ｄａｑｉｎｇ １ ６３ ３ １ ８，Ｃｈｉｎａ） Ａｂｓｔｒａｃｔ：Ｗｉｔｈ ｔｈｅ ｄｅｖｅｌｏｐｍｅｎｔ ｏｆ ｔｈｅ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ，ｉｎｄｕｓｔｒｙ—ｓｐｅｃｉｉｃ ｃｌｆｏｕｄｓ ｈａｖｅ ｃｏｍｅ ｏｕｔ ｉｎｃｒｅａｓｉｎｇｌｙ ｆｏｒ ｔｈｅｓｅ ｙｅａｒｓ．Ｔｈｅ ｐｒｉｖａｔｅ ｃｌｏｕｄｓ ａｒｅ ｓｅｔ ｕｐ ｂｙ ｇｒｏｕｐｉｎｇ ｔｈｅ ｓｅｒｖｉｃｅｓ ｉｎ ｏｒｄｅｒ ｔｏ ｃｕｔ ｔｈｅ ｃｏｓｔ ｗｈｉｌｅ ｋｅｅｐｉｎｇ ｃｏｍｐａｔｉｂｌｅ ｗｉｔｈ ｔｈｅ ｏｌｄ ｓｙｓｔｅｍ．Ｈｏｗｅｖｅｒ， ｃａｕｓｅｄ ｂｙ ｔｈｅ ｓｙｓｔｅｍ ｕｐｇｒａｄｅ ａｎｄ ｍｏｄｕｌｅ ｃｌｕｓｔｅｒｉｎｇ，ｉｔ ｉｓ ｄｉｉｃｕｌｆｔ ｆｏｒ ｔｈｅ ｌｏａｄ ｂａｌａｎｃｅｒ ｔｏ ｈａｎｄｌｅ ｗｉｔｈ ｔｈｅ ｌｏｎｇ—ｃｈａｉｎ ｃｏｍｐｌｉｃａｔｅｄ ｓｙｓｔｅｍ—ｃａｌｌｓ ｂｅｔｗｅｅｎ ｔｈｅ ｓｅｒｖｉｃｅｓ ｅｆｆｅｃｔｉｖｅｌｙ．Ｔｈｅｒｅｆｏｒｅ，ａ ｎｅｗ ＳＯＡ—ｂａｓｅｄ ｓｅｒｖｉｃｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ ｆｏｒ Ｃｌｏｕｄ ｐｌａｔｆｏｒｍ ｉｓ ｐｒｏ— ｐｏｓｅｄ ｔｏ ｍａｋｅ ｉｔ ｍｏｒｅ ｆｌｅｘｉｂｌｅ，ｅｆｆｅｃｔｉｖｅ ａｎｄ ｆｅａｓｉｂｌｅ．Ｔｈｉｓ ｓｙｓｔｅｍ ｉｓ ｉｎ ｐｒｏｄｕｃｅｒ／ｃｏｎｓｕｍｅｒ ｍｏｄｅ ａｎｄ ａｃｔｕａｌｌｙ ａ ｍａｔｃｈｅｒ ｆｏｒ ｃａｌｌｅｒ ａｎｄ ｃａｌｌｅｅ ＳＯ ｔｈａｔ ｉｔ ｃｏｎｔｒｉｂｕｔｅｓ ｔｏ ｔｈｅ ｂｅｔｔｅｒ ｐｅｒｆｏｒｍａｎｃｅ ｏｆ ｔｈｅ Ｃｌｏｕｄ ｐｌａｔｆｏｒｍ． Ｋｅｙ ｗｏｒｄｓ：ＳＯＡ；Ｓｔｒｅａｍ Ｃｌｏｕｄ Ｐｌａｔｆｏｒｍ；Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ；Ｌｏａｄ Ｂａｌａｎｃｅｒ ０引言 随着 联嘲行业的发展以及云计算技术日益成熟，云 台因其低成本、可拓展、高可朋、高性能等优势被业界广’泛 使用，越来越多的企业业务被迁移至云 台。因为各领域业 务需求干差万别，所以出现了各类行业细分云，如金融云、 视频流媒体云、电子商务云等。 为了降低成本、提高效率、应对服务灵活多变的特性， 企业云或行业云作为一种新型的产业升级方式，普遍采用服 务整合的方式来架构云平台。具体体现为通过模块化重构原 何系统，将原本业务系统抽象为功能服务，而随着系统升级 产牛的新型业务则可以通过服务组合来实现。在技术实现层 面上，服务组合表现为约定协议、统一接口系统问的调用， 常以ｗｅｂ服务调用作为其基本实现方式…。 随着云平台业务拓展，内部模块化服务系统问的调用日 益复杂：同时，为了保证云平台的性能需求，大量子服务系 统采用分布式架构。以上的发展趋势都在一定程度．Ｉ：增大了 了服务系统间通讯、调用的难度【２１。为了提高各个组合服务 的吞吐率并缩短响应时间，厩需开发一种高效的云平台服务 管理中问件［３】。 并指出其存在的效率低、灵活性差、可片ｊ性低等问题，借鉴 爿：改进了ＳＯＡ（面向服务的架构）的基本服务管理策略， 针对流媒体云平台具体应Ｈｊ场景设计 了一种基－ｒ ＳＯＡ架构 的新型服务管理中间件，旨在提供一’种高效灵活的云平臼服 务问通信机制。 ｌ原流媒体云平台服务管理 １．１流ｆ（ｉｌ体 、 俞概况 流媒体 、 台 １所爪： 本文研究分析了现有流媒体云平台服务通信机制，发现 图１流媒体云平台架构图 基金项目： 海市科委项目（１２５１１５０３００２）； 作者简介：陈世宜（１９９０一），女，吉林，复旦大学软件学院，硕士研究生，研究方向：嘲络多媒体，上海，２０１２０３ 叶德建（１９７６ ），男，浙江，复旦大学软件学院，剐教授，研究方向：网络多媒体，上海，２０１２０３ ·２９· Ｍｉｃｒｏｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２，Ｎｏ．７，２０１６ 基金项目 微型电脑应用２０１６年第３２卷第７期 底层实现可简单抽象为计算服务与存储服务两部分。计 算服务，主要包括前端ＨＴＴＰ服务器及应用服务器；存储服 务，主要包括ＳＱＬ数据库集群、内存缓存集群、对象存储 服务和大数据处理平台等。计算服务分布在虚拟机上，利用 负载均衡中间件一般用来应对高并发用户请求，通过负 载均衡技术将不同的请求分配给不同的服务器处理，可以有 效缓解单台服务器的压力【 。而在云平台的服务调用过程中， 业界普遍利用负载均衡中间件对外表现统一接口，高效转发 虚拟机平台提供的资源隔离机制提高云平台服务器资源的 利用率，同时由于计算服务本身无状态的特性，使用虚拟化 技术并不损失系统的可用性。存储服务分布在物理机上，确 请求的特性。在处理服务间的调用时，首先将不同服务的服 务地址及路径记录在负载均衡“转发表”中，从而使服务问 的ＲＰＣ调用请求首先发送到负载均衡中间件，负载均衡中 间件根据已配置好的“转发表”中的记录，将客户端的请求 保数据访问性能并提供数据的可靠持久化。 海量客户端发送请求至云平台，通过负载均衡集群将请 求转发至前端ＨｒｒＰ服务器，前端服务器从对象存储中读取 视频图片等资源，并调用应用服务层服务，应用服务借助内 转发对应的应用服务器来进行处理。负载均衡器与服务器之 间有心跳检测，当应用服务器不可用时，负载均衡器将失效 服务器的地址从“转发表”中临时性删除，当该服务器恢复 工作之后，负载均衡器可以将其地址重新添加到“转发表”。 为了避免负载均衡中问件出现单点故障的风险，可通过心跳 机制维持多台备份。 然而负载均衡中间件在实际的使用中会出现如下问题： 存缓存集群提高操作响应速度，将日志等信息存储在 ＮｏＳＱＬ大数据平台待进一步数据挖掘与分析，而业务信息 则统一存储在ＳＱＬ集群中。 云平台的应用服务层通过各个服务模块系统的组合调 用完成，将基本业务抽象为几大核心服务，包括视频点播、 云解码、视频质量监控、终端状态统计、个性化推荐、云推 送等，借助各个服务间的组合提供弹性灵活的业务功能和各 个核心服务内部又可以划分为更细粒度级的子服务组合。终 端用户请求视频点播时调用的子服务，如图２所示： １）负载均衡中间件转发子服务模块间的请求与响应从而使 处理效率低下。如图１所示，服务间的交互均需要通过负载 均衡中间层，即每次请求与响应都经过负载均衡中间件的转 发，那么服务器与负载均衡中间件的连接耗时势必会影响服 务的响应时耗，尤其当某服务的子服务间的调用链长增长时， 竺 悝点ｌ播 连接转发耗时会对于服务整体时耗的影响越发明显。２）负 载均衡中间件本身因其使用的单点布局而成为系统的性能 瓶颈。服务对于负载均衡中间件的压力会随着该服务子服务 匡 卜画荐 链长的增加而成线性增长，完成一次子服务链长为ｌ０的服 务，需要访问负载均衡中间件１０次，而一旦高并发访问此 类长链服务会造成中问件的崩溃，进而整个系统瘫痪。３） 负载均衡中间件需要手动配置转发地址，因此服务器变更时 不能自动动态转移，需要人工改变配置。这给系统的维护人 员造成了很大的压力。 图２点播业务 服务分解 当终端用户请求视频点播服务时，首先需要经过用户认 证系统加以认证，确定用户信息，进行点播操作，依次调用 账广 查询服务、定价服务以及收费服务，同时系统也向用户 推荐影片，依次调用个性推荐服务及影片信息服务。所以在 流媒体云平台中的服务调用存在如下特点：１）存在大量针 对业务逻辑的服务调用，因此大部分服务都需要在基于虚拟 机的服务器上进行。２）针对基础服务的请求多为长链调用。 ３）服务问的组合纷繁复杂，会出现交叉调用的情况。 １．２基于负载均衡中间件的服务管理 目前流媒体云平台采用负载均衡中间件来处理服务间 的调用，如图３所示： 目前主流的负载均衡中间件主要有Ｎｇｉｎｘ、ＨＡＰｒｏｘｙ、 ＬＶＳ等。针对问题１，ＬＶＳ技术只转发请求不转发响应，在 一定程度上提高了效率，但是ＬＶＳ并不适用于虚拟机通讯， 因此在流媒体云平台系统中无法发挥优势：由于流媒体云平 台的基础服务多为长链调用，问题１、２在流媒体云平台中 表现得更为突出；由于流媒体云平台中的服务调用复杂，在 出现问题３时人力成本加重。所以，负载均衡中间件并不是 流媒体云平台服务管理的最佳方案。 ２新型云平台服务管理系统 针对以上问题，本文设计并实现了一种基于ＳＯＡ的新 型服务管理中间件来解决流媒体云平台中系统调用的问题。 本系统将服务间ＲＰＣ调用抽象为应用层服务，将服务调用 的双方抽象为生产者和消费者的模型，服务提供方与请求方 通过注册中心完成配对，在请求方缓存可调用提供方信息， 同时监控中心记录消费者与生产者调用记录，作为日后负载 均衡评估算法权重的数据信息。这样的设计首先缩短了采用 负载均衡模式产生的通信耗时，注册中心只负责配对，而具 体交互由请求方和提供方独立完成，不必经由负载均衡器转 图３负载均衡原理 发；注册中心采用Ｚｏｏｋｅｅｐｅｒ集群，同时请求方缓存提供方 ·３０· Ｍｉｃｒｏｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２，Ｎｏ．７，２０１６ 基金项日 微型电脑应用２０１６年第３２卷第７期 信息，这都提高了系统的可Ｈ］性：注册机制以及实时监控也 保证了服务提供方的变更可以及时更新。本中间件处理服务 调用的具体流程如图４所示： 协议体设计针对具体的通信场景设计了服务ＩＤ、服务 类型、ＩＰ地址、端口号、服务位置、会活ＩＤ、时问戳以及 操作结果字段。在以上通信场景中，各字段的使用情况如表 １所示： 表Ｉ自定义协议内容 操作 信息 类型 字段 含义 服务类型 ＩＰ地址 请求 提供服务类型 捉供方ＩＰ地址 提供方端ＬＩ 提供方提供服务的 体目录 端【＿】号 注册服务 服务位置 图４中『自ｊ件工作流程 １）服务提供方向注册中心注册所提供的服务。２）请求 方向注册 心请求服务。３）注册中心存注册表中查找相关 服务，并通过负载均衡策略将特定服务提供方通知给请求方。 ４）请求方此时获得了提供方的地址，可以直接调用提供方 的服务，同时在收到注册中心卜一次通知前持续调用该提供 方服务。５）同时服务请求方与提供办将此次调用的结果记 请求服务 请求 刚复 操作结果 服务ＩＤ 注册申请足否成功及失败原 注册中心分配的服务ＩＤ 服务类型 ＩＰ地址 端¨号 淆求方清求的服务类型 请求方ＩＰ地址 请求方端Ｌｌ号 录在监控中心，作为负载权重计算的原始数据【５］。６）监控 中心将计算结果以通知的方式发送给注册中心。以下小节针 对本中间件各层实现具体展丌。 ２．１通信层 服务ｌＤ ｌＰ地址 通知服务 通知 端Ｈ号 服务地址 注册中心分配给请求方的服务ＩＤ 注册中心分配给请求方的ＩＰ地址 注册中心分配给请求方的端口号 注册中心分配给请求方的具体雕 录 本中间件通讯层采用基 Ｊ ＮＩＯ的Ｎｅｔｔｙ框架实现。相较 于传统１０，ＮＩＯ通过选择器、通道、缓冲区的设计实现了 高性能非阻塞１０读写机制，支持高并发，同时编程实现简 单。Ｎｅｔｔｖ在ＮＩＯ的基础上对其进行了封装，提供了一套异 步的、事件驱动的网络应用程序框架和工具。在此框架＿Ｆ， 本巾间件设计了符合应用场景的自定义协议来完成服务提 供方、服务请求方、注册中心、监控中心问的交互。 通讯协议主要包括协议头与协议数据两部分内容。如图 ５所示： 记录服务 淆求 会活ＩＤ ＩＰ地址 ｊＩｆｃ控中心分配的会话ＩＤ 提供方ＩＰ地址 清求方请求发出时间／提供方服务 时问戳 完成时间 协议头 信息标志位 操作标志位 长度 超时时间 服务类型 提供方提供的服务类型 服务ｌＤ 服务类型 协议体 ｌＰ地址 回复 操作结果 操作结果 ＩＰ地址 提供方调用结果／请求方通知 监控中心足否接收剑信息 权重更改的ＩＰ地址 端口号 服务位置 会 Ｄ 时间戳 图５自定义协议内容 操作结果 ｊ 控服务 通知 计算权重 更改后的权重值 协议头主要包括：信息标志位、操作标志位、协长度以 及超时时间字段。信息标志位叮设置值为请求、回复与通知， 可用２比特位表示。操作标志位取值为服务注册、服务请求、 服务通知、请求调用记录、调用结果记录以及监控回馈，可 用ｌ字节表示。长度字段显示协议体字节长度。超时时问字 段确保服务无法得到回应时，由请求方再次发起请求。 ２．２注册中心 注册中心实现了本中间件的主要业务功能：为服务请求 方和服务提供方的连接提供了媒介；通过最优选择方式实现 了负载均衡；与服务提供方保持长连接以及时修改各服务当 前状态。 ·３ｌ· Ｍｉｃｒｏｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２，Ｎｏ．７，２０１６ 基金项目 微型电脑应用２０１６年第３２卷第７期 ２．２．１流程设计 址、端口号和服务位置来判断该服务是否应该被注册，若为 新服务则产生新服务ＩＤ分配给该服务。每个服务的ｒＰ地址、 端口号和服务位置从通信信息中直接读取，并记录在注册表 中。选择权重用于注册中心匹配算法，由监控中心产生，并 发送给注册中心。服务类型用以区分提供方提供的不同服务， 多个服务可提供相同类型服务。可用状态信息根据注册中心 与各个服务提供者间的心跳状态及时更新。 ２．２－３匹配策略 注册中心的基本业务流程如图６所示： 注册中心针对请求服务会首先在注册表中选择提供该 类型服务的一组服务ＩＤ。此时为了提高系统效率，减少调 用失败，注册中心首先会筛选此时可用的服务，即可用状态 为Ｔｒｕｅ的服务。在完成第一轮筛选后，根据权重值，选出 权重最大的服务，将其封装为通知消息发给服务请求方。权 重值的计算由监控中心完成，这在一定程度上减轻了注册中 心的负担。 ２．３监控中心 本中间件中的监控中心主要负责收集数据，并根据权重 算法计算注册表中的新权重，计算结束后将结果以信息形式 发送给注册中心，作为每次匹配依据的权重值。 ２－３．１数据采集 图６注册中心流程设计 监控中心接收来自请求方与提供方的记录信息。搜集的 主要信息内容包括会话ＩＤ、操作结果、ＩＰ地址、服务类型 以及时间戳等。以会话ＩＤ为标识，不同ＩＰ地址的同一会话 ｌＤ的信息收集，可以获得当前不同ＩＰ地址服务器目前尚未 在本服务启动阶段，注册中心接受来自各个服务器的消 息，通过信息类型判断后续操作。如果为请求信息，则再次 通过解析协议头的操作标志位字段判断协议类型。若为注册 服务，在当前注册表中根据ＩＰ地址，端口号以及服务地址 构成的服务唯一标识判断服务是否已经注册，对于已经注册 的服务回复注册失败消息，消息体中包含错误码及错误信息， 对于新注册的服务，将其写入注册表中，并回复注册成功， 同时与其保持长连接，通过心跳机制确定服务提供方是否可 用：若为请求服务，则在注册表中查找该类型服务的提供方， 同时根据权重选择最优服务ＩＤ，将其通知给请求方。若信 息类型为通知类型，则修改注册表中的选择权重数值，同时 通知给全部消费者。 ２．２．２存储支持 本中间件作为云平台应用层服务，为了实现平台整体的 可拓展、高性能、高可用等特性，注册中心采用了分布式的 处理的任务数ｎ（１Ｐ１。在协议头中可以读取信息超时时间 Ｑ ｅｘｐ。根据请求方的操作结果信息可获得针对不同ＩＰ地址 服务器请求超时的结果Ｙ（ＩＰ）。根据相同会话ＩＤ的时间戳 可以获得指定ＩＰ地址服务器处理特定服务类型耗时ｔ（ｅｎｄ， ＩＰ，ｓＴｙｐｅ，ｓＩＤ）一ｔ（ｓｔａｒｔ，ＩＰ，ｓＴｙｐｅ，ｓｌＤ）。 ２＿３．２权重计算 为了提高系统的整体效率，缩短调用耗时，同时合理分 配资源，注册中心针对每次具体请求的配对过程中，应考虑 以下４点主要因素：１）提供方服务器最近是否过载，目前 无法处理服务请求；２）当前各服务提供方机器任务分配情 况；３）服务提供方机器最新处理特定服务请求耗时情况：４） 服务提供方历史处理特定请求情况。以上四点因素对于分配 结果的影响效果依次递减。结合监控中心收集的数据，可以 依次表示以上因素如下。 服务提供方是否过载可通过请求方请求超时的结果 设计，即建立注册中心集群，这样一方面避免了单点故障的 风险，另一方面在注册中心处理大规模并发请求时极大地缩 短了等待时间，提高系统性能，改善服务质量。 注册中心通过Ｚｏｏｋｅｅｐｅｒ来实现分布式存储。Ｚｏｏｋｅｅｐｅｒ 是一种开源的分布式应用程序协调服务，提供了配置维护、 Ｙ（ＩＰ）表示。对于分配权重的影响直接表示为Ｗ Ｙ（ＩＰ）ｅ ｛０，１｝，０代表当前状态未过载，１表示出现过载，即收到请 求方发送的超时消息。 名字服务、分布式同步、组服务等功能，其核心基于Ｆａｓｔ Ｐａｘｏｓ算法，通过投票选举协议确保存放在各个节点上的数 据能够保持强一致性。 当前各服务提供方机器任务分配情况以任务数来进行 表示，即Ｎ＝＜ｎ（ｉｐ１），ｎ（ｉｐ２），ｎｏＰ３）…．＞，ｎ（ｉｐ ）ｅＮ。机器分配情 注册中心主要存储各个服务的注册信息以及当前状态。 况对于权重的影响可以抽象为ＷＮ——－。即权重随着请求方 １任务数的增多而急剧减少，这在一定程度上可以避免服务发 生过载情况。 服务提供方机器最近处理特定服务请求耗时情况根据 注册表以关系型数据库表的形式将注册服务持久化，该表中 包含的字段为：服务ＩＤ、ＩＰ地址、端口号、服务位置、服 务类型、选择权重以及可用状态。服务ＩＤ为自增字段，每 当有一个新的服务请求注册时，根据核对之前表中的ＩＰ地 ·３２· Ｍｉｃｒｏｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２，Ｎｏ．７，２０１６ 基金项目 微型电脑应用２０１６年第３２卷第７期 最近次耗时的绝对值进行计算。最近次耗时的绝对值表示为 ｔ（ｅｎｄ卜ｔ（ｓｔａｒｔ），分配权重为ｗＴ，具体计算方式如公式（１）： ｔｅｎｄＰｓｔａｒｔＩＰ） （Ｊ）ｔ（，－．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．括注册，请求以及记录等类型消息，并且对于来自注册中心 以及监控中心的信息进行解析处理，完成业务逻辑。同时为 了提高系统的吞吐量和可用性，请求方缓存处理相应服务的 提供方地址，只在接收到注册中心通知的情况下更改服务提 ．．．．．．．—（，Ｐ）＝ ，ｗｔ￣（ｏ，１） （１） 供方信息，减少了反复请求建立连接的消耗，同时也便于在 注册中心失效时，依然可以正常调用服务。 ｗＴ的取值区间通过归一化处理，将其映射到（０、１） 区间。 ３系统测试 本中间件作为应用层系统中间件应用于清鹤流媒体云 平台，解决私有云平台中业务服务间Ｐ．ＰＣ调用的问题。针 服务提供方历史情况基于以往Ｎ次处理此类服务所需 时间进行计算，即Ｈ＝＜Ａ ｔｌ，Ａ ｔ２，Ａ ｔ３…＞，其中△ｔｎ（ ）＝ ｔｎ（ｅｎｄＩＰ）一ｔｎ（ｓｔａｒｔＩＰ），分配权重为ｗＨ。ＷＨ主要由两部分组 ．，对该系统的处理效率和吞吐量等指标设计了相应实验进行 测试。实验环境为清鹤流媒体云平台的虚拟机测试环境，每 台虚拟机的配置相同，如表２所示： 表２测试环境硬件配置 ＣＰＵ核数 ２ 成，即以往历史调和均值以及历史波动，即均值越高处理时 间越长，浮动越大越不稳定，那么相应的权重值也越低。具 体计算方式如公式（２）： ｗＨ（ｔＰ）＝１－去 刍Ａｔｎ（１ｐ）－ １ Ｎ（Ａｔｎ（ｉｐ）－ｚ， ０＜△ｔｎ＜ａｅ ｐ （２） ＣＰＵ主频 ２．４ＧＨｚ 内存 ４Ｇ 操作系统 ｕｂｕｎｔｕ１２．０４ 各服务器网卡均为千兆网卡，所在网络的交换机速率为 １０Ｇｂｉｔ／ｓ，即网络环境不会成为实验瓶颈。原系统负载均衡 中间件采用ＨＡＰｒｏｘｙ１．４．２４，ｗｅｂ服务采用Ａｐａｃｈｅ Ｔｏｍｃａｔ ８．０服务器。 ３．１响应时间测试 公式（２）中 。 。为服务超时时间，△ｔ（ ）为以往Ｎ次 调用处理平均时间，在计算历史均值作为判断机器当前情况 的过程中，最近次的处理时间对于权重结果的影响最明显， 随着距当前时间的时间差越大，影响程度逐一递减。同时历 史处理时间的波动作为衡量机器稳定性的重要因素。这两方 面的影响同时进行归一化处理，使得ｗＨ的值在（Ｏ，１）区间 内波动。 本实验在服务调用效率方面对新型中间件与传统负载 均衡中间件进行了对比。由于在单次服务调用过程中会发生 多次ＲＰＣ调用，因此，本文定义服务调用的链长为单次服 务请求过程中发生的ＲＰＣ次数。本实验通过测试不同链长 影响匹配结果的权重计算基于以上４种子权重的综合 考虑，根据各个权重的影响强弱，综合为最终的权重计算方 式如公式（３）： 的服务请求的响应时间来衡量新旧中间件通信效率。 实验过程如下：使用ＣＵＲＬ工具模拟服务调用的ＨＴＴＰ 请求，模拟过程共分２０组，每组服务调用链长不同；每组 进行２０次服务调用，记录每次通信耗时；将每组的实验数 据进行排序，选择排序结果为８至１２位的５组数据作为最 终结果，以排除测试中由于网络环境等因素影响而产生的数 据噪点如图７所示： 封麓ｆｔ摹， Ｗ（ＩＰ）＝Ｗｖ０Ｐ）＋２Ｗｙ（Ｉｐ）ＷＮ（ＩＰ）＋ ｗＹ（ＩＰ）ｗＮ（ＩＰ）ｗＴ（ＩＰ）＋ ｗＹ（ＩＰ）ｗＮ（ＩＰ）ｗＴ（ＩＰ）ｗＨ（ＩＰ） （３ 即计算权重时，可以充分保证４种因素对于权重的影响 的优先级顺序，即若ｗｒ（ＩＰ１）＞ｗｙ（ＩＰ：），￣Ｕｗ（ＩＰ１）＞Ｗ（ＩＥ２）； 当ＷｖｏＰ１）＝ｗｒ（１Ｐｚ）时， 若Ｗｎ（ＩＰ１）＞ｗＮ（ＩＰ２）， 则 Ｗ（ＩＰ１）＞ｗ０Ｐ２）；当ｗＹ（ＩＰ１）＝ｗＹ（ＩＰ２）Ｊ￣ＷＮ（ＩＰ１）＝ＷＮ（ＩＰ２）时， 若ｗＴ（ＩＰ ）＞ＷＴＯｐ２），￣ＵｗＯＰ０＞Ｗ（ＩＰ２）；当ｗＹ（ＩＰ１）＝ｗｙ（ＩＰ２）， ＷＮ０Ｐ１）＝ｗｎ０Ｐ２），且ｗｒ（ＩＰ１）＝ｗｔ（ＩＰ２）时，若ｗ＿Ｈ（ＩＰ１）＞ ＾圭 ＷＨ（ＩＰ，），￣ｔＪｗ０Ｐ０＞Ｗ（ＩＰ２）。 根据以上一套计算权重的算法，对每一台提供服务的机 器都产生相应的权重值，以在匹配过程中使用。监控中心的 权重算法配合注册中心的匹配机制保证系统尽可能使用运 转良好，处理速度快，性能稳定的机器来应答请求，从而降 低系统平均处理用时，提高系统的处理效率，增强系统可用 性，缩短请求方等待时间，提升整体性能，使得用户有更好 的使用体验。 ２．４服务提供方／服务请求方 。 ． 。ｌ ；。 ｉ ｌ。 窖圭１ ８ ｅ 。 。ｉ ‘＿ 鞋长‘寰， ● ｉ ｅ’ 在本中间件中，服务提供方和请求方采用了简洁的设计 模式，计算处理主要由注册中心及监控中心完成。请求方与 提供方依托自定义协议向注册中心及监控中心发送信息，包 图７新旧系统效率对比 图７为新旧中间件针对相同简单长链请求时耗的测试 （下转第３８页） ·３３· Ｍｉｃｒｏｃｏｍｐｕｔｅｒ Ａｐｐｌｉｃａｔｉｏｎｓ Ｖｏ１．３２，Ｎｏ．７，２０１６ 基金项目 微型电脑应用２０１６年第３２卷第７期 ５ ３划与执行系统架构设计【Ｊ］．东南大学学报：（自然科学版）， ２０１２，４２（１）：ｌ８２－ｌ８５． 【３］Ｄａｎｇ Ｑ Ｖ，Ｎｉｅｌｓｅｎ Ｉ．Ｓｉｍｕｌｔａｎｅｏｕｓ ｓｃｈｅｄｕｌｉｎｇ ｏｆ ｍａ－ ｒｏｎｍｅｎｔ［Ｙ］．Ｊｏｕｒｎａｌ ｏｆ Ｏｐｔｉｍｉｚａｔｉｏｎ ｉｎ Ｉｎｄｕｓｔｒｉａｌ Ｅｎｇｉ— ｎｅｅｒｉｎｇ，２０１４，３７（６）：１３６－１４５． 轴 ∞［７］Ｎｉｅｌｓｅｎ Ｉ，Ｄａｎｇ Ｑ Ｖ，Ｎｉｅｌｓｅｎ Ｐ，ｅｔ ａ１．Ｓｃｈｅｄｕｌｉｎｇ ｏｆ ｍｏ— ｂｉｌｅ ｒｏｂｏｔｓ ｗｉｔｈ ｐｒｅｅｍｐｔｉｖｅ ｔａｓｋｓ［￣．Ａｄｖａｎｃｅｓ ｉｎ Ｉｎｔｅｌｌｉ— ｇｅｎｔ Ｓｙｓｔｅｍｓ＆Ｃｏｍｐｕｔｉｎｇ，２０ １ ４，２９（４）：ｌ ９—２７． ｃｈｉｎｅｓ ａｎｄ ｍｏｂｉｌｅ ｒｏｂｏｔｓ［Ｊ］．Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｉｎ Ｃｏｍｐｕｔ— ｅｒ＆Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅ，２０１３，３６（５）：ｌ】８－１２８． 【４］李诚，李爽，冯毅萍，等．基于时间Ｐｅｔｒｉ网和启发式搜索 的柔性制造系统调度算法［Ｊ］．上海交通大学学报，２０１５， ４９（５）：７０８·７ １３． 【８】赵金周，袁建新．基于远程柔性制造系统的物料分配实 验设计 ．开封大学学报，２０１０，２４（２）：９０—９３． ［９］沈博闻，于宁波，刘景泰．仓储物流机器人集群的智能 调度和路径规划［Ｊ】．智能系统学报，２０１４，９（６）：６５９—６６４． 【１０】Ｃｈｏｉ Ｊ Ｈ，Ｋｉｍ Ｊ Ｓ，Ｊｉｎ Ｈ Ｊ，ｅｔ ａ１．Ｍｕｌｔｉ·Ｏｂｊｅｃｔｉｖｅ Ｇｅｎｅｔｉｃ Ａｌｇｏｒｉｔｈｍ ｂａｓｅｄ ｏｎ Ｍｕｌｔｉ—Ｒｏｂｏｔ Ｐｏｓｉｔｉｏｎｓ ｆｏｒ Ｓｃｈｅｄｕｌｉｎｇ ［５］Ｒｏｈ Ｈ Ｋ，Ｋｉｍ Ｙ Ｄ．Ｄｕｅ－ｄａｔｅ ｂａｓｅｄ ｌｏａｄｉｎｇ ａｎｄ ｓｃｈｅｄｕｌ· ｉｎｇ ｍｅｔｈｏｄｓ ｆｏｒ ａ ｆｌｅｘｉｂｌｅ ｍａｎｕｆａｃｔｕｒｉｎｇ ｓｙｓｔｅｍ ｗｉｔｈ ａｎ ａｕｔｏｍａｔｉｃ ｔｏｏｌ ｔｒａｎｓｐｏｒｔｅｒ［Ｊ］．Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｊｏｕｒｎａｌ ｏｆ Ｐｒｏ— ｄｕｃｔｉｏｎ Ｒｅｓｅａｒｃｈ，２０１０，３５（１ １）：２９８９—３００４． Ｐｒｏｂｌｅｍｓ［Ｊ］．Ｊｏｕｒｎａｌ ｏｆ ｔｈｅ Ｋｏｒｅａｎ Ｓｏｃｉｅｔｙ ｆｏｒ Ｐｒｅｃｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｉｎｇ，２０ １ ４，３ １（８）：６８９－６９６． 【６］Ｚａｒｇｈａｍｉ Ｓ．Ｅｘａｃｔ Ｍｉｘｅｄ Ｉｎｔｅｇｅｒ Ｐｒｏｇｒａｍｍｉｎｇ ｆｏｒ Ｉｎｔｅ－ ｇｒａｔｅｄ Ｓｃｈｅｄｕｌｉｎｇ ａｎｄ Ｐｒｏｃｅｓｓ Ｐｌａｎｎｉｎｇ ｉｎ Ｆｌｅｘｉｂｌｅ Ｅｎｖｉ—Ｉ （上接第３３页） （收稿日期：２０ １ ６．０３．２８） 由实验结果可以看出，改进系统的吞吐量明显优于原系 统，而且相对于短链请求，长链请求的优势更明显。同时原 系统由于ＨＡＰｒｏｘｙ本身的压力，在链长增加的情况下吞吐 结果，从中可以看出随着链长的增加改进中间件相对于原始 中间件的优势越明显。如当服务链长为２Ｏ时，新系统平均 处理时间为４４７．２毫秒而原始系统则高达５１７．６毫秒，针对 量显著减少，而新系统在一定程度上缓解了这种压力，在应 对长链请求时也表现了很好的性能。 链长大于５的服务调用，新中间件的效率提高了１０％以上。 而产生这样改变的主要原因在于去中心化的设计思路，随着 系统的启动，当服务请求方获得了来自注册中心的通知后， ４总结 本文分析了目前流媒体云平台使用的传统负载均衡中 间件系统原理，提出了其在长链调用等工业界应用场景日渐 复杂过程中出现的实际问题，并且针对细分领域、结合流媒 再次进行服务调用时可以省去与中间件的交互，从而极大的 提高了通信效率 ３．２吞吐量测试 本实验在服务吞吐量方面对新型中间件与传统负载均 衡中间件进行了对比。由于系统吞吐量本身也受服务请求链 长的影响，因而在实验中设计了针对不同服务请求链长下新 旧中间件的吞吐量测试。 体云平台的特点，设计并实现了一种用以解决应用层ＲＰＣ 调用服务的基于ＳＯＡ构架的新型云平台服务管理中间件。 该设计实现改善了原本使用负载均衡中间件产生的系统性 能瓶颈，在长链调用中使得系统的吞吐量提升了近５倍。其 实验过程如下：采用ｈｔｔｐ ｌｏａｄ压力测试软件，模拟５０ 个客户端同时发起的１００００个服务请求，记录新旧中间件在 以下情况下的吞吐量；针对不同链长的服务调用进行测试， 分为链长２－４的短链服务组与链长为１０左右的长链服务组， 次，本中间件缩短了服务调用耗时，提高了系统效率，在长 链调用中时耗缩短了近１０％。因此，本中间件提供了一种真 正灵活高效，性能优越的流媒体云平台服务调用解决方案。 长、短链组分别进行９次测试，并记录每次测试的吞吐量； 将每组的九次实验结果排序，取排序结果第五位的数据作为 最终结果，以排除意外情况造成的偏差。 实验结果如下图８所示： 参考文献 ［１】 梁爽．基于ＳＯＡ的云计算框架模型的研宄与实现［Ｊ］． 计算机工程与应用，２０１ １，３５：９２—９４＋１４２ ｆ２１ Ｂａｕｄｅ Ｆ，Ｆｉｌａｌｉ Ｉ，Ｈｕｅｔ Ｆ，ｅｔ ａ１．ＥＳＢ ｆｅｄｅｒａｔｉｏｎ ｆｏｒ ｌａｒｇｅ－ｓｃａｌｅ ＳＯＡ［Ｃ］／／Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆｔｈｅ ２０１０ ＡＣＭ Ｓｙｍ —ｐｏｓｉｕｍ ｏｎ Ａｐｐｌｉｅｄ Ｃｏｍｐｕｔｉｎｇ．ＡＣＭ，２０ １ ０：２４５９－２４６６． ［３】 Ｙａｎｇ Ｘ，Ｚｈａｎｇ Ｈ．Ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ ａｎｄ ＳＯＡ ｃｏｎｖｅｒ— ｇｅｎｃｅ ｒｅｓｅａｒｃｈ［Ｃ］／／Ｃｏｍｐｕｔａｔｉｏｎａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ ａｎｄ Ｄｅ— ｓｉｇｎ（ＩＳＣＩＤ），２０ １ ２ Ｆｉｔｆｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｙｍｐｏｓｉｕｍ ｏｎ， ＩＥＥＥ，２０１２，１：３３０—３３５． ●原始 势改进 ［４】 杜矗，郭涛，陈俊杰．云环境下机群弹性负载均衡机制［Ｊ］ 计算机应用，２０１３，０３：８３０—８３３ 【５］ Ｚｈａ Ｊ，Ｗａｎｇ Ｊ，Ｈａｎ Ｒ，ｅｔ ａ１．Ｒｅｓｅａｒｃｈ ｏｎ ｌｏａｄ ｂａｌａｎｃｅ ｏｆ ｓｅｒｖｉｃｅ ｃａｐａｂｉｌｊｙ ｔｉｎｔｅｒａｃｔｉｏｎ ｍａｎａｇｅｍｅｎｔ［Ｃ］／／Ｂｒｏａｄｂａｎｄ Ｎｅｔｗｏｒｋ ａｎｄ Ｍｕｌｔｉｍｅｄｉａ Ｔｅｃｈｎｏｌｏｇｙ（ＩＣ—ＢＮＭＴ），２０ ｌ Ｏ ３ｒｄ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ．ＩＥＥＥ．２０ ｌ ０： 短撼 长燃 ２１２．２１７． 图８新旧系统吞吐量对比 ·３８· （收稿日期：２０ｌ６．０１．０２）
