关于分布式系统:BI系统的分布式部署原理和技术实现

3次阅读

共计 1882 个字符，预计需要花费 5 分钟才能阅读完成。

对于“分布式系统”的定义，咱们先看下书中是怎么说的。《分布式系统原理和范型》一书中是这样定义分布式系统的：“分布式系统是若干独立计算机的汇合，这些计算机对于用户来说就像是单个相干零碎”。
对于这个定义，咱们直观的感触就是：
首先，这种零碎相对来说很厉害，由好几台主机组成。以谷歌、亚马逊等服务商而言，他们的数据中心都由上万台主机撑持起来的。
其次，尽管很它很厉害，但对于外人来说，是感觉不到这些主机的存在。也就是说，咱们只看到是一个零碎在运作。以最近的“亚马逊 S3 宕机事件”为例，平时，咱们压根不晓得亚马逊所提供的服务背地是由多少台主机组成，然而等到 S3 宕机才晓得，这货曾经是占了互联网世界的半壁江山了。
从过程角度看，两个程序别离运行在两个台主机的过程上，它们相互协作最终实现同一个服务（或者性能），那么实践上这两个程序所组成的零碎，也能够称作是“分布式系统”。
当然，这个两个程序能够是不同的程序，也能够是雷同的程序。如果是雷同的程序，咱们又能够称之为“集群”。所谓集群，就是将雷同的程序，通过一直横向扩大，来进步服务能力的形式。
举一个生存中的例子来阐明：
小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。起初客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，两个厨师的关系是集群。
为了让厨师分心炒菜，把菜做到极致，再请了个配菜师负责切菜，备菜，备料 …，厨师和配菜师的关系是分布式。
一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。
一个配菜师因故销假了，然而其余的配菜师还是该啥就干啥，只是没销假的配菜师工作平均的加量了，但他们的工作和职责是不变的，这是集群。
店里生意很好，当店长接到订单后，看哪个厨师活儿不重，就将新的订单分给谁，这就是负载平衡。
集群：多集体在一起做同样的事。
分布式：多集体在一起做不同的事。
负载平衡：决定将工作以某种规定分给谁做。

理解了什么是分布式之后，为什么要应用散布部署呢；
首先分布式部署长处很显著，次要体现在上面 4 个方面：
零碎可用性晋升
传统的集中式计算或集中式存储在遇见单点故障时很容易造成整个服务不可用，分布式下的服务体系，单台机器有故障，不致于造成整个服务不可用。
零碎并发能力晋升
比方双 11 流动，平时订单少 50 台机器就够了，到了 11 订单量剧增，服务器减少到 100 台，每台机器之间互相独立，互不影响。
零碎容错能力晋升

同一组服务别离部署在北京上海杭州，杭州的机房突发断电或者火灾，杭州机房的流量会被主动散发到北京和上海的机房，不影响用户应用。
低提早
参考上一个图，北京的用户申请主动散发到北京，上海的用户申请被散发到上海，服务器会依据用户的 IP 抉择间隔本人最近的机房，升高网络提早。
同样分布式部署带来益处的同时也会有一些毛病，只有是上面 3 个方面：
分布式服务依赖网络
服务器间通信依赖网络，不牢靠网络包含网络延时，丢包、中断、异步，一个残缺的服务申请依赖一连串服务调用，任意一个服务节点网络呈现问题，都可能造成本次申请失败。
保护老本高
传统单体式服务只须要保护一个站点就能够。
分布式服务零碎被拆分成若干个小服务，服务从 1 变为几十个上百个服务后，减少运维老本。

一致性，可用性，分区容错性无奈同时满足
这个是最次要的，这三种个性就是平时说的 CAP 定理，在分布式系统中，这三种个性最多只能满足两种，无奈同时满足，须要依据理论状况去调整就义掉其中哪个。

随着数据的爆炸性增长，BI 零碎须要解决的数据越来越多，动辄 TB 级，甚至 PB 级，于是服务器宕机，反应迟钝，查问迟缓等各种性能问题接踵而来，BI 零碎的用户，心里几乎又苦又难~~~

各路 BI 厂商也意识到这些问题，纷纷推出各种解决方案。

这里提供一种应用分布式部署解决方案。
架构图如下：

那么分布式部署呢，次要是对 ReportWorker，CotWorker，DashboardWorker 组件进行横向扩大，这几个组件次要是负责仪表板和报表运算的组件，能够部署多个以提供零碎的计算性能。
为了升高用户部署老本，提供了在线的近程部署形式，UI 界面化操作，能够在线增加节点，近程为每个节点部署须要的组件，以及对节点组件进行在线启停，进一步升高用户部署老本。

同时也能够在线的运维治理和系统诊断性能，能够查看系统资源耗费，系统日志下载，不便对 BI 零碎进行运维治理，升高用户的运维老本。
大家如果感兴趣欢送拜访各种在线 demo, 领会 BI 工具为数据可视化带来的便当：https://www.grapecity.com.cn/…

正文完