系统架构:每秒1万次请求的系统要做成服务化拆分吗?
DAU(Daily Active User)日活跃用户数量
1 一体化架构的痛点
项目刚开始的时候,为了尽快搭建项目,尽快上线,一般都采用一体化架构,即单体应用。
- 开发简单直接,代码和项目集中式管理
- 只需要维护一个工程,节省维护系统运行的人力成本
- 排查问题的时候,只需要排查这个应用进程就可以了,目标性强
但是随着系统功能越来越复杂,开发团队越来越大,一体化架构的缺陷也就显露出来了
-
技术层面,数据库连接数可能成为系统的瓶颈
-
研发成本上,团队增加导致沟通成本呈指数级增长
《人月神话》中曾经提到:一个团队内部沟通成本和人员数量 n 有关,约等于 n(n-1)/2,也就是说随着团队人员的增加,沟通的成本呈指数级增长,一个 100 人的团队需要沟通的渠道大概是 100(100-1)/2 = 4950。为了减少沟通成本,我们一般会把团队拆分成若干个小团队,每个小团队 5~7 人负责一部分功能模块的开发和维护。
-
一体化架构对于系统的运维,每次修改上线都需要构建整个项目
2 如何使用微服务化解决痛点
将一体化架构进行拆分,按照业务横向拆分。各个拆分出来的子系统分别连接自己对应的数据库,解决数据库连接瓶颈;各个小团队负责自己单独的服务,降低大团队中沟通成本;某个子系统修改上线,降低对其他服务的影响。
但是,微服务化之后,原有单一系统被拆分成多个子服务,在开发和运维方面也会引入额外的问题。