系统可扩展性思考

系统扩展的错觉

没有什么是加机器解决不了的,一台不行加两台。

这是我们工作中经常调侃的一句话,当我们系统遇到性能瓶颈时,第一直觉就是加机器,但是在实际实践中,加机器能解决问题吗?
我们一般说的加机器得到的性能提升称为横向扩展。
横向扩展(scale up),也叫水平扩展,指用更多的节点支撑更大量的请求。如果1台机器能够支撑1万TPS,那么两台机器能否支撑2万TPS?
横向扩展通常是为了提升吞吐量,响应时间一般要求不受吞吐量影响即可,无限提高吞吐量不能相应提升响应时间。

与横向扩展对应的是垂直扩展,针对一个节点进行升级,通常通过提升硬件实现。提高节点的单机能力或者改变数据存错结构、传输方式等方法,都可以提高响应时间。
横向扩展和垂直扩展可以一定程度上解释提高系统性能的原则,但是这个模型还有点粗糙。

什么是AKF扩展立方体

AFK扩展立方体(Scalability Cube)是《架构即未来》一书中提出的可扩展模型。这个理论把系统在架构上的扩展性按照三个维度进行划分,如下图所示。
在这里插入图片描述

X轴:服务/数据水平复制

通常称为水平扩展,通过复制实例,前端对流量进行负载均衡,以分摊整体压力为目的进行扩展。优点在于架构简单,实施速度快,研发成本低,只需通过负载均衡,保持无状态就非常容易达成。
一般在产品初期,开发团队成员不多,用户需求不确定的情况下,我们只需要通过单体架构实现系统即可。当用户访问量快速增长,系统性能出现瓶颈的时候,可以通过增加节点数量来应对,数据库层面可以通过读写分离进行扩展。

Y轴:根据职责/功能划分

根据服务或者资源扩展,也是我们从单体架构演进到微服务架构的思想。对业务进行微服务划分,优点在于故障隔离性好、快速部署、团队沟通效率高。挑战在于对工具环境依赖高,资源消耗多,运维复杂度高、一致性实现成本高等。
在第二阶段,用户快速增长,产品需求快速增加,我们可以根据业务对系统进行拆分,团队成员也相应进行划分,将不同模块的业务划分到各自的微服务中。

Z轴:按服务/数据优先级划分

根据查询或者计算结果进行划分。简单来说,就是分片的思想。当数据规模非常大的时候,可以通过分片降低整体的压力。挑战在于架构复杂,数据迁移复杂,成本较高。
在第三阶段,随着用户规模的快速扩大,数据库成了性能瓶颈。我们可以通过MQ削峰填谷,解决写的性能瓶颈,通过分布式缓存解决读的性能瓶颈。在数据库层面,可以进行水平拆分,通过引入数据库中间件屏蔽底层分表细节。

结论

AKF扩展立方体是一套通用的扩展性理论,它不仅可以应用到系统的架构扩展上,也可以应用到人员的组织架构扩展上甚至其他相关的工业领域。

当然并不是所有公司都需要同时在XYZ三个方向上进行扩展,每个方向上的扩展都有它的利弊,我们需要根据公司与业务实际场景进行权衡取舍,选择最合适的架构方案,切忌教条主义。更重要的是了解AKF这套模型的理论哲学。

By Ryan.ou

猜你喜欢

转载自blog.csdn.net/vipshop_fin_dev/article/details/120683357