知识卡片
复杂度问题应优先级排序解决而非全面开花
内容
大部分系统的核心复杂度只集中在高性能、高可用、可扩展性中的一到两个，若同时存在三个以上，往往说明此前设计有问题。面对多个复杂度应按业务、技术、团队排优先级，先解决最主要的一个，而非设计大而全方案——不同复杂度的解法有时互相矛盾（提升可用性要求落盘，又拖累性能）。案例：对标QQ体量设计的平台一开始上40多个子系统追求全面复杂度，落地一年后效率反而低到无法忍受，后来砍掉子系统数量，问题自然消失。
参考来源
- 位置：《从0开始学架构》第12章《10｜架构设计流程：识别复杂度》（源文件：_epub-src/OEBPS/Text/part0011_split_000.html、part0011_split_001.html）
- 结论依据：原文明确"如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误"，并以"亿级用户平台"案例说明"一开始就设计出了40多个子系统……上线后……开始设计的号称TPS 50000/秒的系统，实际TPS连500都不到"，后"合并很多子系统，将原来40多个子系统合并成不到20个子系统，整个系统才逐步稳定下来"。
- 原始内容：如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题……一开始就设计出了40多个子系统，然后投入大量人力开发了将近1年时间才跌跌撞撞地正式上线……开始设计的号称TPS 50000/秒的系统，实际TPS连500都不到……将原来40多个子系统合并成不到20个子系统，整个系统才逐步稳定下来。