前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >高可扩展性系统的设计

高可扩展性系统的设计

原创
作者头像
JavaEdge
修改于 2020-10-09 03:27:10
修改于 2020-10-09 03:27:10
7450
举报
文章被收录于专栏:JavaEdgeJavaEdge

文章收录在我的 GitHub 仓库,欢迎Star/fork: Java-Interview-Tutorial https://github.com/Wasabi1234/Java-Interview-Tutorial

架构设计的高可扩展性表示可通过加机器线性提高系统处理能力,承担更高流量和并发。

由于峰值的流量不可控,不可能在系统架构设计初期就考虑好机器数量以支持并发。

一般基于成本考虑,在业务平稳期,会预留30%~50%冗余机器应对运营活动或者推广可能带来的峰值流量,但当有突发事件时,流量可能瞬间提升几倍。莫过于明星公布恋情,大家都会到两人微博下互动,微博流量短时内迅速增长,微博信息流也短暂出现无法刷新消息,系统一时间不可用。

所以如何应对突发的流量呢?

最快的方式就是堆机器。不过能保证扩容三倍机器后,系统也能支撑三倍的流量吗?

系统瓶颈在哪里?

通过在单机系统中增加处理核心,可增加系统的并行处理能力,但当并行任务数较多时,系统会因为争抢资源而达到性能拐点,处理能力不升反降。

集群系统也是这样。不同的系统分层上可能存在一些“瓶颈”,这些瓶颈点制约着统的横向扩展能力。

比如系统流量1000 QPS,对DB也是1000 QPS。若流量增加10倍,虽然系统可通过扩容正常服务,DB却成瓶颈。或单机网络带宽50Mbps,若扩容到30台机器,前端负载均衡带宽就超过千兆带宽限制,也会成为瓶颈点。

所以系统中存在哪些服务会成为系统扩展的瓶颈呢?

无状态的服务和组件很易于扩展,但是MySQL这种存储服务有状态,较难扩展。因为向存储集群中增减机器时,涉及大量数据迁移,一般关系型DB都不支持。

DB、缓存、依赖的第三方、负载均衡、交换机带宽等都是系统扩展时需考虑因素。得清楚系统并发达到某量级后,哪个因素会成为系统瓶颈点,从而对症下药。

高可扩展性设计

拆分,把庞杂系统拆分成独立、单一职责的模块。

注意对不同类型模块,拆分原则不同。假如设计一个知乎,那么会有几个模块呢?至少5个模块。

用户:负责维护社区用户信息,注册,登陆等;

关系:用户之间关注、好友、拉黑等关系的维护;

内容:社区发的内容,就像朋友圈或者微博的内容;

评论、赞:用户可能会有的两种常规互动操作;

搜索:用户的搜索,内容的搜索。

部署方式遵照最简单三层部署架构

  1. 负载均衡负责请求的分发
  2. 应用服务器负责业务逻辑的处理
  3. 数据库负责数据的存储落地

所有模块的业务代码混合,数据也都存在一个库。

存储层的扩展性

无论是存储数据量,还是并发访问量,不同业务模块间量级相差很大。

比如知乎,关系数据量远大于用户数据量,但用户数据的访问量却远比关系数据大。所以假如存储目前的瓶颈点是容量,那只需针对关系模块的数据做拆分,而无需拆分用户模块数据。所以存储拆分首先考虑业务维度。

拆分后,这简单社区系统就有用户库、内容库、评论库、点赞库和关系库。这还能隔离故障,某库挂了不会影响到其它DB。

  • 按DB业务拆分后的部署架构

业务拆分一定程度提升了系统扩展性,但运行久后,单一业务DB在容量和并发请求量上仍会超过单机限制。需针对DB做二次拆分。

这次拆分按照数据特征做水平的拆分,比如给用户库增加俩节点,然后将用户数据拆分库。

水平拆分后,即可突破单机限制。不能随意地增加节点,因为一旦增加节点就需手动迁移数据。所以长远考虑最好一次增加足够节点,避免频繁扩容。

当DB按业务和数据维度拆分后,尽量不要使用事务。因为当一个事务同时更新不同DB,需使用二阶段提交,来协调所有DB要么全部更新成功,要么全部更新失败。

业务层扩展性

一般从三个维度考虑业务层的拆分方案

  • 业务纬度
  • 重要性纬度
  • 请求来源纬度

首先需把相同业务服务拆分成单独业务池,比方知乎,可按业务维度拆分成用户池、内容池、关系池、评论池、点赞池和搜索池。

每个业务依赖独自DB资源,不会依赖其它业务的。这样当某业务接口成为瓶颈时,只需扩展业务池,以及确认上下游依赖方,大大减少扩容复杂度。

还可根据业务接口重要程度,把业务分为核心池和非核心池。比如关系池:

  • 关注、取消关注接口相对重要,可放在核心池
  • 拉黑和取消拉黑的操作就相对不那么重要,可以放在非核心池里面

这可优先保证核心池性能,当整体流量上升时优先扩容核心池,降级部分非核心池的接口,从而保证整体系统的稳定性。

  • 关系池拆分示意图

还可以根据接入客户端类型做业务池拆分。比如服务于

  • 客户端接口的业务可定义为外网池
  • 小程序或者HTML5页面的业务可定义为H5池
  • 内部其它部门的业务可以定义为内网池。

总结

未做拆分的系统虽然可扩展性不强,但简单,无论开发、运维都无需很大精力。拆分后,需求开发需要横跨多系统多团队,排查问题也需要涉及多系统,运维每个子系统都需专人负责,所以大厂招聘也都要求沟通协作能力强。

参考

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
大厂如何打造可扩展的高并发系统?
高可扩展性是个设计指标:表示可通过加机器线性提高系统处理能力,承担更高流量和并发。
JavaEdge
2022/12/13
4330
系统设计:如何让系统容易扩展?
一个高可扩展性指标,表示可以通过增加机器的方式来线性提高系统的处理能力,从而承担更高的流量或者并发数。
王小明_HIT
2020/07/16
7520
架构师教你kill祖传石山代码重复/大量ifelse
很多 crud 工程师抱怨业务开发没有技术含量,什么设计模式、高并发都用不到,就是堆CRUD。每次面试被问到“讲讲常用设计模式?”,都只能把单例讲到精通,其他设计模式即使听过也只会简单说说,因为根本没实际用过。
JavaEdge
2020/10/25
1.1K0
深入理解高可扩展性得实现
在云计算体系架构中,高可扩展性(High Scalability)本质上是一种弹性工程能力,表现为系统通过智能化的资源编排机制,实现计算、存储、网络等基础资源与业务负载的动态匹配。其核心诉求始终如一:通过纵向扩容(Scale Up)或横向拓容(Scale Out)的灵活组合,构建具备非线性增长能力的数字基础设施,既能在流量脉冲场景下实现毫秒级资源弹性供给,又能在业务低峰期自动回收冗余资源,最终达成服务稳定性与成本效率的黄金平衡。
Michel_Rolle
2024/12/26
1.8K0
Dubbo定时任务时间轮(Time Wheel)算法详解
一种高效批量管理定时任务的调度模型。时间轮一般会实现成一个环形结构,类似一个时钟,分为很多槽,一个槽代表一个时间间隔,每个槽使用双向链表存储定时任务。指针周期性地跳动,跳动到一个槽位,就执行该槽位的定时任务。
JavaEdge
2020/10/14
3.8K0
Dubbo定时任务时间轮(Time Wheel)算法详解
深度解析Redis线程模型设计原理
所以虽然FEH是单线程运行,但通过I/O多路复用监听多个socket,不仅实现高性能的网络通信模型,又能和 Redis 服务器中其它同样单线程运行的模块交互,保证了Redis内部单线程模型的简洁设计。
JavaEdge
2020/09/01
9690
你们系统是怎么保证可扩展的
前面分享了高并发系统(你们系统是怎么保证高并发的)以及高可用系统(你们系统是怎么保证高可用的)的解决方案,今天我们再来看另一个很重要的模块,可扩展系统,系统的可扩展性同样是架构所需要重点考虑的一个设计点。
架构师修炼
2020/07/20
6350
你们系统是怎么保证可扩展的
突破Java面试(24)-Redis的持久化机制
Redis 对外提供数据访问服务时,使用的是常驻内存的数据。如果仅将数据存在内存,一旦宕机重启,数据全部丢失。
JavaEdge
2019/07/07
9120
突破Java面试(24)-Redis的持久化机制
DDD领域驱动设计实战-分层架构
整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何?
JavaEdge
2021/01/22
1.9K0
DDD领域驱动设计实战-分层架构
软件架构分层方法论
一般初创软件,为快速上线,几乎不考虑分层。但随业务越发复杂,就会导致逻辑复杂、模块相互依赖、代码扩展性差等各种问题。
JavaEdge
2020/09/25
8660
软件架构分层方法论
软件系统可扩展性的10个关键因素
作为可靠软件设计原则的一部分,这篇文章将重点关注可扩展性——这是构建健壮、面向未来的应用程序的最关键元素之一。
用户5166556
2023/09/07
1.7K0
软件系统可扩展性的10个关键因素
对业务系统的可扩展性设计思考
对于业务系统本身在架构设计的时候考虑扩展,原来更多的都是谈的IT基础技术架构本身的高可用性和高扩展性。而对于业务系统扩展性,简单来说就是如何灵活的应对需求的变化和扩展,如果减少在处理变更或扩展中代码不断产生的坏味道。
架构之家
2022/07/12
1.2K0
对业务系统的可扩展性设计思考
架构设计中的性能优化与可扩展性:如何找到平衡点?
这里先给大家推荐一篇实用的好文章:《从小改动到系统崩溃:一场“蝴蝶效应”般的Debug惊魂记!》 来自作者:bug菌
喵手
2024/12/02
2890
架构设计中的性能优化与可扩展性:如何找到平衡点?
高并发系统架构设计之微服务篇19: 微服务拆分
通过前面几个篇章的内容,你已经从数据库、缓存和消息队列的角度对自己的垂直电商系统在性能、可用性和扩展性上做了优化。现在,你的系统运行稳定,好评不断,每天高峰期的流量,已经达到了 10000/s 请求,DAU 也涨到了几十万。CEO 非常高兴,打算继续完善产品功能,以便进行新一轮的运营推广,争取在下个双十一可以将 DAU 冲击过百万。
Freedom123
2024/03/29
2890
高并发系统架构设计之微服务篇19: 微服务拆分
可扩展和弹性伸缩系统设计
软件系统是可以随着需求变化或者技术变化而不断扩展和迭代的,我们常见的各种软件系统比如操作系统、各种知名开源软件系统都是如此。而在这个过程中,我们如何通过较小的代价去扩展我们的系统,是我们要重点考虑的。
Allen.Wu
2023/02/15
2.1K0
聊聊分布式的可扩展性
团队,总会有人离开,总会有人加入。。。总会有一个leader,当服务器的数量增加的时候,业务增加的时候,总会进行相关的扩容或者缩容,那么这个团队的扩展性如何?
SRE运维实践
2019/07/08
1.7K0
什么是可扩展性-如何设计一个扩展性强的系统 一
在系统设计中,可扩展性是指系统使其性能和成本适应应用程序和系统处理需求的新变化的能力。
用户1418987
2024/09/06
4470
什么是可扩展性-如何设计一个扩展性强的系统 一
系统架构设计(3)-可扩展性
即使系统现在可靠,不代表将来一定可靠。发生退化的最常见原因是负载增加:并发用户从最初的10,000 增长到 100,000或系统目前处理数据量超出之前很多倍。
JavaEdge
2022/06/06
1K0
系统架构设计(3)-可扩展性
这可能是你见过最好的Redis主从复制原理
在Redis复制的基础上(不包括Redis Cluster或Redis Sentinel作为附加层提供的高可用功能),使用和配置主从复制非常简单,能使得从 Redis 服务器(下文称 slave)能精确得复制主 Redis 服务器(下文称 master)的内容。每次当 slave 和 master 之间的连接断开时, slave 会自动重连到 master 上,并且无论这期间 master 发生了什么, slave 都将尝试让自身成为 master 的精确副本。
JavaEdge
2020/09/06
1.1K0
这可能是你见过最好的Redis主从复制原理
【可扩展性】谷歌可扩展和弹性应用的模式
本文档介绍了一些用于创建具有弹性和可扩展性的应用程序的模式和实践,这是许多现代架构练习的两个基本目标。设计良好的应用程序会随着需求的增加和减少而上下扩展,并且具有足够的弹性以承受服务中断。构建和运行满足这些要求的应用程序需要仔细规划和设计。
架构师研究会
2022/09/26
2K0
推荐阅读
相关推荐
大厂如何打造可扩展的高并发系统?
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档