为什么有些看起来很厉害的技术高手,设计的架构都很垃圾

本文探讨了技术高手设计的架构在应对高并发、高可用、高性能挑战时的演进过程。从active-standby高可用架构解决单点故障问题,到Master-Slave分布式计算系统降低单机负载,再到引入弹性计算资源调度机制确保资源均衡,最后建立分布式系统高容错机制,保证系统的稳定运行。文章总结了这一系列演进带来的优势,并展望了应对更高流量需求的未来挑战。
摘要由CSDN通过智能技术生成

一、写在前面

上篇文章《别光看NB的Github开源项目,你得参考他们去设计自己的架构!》,聊了一下商家数据平台第一个阶段的架构演进。通过离线与实时计算链路的拆分,离线计算的增量计算优化,实时计算的滑动时间窗口计算引擎,分库分表 + 读写分离,等各种技术手段,支撑住了百亿量级的数据量的存储与计算。

我们先来回看一下当时的那个架构图,然后继续聊聊这套架构在面对高并发、高可用、高性能等各种技术挑战下,应该如何继续演进。

在这里插入图片描述

二、active-standby高可用架构

大家看看上面的那个架构图,有没有发现里面有一个比较致命的问题?就是如何避免系统单点故障!

在最初的部署架构下,因为数据平台系统对CPU、内存、磁盘的要求很高,所以我们是单机部署在一台较高配置的虚拟机上的,16核CPU、64G内存、SSD固态硬盘。这个机器的配置是可以保证数据平台系统在高负载之下正常运行的。

但是如果仅仅是单机部署数据平台系统的话,会导致致命的单点故障问题,也就是如果单台机器上部署的数据平台系统宕机的话,就会立马导致整套系统崩溃。

因此在初期的阶段,我们对数据平台实现了active-standby的高可用架构,也就是一共部署在两台机器上,但是同一时间只有一台机器是会运行的,但是另外一台机器是备用的。处于active状态的系统会将滑动窗口计算引擎的计算状态和结果写入zookeeper中,作为元数据存储起来。

关于元数据基于zookeeper来存储,我们是充分参考了开源的Storm流式计算引擎的架构实现,因为Storm作为一个非常优秀的分布式流式计算系统,同样需要高并发的读写大量的计算中间状态和数据,他就是基于zookeeper来进行存储的。

本身zookeeper的读写性能非常的高,而且zookeeper集群自身就可以做到非常高的可用性

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值