使用Spark进行微服务的实时性能分析

作为一种灵活性极强的构架风格,时下微服务在各种开发项目中日益普及。在这种架构中,应用程序被按照功能分解成一组松耦合的服务,它们通过REST APIs相互协作。通过这个设计原则,开发团队可以快速地不断迭代各个独立的微服务。同时,基于这些特性,很多机构可以数倍地提升自己的部署能力。 

然而凡事都有两面性,当开发者从微服务架构获得敏捷时,观测整个系统的运行情况成为最大的痛点。如图1所示,多个服务工作联合对用户请求产生响应;在生产环境中,应用程序执行过程中端到端的视图对快速诊断并解决性能退化问题至关重要的,而应用中多达数十的微服务(每个还对应数百个实例)使得理解这点变得非常困难。信息是如何在服务中穿梭流动的?哪里是瓶颈点?如何确定用户体验的延迟是由网络还是调用链中的微服务引起? 

575057881

与此同时,在云环境下,企业对基于微服务应用的性能分析工具的需求与日俱增,因此IBM Research正在尝试构建基于平台的实时的性能分析工具,它的性质类似于自动缩放和负载平衡等服务。通过捕获和分析应用中微服务的网络通信,服务按非侵入式的方式进行。在云环境中,服务分析需要处理海量来自实时租户应用的通信追踪,进一步发现应用程序拓扑结构,跟踪当服务通过网络微服务时的单个请求等。由于需要运行批处理和实时分析应用,所以Spark被采用。 

575057881

图2所示,这里设置了一个简单实验来描述如何利用Spark进行操作分析。整体的环境是一个OpenStack云,一组基于微服务的应用程序运行在不同租户的网络中,还有一个小型Spark集群。在每个Nova计算主机上安装的软件网络tap来捕获通过租户网络内的网络数据包。从租户网络中捕获的Wire-data被投入Kafka bus。同时,在Spark应用中编写连接器,获取Kafka的包并对其进行实时分析。 

因此,Spark应用被编写试图来回答下列问题: 

1. 对终端用户的请求响应时,信息流是如何通过服务的?在IT Operational Analytics领域,这种分析操作通常被称为“事务跟踪”。 

2. 在给定时间窗中,应用中各种微服务之间的调用/被调用关系是什么? 

3. 在给定时间口中,应用中各种微服务的响应时间是多少? 

根据以上问题,这里开发了2个Spark应用程序:1个实时事务跟踪的应用程序和1个批量分析应用来生成应用的通信图和延迟统计。前者基于Spark流抽象,后者则是一组由Spark作业服务器管理的批处理作业。 

跟踪不同微服务之间的事务(或请求流)需要根据应用程序中不同微服务之间的请求-响应对创建因果关系。为了完全不受应用程序,这里将该应用当作一个黑盒。因此不妨认为应用程序中没有利用任何全局唯一请求标识符来跟踪跨微服务的用户请求。 

为了追踪上文所提的因果关系,这里采用了Aguilera等人在2003 SOSP论文中提出的一种对黑盒分布式系统进行性能分析的方法,并做细微的修改。对于同步的网络服务,论文提出了一种nesting algorithm,将分布式应用程序表示为一个图,各条边代表节点之间的相互作用。这个nesting algorithm会检查服务之间的调用时间戳,进一步推断其因果关系。简单地说,如果服务A调用服务B,而A在返回响应之前会和服务C通信,那么服务B呼叫C被认为是由A调用B引起的。通过分析一大组消息,这里可以得到服务间有统计性置信度的调用链,并消除可能性较小的选项。论文发表的原始算法旨在离线方式下操作大型的跟踪集。这个用例会修改该算法来操作数据包流的移动窗口,并慢慢逐步完善的拓扑结构推断。 

图3显示了事务跟踪应用中作业的部分工作流程。图4显示了在一个租户应用中的事务跟踪,由Spark应用推导。Packet流到达块中,以PCAP格式封装。个体流从Packet流中提取并按滑动窗口分组,即dstreams。在给定的时间窗口内,HTTP请求和请求响应通过对比标准的5个tuple 提取(src_ip、src_port、dest_ip、dest_port, protocol),组成下一个DStream,然后到nesting algorithm中实现的其余处理管道(未在图中显示)。事务跟踪应用输出结果会存储到时间序列数据存储区中(InfluxDB)。 

575057881

第二个Spark应用是一个标准批量分析应用程序,在给定的时间窗口产生服务调用图以及调用延迟统计。应用作为标准批处理作业被提交到Spark作业服务器。如图5所示,批量分析应用从InfluxDB分离出独立事务跟踪,并将每个独立事务跟踪转换为对的列表。列表被聚集成两个RDDS,一个包含顶点列表,而另一个为边列表。顶点列表根据顶点名称进一步解析。最后,应用程序的调用图在有向图中计算,以及图中每条边延迟时间的统计数据。该图是应用程序时间演变图的一个实例,表示给定时间内的状态。图6和7显示调用图和租户应用延迟时间的统计数据,作为该批次的分析作业输出。 

资料群在图片下方

575057881

575057881

575057881

通过Spark平台,各种不同类型的分析应用可以同时操作,如利用一个统一的大数据平台进行批量处理、流和图形处理。下一步则是研究系统的可扩展性方面,如通过增加主机线性提升数据提取速度,并同时处理成千上万租户的应用踪迹。后续会继续汇报这方面的进展情况。 

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,736评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,167评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,442评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,902评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,302评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,573评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,847评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,562评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,260评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,531评论 2 245
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,021评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,367评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,016评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,068评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,827评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,610评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,514评论 2 269

推荐阅读更多精彩内容