流-MSA：简化物联网数据流处理的微服务架构

⃝可在www.sciencedirect.com上在线获取ScienceDirectICTExpress 5（2019）146www.elsevier.com/locate/ictestream-MSA：一种微服务康斯坦丁诺斯·策佩斯希腊Harokopio大学电信信息学系接收日期：2019年3月31日;接受日期：2019年在线发售2019年摘要物联网解决方案的广泛部署导致了大量从处理中产生价值的应用程序的出现产生的高频数据流。为了满足这些任意简单应用程序的时间要求，从业者通常采用单片方法。然而，对低成本和可重复使用的解决方案的需求已经使这些方法过时。本文通过讨论微服务架构（MSA）如何提供强大且低成本的解决方案来管理数据负载来解决这个问题实时要求。我们的动机是提供一种方法（流MSA），使这类应用程序的简单和有效的迁移到一个MSA的方法。c2019韩国通信与信息科学研究所（KICS）。出版社：Elsevier B.V.这是一个开放的访问CC BY-NC-ND许可证下的文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。关键词：微服务架构;数据流;可扩展性;云计算1. 介绍物联网解决方案的广泛部署引发了一类实时数据流处理的出现-ing应用程序，它依赖于在数据对象流上执行低成本操作的快节奏管道。 这些操作中的每一个都对数据对象执行一个基本操作，并将其推送到下一个。这些操作通常是小的数据转换，例如高阶函数或定制的低复杂度算法或简单的数据库操作[1]。通常，为了应对数据流速率，应用程序依赖于高端资源，这可能最终导致高基础设施成本和单片实现。为了解决这个问题，在过去的几年中，应用程序开发人员通常采用云计算技术，通过添加负载均衡器和缩放规则来实现应用程序的缩放。在云中，除了单体方法之外，还有两种架构方法来支持这些类型的数据管道：PaaS和微服务架构（MSA）。PaaS 解 决 方 案 通 常 是 一 个 托 管 的 数 据 流 平 台 ， 如Dataflow、Apache Spark或Kafka或Flink。云服务确保这些服务能够自主管理电子邮件地址：tserpes@hua.gr。同行评审由韩国通信和信息科学研究所（KICS）负责https://doi.org/10.1016/j.icte.2019.04.001应用程序的可用性和容错性。这些解决方案，无论多么可靠，通常都很昂贵，并且需要一些针对平台特性的开发工作。更合适的是MSA，它从两个方面降低了应用程序的执行成本：（a）它带来了最小的云基础设施成本，因为它可以将执行分配给多个按需调用的小型机器，而不是维护单个始终在线的机器;以及（b）它集成了支持功能，例如负载平衡，在应用逻辑中（应用相关度量与通用度量），以更有效的方式使资源成本适应应用需求[2]。这项工作的目标是：进一步阐述上述两点，为在类似应用中使用MSA（流MSA）通过对此类应用程序2. 微服务架构方法术语2405-9595/2019韩国通信与信息科学研究所（KICS）。 出版社：Els e vierB. V. 这是一个开放的访问CC BY-NC-ND许可证下的文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。···K. Tserpes/ICT Express 5（2019）146-149147到驻留在其自己的独立资源基础结构中的最小的、自包含的函数。微服务环境的一个基本特征是可复制性，即特定的微服务可以根据需要轻松复制多次，以实现可扩展性或简单的可重用性。这意味着微服务包含功能逻辑和提供环境，例如Web服务器以暴露RESTful API。将应用程序管道分解为微服务必须遵循一些通用规则，以便利用MSA概念。在下文中，将讨论应用程序功能分解、微服务交互和通信协议。有资格转变为微服务的功能通常是那些执行最小数据操作的功能，特别是在大数据流的情况下。当从函数式编程的角度来看流水线时，这些函数是高阶函数，通常是映射器、归约器和滤波器。此外，低复杂度的算法也需要被挑选出来作为自治服务[3]，以及数据库操作作为服务概念的精神[4]。这些资格标准的经验法则隔离最有可能被重用和/或必须缩放以支持实时需求的所有操作。因此，流MSA方法的微服务将被称为流MS。微服务交互需要依赖于轻量级标准通信协议，最好是websocket API [5] 。 这 样 的 API 比 标 准 的 基 于 HTTP 的RESTful API更适合于重复的通信模式，例如流处理，因为它允许避免每个通信的HTTP报头开销。为了确保微服务的可重用性和可扩展性，还必须依赖于单个对象级别的简单推/拉关系，而不是在微服务之间实现特定于应用程序的通信协议。关键的想法是简化这种管道的创建，忽略它们的复杂性（线性或循环），基本上通过选择和在配置方面，每个流MS需要定义其输入/输出端点，即流对象模型。它们是简单的输入/输出模块，不能适应复杂的场景，如多输出。通 过 为 负 载 均 衡 器 添 加 基 础 设 施 感 知 的 流 ms（instream-ms）来实现扩展。在流水线中，开发者将instream-ms放置在要产生的组件之前，并指示它如何（a）例如使用云提供商的API和目标流-ms的模板来产生新的流-ms当识别出潜在的瓶颈时，instream-ms被注入工作流在负载平衡策略方面，必须遵循动态方法，而不是静态方法。在静态负载平衡中，保留固定数量的操作处理器（或远程节点），系统相应地使用它们。的情况下在所讨论的方法中，应用程序可以基于适应于运行时条件的一些预定规则来缩放，并且特别是负载本身（例如，[6、7]）。3. 参考应用在本节中，我们研究了一个参考应用，该应用将使我们能够评估MSA和上述一般方法构成满足所讨论的应用类别中的实时数据处理要求的最适当方法的声明。特定应用的功能涉及处理包含来自移动设备的WiFi信号测量的数据对象的高频流。该应用程序的目标是估计和可视化的人群密度下的实时要求。在应用程序中，实时意味着任何进入管道的数据对象必须在60"内处理。应用程序的体系结构包括两个步骤操作：（a）收集超出本工作范围的数据;以及（b）将允许将WiFi测量转换为用户位置的数据处理。更详细地，引入到 管道是包含以下详细信息的对象数组：uid：唯一的用户ID，以MAC地址的形式表示，假设连接的移动设备总是传输相同的MAC地址。did：收集数据的设备的设备ID。需要此字段将收集信号的设备映射到特定位置（Lat、Lon对）。rssi：接收信号强度指示符，单位为dB，即WiFi信号强度。这需要估计检测到用户的半径，其中中心是收集器timestamp：数据生成的unix时间这种测量的每个阵列以60"的间隔被引入到流水线中，以便以包括以下细节的输出数据对象结束：uid：唯一的用户IDlat：用户位置的纬度lon：用户位置timestamp：用户位于这些lat，lon坐标基于流-MSA规则将处理操作分解为潜在的流- ms元素，导致涉及数据收集器和数据聚合器（其再次是现场组件并且在本工作的范围之外）的逻辑流水线，以及三个基本操作：过滤操作、称为“三边测量”的独立数据处理操作以及用于热图可视化的一些基本数据库操作。三边测量是计算最密集的过程，也是管道出现瓶颈的地方。因此，它是需要扩展以适应应用程序要求的元素。为了实现这一点，在流水线中在其之前引入负载平衡元件。由此产生的流水线如图所示。1.一、········148K Tserpes/ICT Express 5（2019）146-149图二、测 量 值在2.5 天内波动。图1.一、应 用 程序工作流。云计算部分是感兴趣的部分在实现方面，这些组件中的每一个都作为流MS运行。每个stream-ms由一个VM和一个NodeJS运行时组成，VM运行一个带有最低限度软件的Linux发行版，NodeJS运行时执行微服务的基本数据操作。相同的运行时公开和/或消费websocket API。关于哪个stream-ms公开API以及哪个使用API的一般规则如下：缩放的流MS消耗处理流中的固定组件的API。也就是说，它们实现了一个websocket客户端。一个微服务不应该暴露超过一个API，除非绝对必要。也就是说，它们最多实现一个websocket服务器。在管道中发生的处理在以下内容中描述：过滤：过滤器微服务基于它们的uid和时间戳对测量进行分组。如果一个组的大小小于3，则它将被过滤掉，数据速率平均以4/5的比率大大降低。原因是，对于每个uid，我们需要至少三个来自三个不同设备的WiFi测量。负载均衡：instream-ms在单个消息队列中缓冲测量。当Trilateratorstream-ms（处理器组件）请求数据对象时，Load Balancer删除队列中最旧的挂起对象，并将其推送到请求处理器。为了使instream-ms识别对新Trilaterator的需要，它周期性地监视其队列的长度如果队列大小增加的速率超过某个阈值，则负载均衡器主动请求部署新的处理器组件。相反如果速率正在降低，负载均衡器请求解除多余的处理器组件。这些请求通过底层云提供商的API实现新处理器完全运行所需的时间以及进入应用程序的测量值数量的波动都对缩放操作产生不利影响。Trilaterator：Trilaterator承担处理负载均衡器分配给它的测量结果的任务，并在给定的时间跨度内找到相应用户的大致位置。它部署在虚拟机上，根据最终用户分配的预算进行冷部署或热部署。三边测量算法要求从相等数量的已知点到所讨论的物体的至少三个距离，以便估计其位置。为了实现这一点，在三边测量的主要任务之前，该流 - ms 首 先 计 算 所 讨 论 的 用 户 与 通 过 WiFi 信 号 强 度（RSSI）收集测量结果的设备的距离。Heatmap ： Heatmapstream-ms 包 括 一 个 存 储 和 一 个websocket API，使其他微服务能够将用户位置持久化到其数据库中。它还为Heatmap可视化提供了客户端。4. 结果特定的数据速率平均为每分钟4648个数据对象，在2.5天的时间内在1和83017之间波动。 2）的情况。为了提高预算效率，为每个微服务的VM选择了GoogleCloud Compute中的f1-micro（1 vCPU，0.6 GB内存）实例类型。这是提供的最小计算机实例类型。每个部署的Trilaterator的吞吐量接近1000个数据对象。在高峰期，生成20个Trilaterator，最多可提供约18，000次测量（由于第一步中进行的过滤，速率降低）。f1-微型机可以执行-cute三边操作平均在56毫秒，导致在一个整体吞吐量几乎1071输入数据对象每分钟为每个三边。··K. Tserpes/ICT Express 5（2019）146-149149流水线的1′处理时间的目标实现了，系统勉强错过了目标3次。这发生在数据流中非常高的峰值紧接在非常低的峰值之后出现的情况下（例如，at 21/07@21：37）。在单个NodeJS运行时（单片实现）和自动缩放功能中的相同实现呈现了类似的行为，其中1例错过了1′目标。然而，最大的差异在于基础设施成本，在单片实施的情况下，基础设施成本高出15%以上，主要是由于预热方法。5. 结论本文讨论了如何使用MSA来满足处理高频数据流的短应用管道的实时要求[8]。由于需要处理物联网数据流，这类应用程序现在更加相关提供了一组用于将这样的应用程序转换为符合MSA的可伸缩管道的通用规则。这些规则，被称为最重要的是，与标准的单片实现相比，参考实现节省了成本。未来工作的一些考虑包括扩展的方法，以适应复杂的操作，erations之间的流MS，例如，多个输入/输出，或流MS操作之间的功能依赖性。此外，实现特定的DevOps自动化，部署，特别是使用容器，这似乎是一个适当的方法。利益冲突作者声明，本文中不存在利益冲突。引用[1] C. Richardson，微服务模式，Manning Publications，2017。[2] A. Makris，K. Tserpes，D. Anagnostopoulos，J. Altmann，用于最小化分布式键值存储中的get操作的平均响应时间的负载平衡，在：2017 IEEE第14届网络，传感和控制国际会议（ICNSC），2017年，pp. 263http://dx.doi.org/10.1109/ICNSC.2017.8000102[3] A. 瓦 尔 萨 米 斯 湾 Tserpes ， D. Zissis ， D. Anagnostopoulos ， T.Varvarigou，采用传统的机器学习算法进行大数据流分析：对象轨迹预测的案例，J.Syst.Softw。127（2017）249-257.[4] A.弗达角菲奇岛Zimmermann，W. 凯利，A. Barros，Migrat-ingenterprise legacy source code to microservices ： on multitenancy ，statefulness，and data consistency，IEEE Softw. 35（3）（2018）63[5] I. Fette，A. Melnikov，Websocket协议，RFC 6455，RFC编辑器（2011）。网址http://tools.ietf.org/html/rfc6455。[6] X.伦河，巴西-地Lin，H.邹，基于指数平滑预测的云计算平台动态负载均衡策略，载：云计算与智能系统（CCIS），2011 IEEE国际会议，IEEE，2011，pp. 220-224[7] Y. Fang ， F. Wang ， J. Ge ， A task scheduling algorithm based onloadbalancing in cloud computing ， in ： International Conference onWebInformationSystems and Mining，Springer，2010. 271-277[8] D. Kyriazis，A.梅尼赫塔斯湾Kousiouris，M.Boniface，T.库奇诺塔，K. Oberle，T. Voith，E. Oliveros，S.一种面向实时服务的基础设施，GSTF J。Comput. （JoC）1（2）（2018）.