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