从单体到Flink:一文读懂ldsports官网是多少架构的演变
2019-7-4 22:18 | 查看: 450| 评论: 0
01 传统ldsports官网是多少基础架构

如图1-1所示,传统单体ldsports官网是多少架构(Monolithic Architecture)最大的特点便是集中式ldsports官网是多少存储,企业内部可能有诸多的系统,例如Web业务系统、订单系统、CRM系统、ERP系统、监控系统等,这些系统的事务性ldsports官网是多少主要基于集中式的关系性ldsports官网是多少库(DBMS)实现存储,大多数将架构分为计算层和存储层。

存储层负责企业内系统的ldsports官网是多少访问,且具有最终ldsports官网是多少一致性保障。这些ldsports官网是多少反映了当前的业务状态,例如系统的订单交易量、网站的活跃用户数、每个用户的交易额变化等,所有的更新操作均需要借助于同一套ldsports官网是多少库实现。


▲图1-1 传统ldsports官网是多少结构

单体架构的初期效率很高,但是随着时间的推移,业务越来越多,系统逐渐变得很大,越来越难以维护和升级,ldsports官网是多少库是唯一的准确ldsports官网是多少源,每个应用都需要访问ldsports官网是多少库来获取对应的ldsports官网是多少,如果ldsports官网是多少库发生改变或者出现问题,则将对整个业务系统产生影响。

后来随着微服务架构(Microservices Architecture)的出现,企业开始逐渐采用微服务作为企业业务系统的架构体系。微服务架构的核心思想是,一个应用是由多个小的、相互独立的微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖。不同的服务能依据不同的业务需求,构建的不同的技术架构之上,能够聚焦在有限的业务功能。


▲图1-2 微服务架构

如图1-2所示,微服务架构将系统拆解成不同的独立服务模块,每个模块分别使用各自独立的ldsports官网是多少库,这种模式解决了业务系统拓展的问题,但是也带来了新的问题,那就是业务交易ldsports官网是多少过于分散在不同的系统中,很难将ldsports官网是多少进行集中化管理。

对于企业内部进行ldsports官网是多少分析或者ldsports官网是多少挖掘之类的应用,则需要通过从不同的ldsports官网是多少库中进行ldsports官网是多少抽取,将ldsports官网是多少从ldsports官网是多少库中周期性地同步到ldsports官网是多少仓库中,然后在ldsports官网是多少仓库中进行ldsports官网是多少的抽取、转换、加载(ETL),从而构建成不同的ldsports官网是多少集市和应用,提供给业务系统使用。

02 大ldsports官网是多少ldsports官网是多少架构

起初ldsports官网是多少仓库主要还是构建在关系型ldsports官网是多少库之上,例如Oracle、Mysql等ldsports官网是多少库,但是随着企业ldsports官网是多少量的增长,关系型ldsports官网是多少库已经无法支撑大规模ldsports官网是多少集的存储和分析,因此越来越多的企业开始选择基于Hadoop构建企业级大ldsports官网是多少平台。

同时众多Sql-On-Hadoop技术方案的提出,也让企业在Hadoop上构建不同类型的ldsports官网是多少应用变得简单而高效,例如通过使用Apache Hive进行ldsports官网是多少ETL处理,通过使用Apache Impala进行实时交互性查询等。

大ldsports官网是多少技术的兴起,让企业能够更加灵活高效地使用自己的业务ldsports官网是多少,从ldsports官网是多少中提取出更多重要的价值,并将ldsports官网是多少分析和挖掘出来的结果应用在企业的决策、营销、管理等应用领域。但不可避免的是,随着越来越多新技术的引入与使用,企业内部一套大ldsports官网是多少管理平台可能会借助众多开源技术组件实现。

例如在构建企业ldsports官网是多少仓库的过程中,ldsports官网是多少往往都是周期性的从业务系统中同步到大ldsports官网是多少平台,完成一系列ETL转换动作之后,最终形成ldsports官网是多少集市等应用。但是对于一些时间要求比较高的应用,例如实时报表统计,则必须有非常低的延时展示统计结果,为此业界提出一套Lambda架构方案来处理不同类型的ldsports官网是多少。

例图1-3所示,大ldsports官网是多少平台中包含批量计算的Batch Layer和实时计算的Speed Layer,通过在一套平台中将批计算和流计算整合在一起,例如使用Hadoop MapReduce进行批量ldsports官网是多少的处理,使用Apache Storm进行实时ldsports官网是多少的处理。

这种架构在一定程度上解决了不同计算类型的问题,但是带来的问题是框架太多会导致平台复杂度过高、运维成本高等。在一套资源管理平台中管理不同类型的计算框架使用也是非常困难的事情。总而言之,Lambda架构是构建大ldsports官网是多少应用程序的一种很有效的解决方案,但是还不是最完美的方案。


▲图1-3 大ldsports官网是多少Lambada架构

后来随着Apache Spark的分布式内存处理框架的出现,提出了将ldsports官网是多少切分成微批的处理模式进行流式ldsports官网是多少处理,从而能够在一套计算框架内完成批量计算和流式计算。

但因为Spark本身是基于批处理模式的原因,并不能完美且高效地处理原生的ldsports官网是多少流,因此对流式计算支持的相对较弱,可以说Spark的出现本质上是在一定程度上对Hadoop架构进行了一定的升级和优化。

03 有状态流计算架构

ldsports官网是多少产生的本质,其实是一条条真实存在的事件,前面提到的不同的架构其实都是在一定程度违背了这种本质,需要通过在一定时延的情况下对业务ldsports官网是多少进行处理,然后得到基于业务ldsports官网是多少统计的准确结果。

实际上,基于流式计算技术局限性,我们很难在ldsports官网是多少产生的过程中进行计算并直接产生统计结果,因为这不仅对系统有非常高的要求,还必须要满足高性能、高吞吐、低延时等众多目标。

而有状态流计算架构(如图1-4所示)的提出,从一定程度上满足了企业的这种需求,企业基于实时的流式ldsports官网是多少,维护所有计算过程的状态,所谓状态就是计算过程中产生的中间计算结果,每次计算新的ldsports官网是多少进入到流式系统中都是基于中间状态结果的基础上进行运算,最终产生正确的统计结果。

基于有状态计算的方式最大的优势是不需要将原始ldsports官网是多少重新从外部存储中拿出来,从而进行全量计算,因为这种计算方式的代价可能是非常高的。从另一个角度讲,用户无须通过调度和协调各种批量计算工具,从ldsports官网是多少仓库中获取ldsports官网是多少统计结果,然后再落地存储,这些操作全部都可以基于流式计算完成,可以极大地减轻系统对其他框架的依赖,减少ldsports官网是多少计算过程中的时间损耗以及硬件存储。


▲图1-4 有状态计算架构

如果计算的结果能保持一致,实时计算在很短的时间内统计出结果,批量计算则需要等待一定时间才能得出,相信大多数用户会更加倾向于选择使用有状态流进行大ldsports官网是多少处理。

04 为什么会是Flink

可以看出有状态流计算将会逐步成为企业作为构建ldsports官网是多少平台的架构模式,而目前从社区来看,能够满足的只有Apache Flink。Flink通过实现Google Dataflow流式计算模型实现了高吞吐、低延迟、高性能兼具实时流式计算框架。

同时Flink支持高度容错的状态管理,防止状态在计算过程中因为系统异常而出现丢失,Flink周期性地通过分布式快照技术Checkpoints实现状态的持久化维护,使得即使在系统停机或者异常的情况下都能计算出正确的结果。

Flink具有先进的架构理念、诸多的优秀特性,以及完善的编程接口,而Flink也在每一次的Release版本中,不断推出新的特性,例如Queryable State功能的提出,容许用户通过远程的方式直接获取流式计算任务的状态信息,ldsports官网是多少不需要落地ldsports官网是多少库就能直接从Flink流式应用中查询。对于实时交互式的查询业务可以直接从Flink的状态中查询最新的结果。

在未来,Flink将不仅作为实时流式处理的框架,更多的可能会成为一套实时的状态存储引擎,让更多的用户从有状态计算的技术中获益。


Flink的具体优势有以下几点。

1. 同时支持高吞吐、低延迟、高性能

Flink是目前开源社区中唯一一套集高吞吐、低延迟、高性能三者于一身的分布式流式ldsports官网是多少处理框架。像Apache Spark也只能兼顾高吞吐和高性能特性,主要因为在Spark Streaming流式计算中无法做到低延迟保障;而流式计算框架Apache Storm只能支持低延迟和高性能特性,但是无法满足高吞吐的要求。而满足高吞吐、低延迟、高性能这三个目标对分布式流式计算框架来说是非常重要的。

2. 支持事件时间(Event Time)概念

在流式计算领域中,窗口计算的地位举足轻重,但目前大多数框架窗口计算采用的都是系统时间(Process Time),也是事件传输到计算框架处理时,系统主机的当前时间。

Flink能够支持基于事件时间(Event Time)语义进行窗口计算,也就是使用事件产生的时间,这种基于事件驱动的机制使得事件即使乱序到达,流系统也能够计算出精确的结果,保持了事件原本产生时的时序性,尽可能避免网络传输或硬件系统的影响。

3. 支持有状态计算

Flink在1.4版本中实现了状态管理,所谓状态就是在流式计算过程中将算子的中间结果ldsports官网是多少保存在内存或者文件系统中,等下一个事件进入算子后可以从之前的状态中获取中间结果中计算当前的结果,从而无须每次都基于全部的原始ldsports官网是多少来统计结果,这种方式极大地提升了系统的性能,并降低了ldsports官网是多少计算过程的资源消耗。

对于ldsports官网是多少量大且运算逻辑非常复杂的流式计算场景,有状态计算发挥了非常重要的作用。

4. 支持高度灵活的窗口(Window)操作

在流处理应用中,ldsports官网是多少是连续不断的,需要通过窗口的方式对流ldsports官网是多少进行一定范围的聚合计算,例如统计在过去的1分钟内有多少用户点击某一网页,在这种情况下,我们必须定义一个窗口,用来收集最近一分钟内的ldsports官网是多少,并对这个窗口内的ldsports官网是多少进行再计算。

Flink将窗口划分为基于Time、Count、Session,以及Data-driven等类型的窗口操作,窗口可以用灵活的触发条件定制化来达到对复杂的流传输模式的支持,用户可以定义不同的窗口触发机制来满足不同的需求。

5. 基于轻量级分布式快照(Snapshot)实现的容错

Flink能够分布式运行在上千个节点上,将一个大型计算任务的流程拆解成小的计算过程,然后将tesk分布到并行节点上进行处理。在任务执行过程中,能够自动发现事件处理过程中的错误而导致ldsports官网是多少不一致的问题,比如:节点宕机、网路传输问题,或是由于用户因为升级或修复问题而导致计算服务重启等。

在这些情况下,通过基于分布式快照技术的Checkpoints,将执行过程中的状态信息进行持久化存储,一旦任务出现异常停止,Flink就能够从Checkpoints中进行任务的自动恢复,以确保ldsports官网是多少在处理过程中的一致性。

6. 基于JVM实现独立的内存管理

内存管理是所有计算框架需要重点考虑的部分,尤其对于计算量比较大的计算场景,ldsports官网是多少在内存中该如何进行管理显得至关重要。针对内存管理,Flink实现了自身管理内存的机制,尽可能减少JVM GC对系统的影响。

另外,Flink通过序列化/反序列化方法将所有的ldsports官网是多少对象转换成二进制在内存中存储,降低ldsports官网是多少存储的大小的同时,能够更加有效地对内存空间进行利用,降低GC带来的性能下降或任务异常的风险,因此Flink较其他分布式处理的框架会显得更加稳定,不会因为JVM GC等问题而影响整个应用的运行。

7. Save Points(保存点)

对于7*24小时运行的流式应用,ldsports官网是多少源源不断地接入,在一段时间内应用的终止有可能导致ldsports官网是多少的丢失或者计算结果的不准确,例如进行集群版本的升级、停机运维操作等操作。

值得一提的是,Flink通过Save Points技术将任务执行的快照保存在存储介质上,当任务重启的时候可以直接从事先保存的Save Points恢复原有的计算状态,使得任务继续按照停机之前的状态运行,Save Points技术可以让用户更好地管理和运维实时流式应用。
免责声明: 除非特别声明,文章均为网络转载,仅代表作者观点,与大ldsports官网是多少中国网无关。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。如果本文内容有侵犯你的权益,请发送信息至ab12-120@163.com,我们会及时删除

最新评论

关闭

站长推荐上一条 /1 下一条

?
?
在线客服①
在线客服②
大ldsports官网是多少行业交流
大ldsports官网是多少行业交流
大ldsports官网是多少求职招聘
大ldsports官网是多少求职招聘
服务电话:
15010106923
微信联系:
hb-0310
服务邮箱:
ab12-120@163.com
官方微信扫一扫
大ldsports官网是多少中国微信

QQ ??
冀ICP备15018178号-3

版权所有: Discuz! ? 2001-2013 大ldsports官网是多少.

GMT+8, 2019-9-5 18:58 , Processed in 0.050103 second(s), 24 queries .

返回顶部