识别复杂度是架构设计第一步：判断错了方向，越努力错得越离谱

架构设计流程的第一步是识别复杂度，这一步之所以是第一步而不是随便哪一步，是因为一旦对系统复杂性的判断本身就错了，后续无论方案设计得多精美、多先进，都是在南辕北辙——例如一个系统真正的复杂度是业务逻辑耦合严重，架构师却设计出TPS达到50000/秒的高性能架构，性能指标再漂亮也没有意义，因为没有解决真正的问题；这类方向性错误还有个反直觉的特点：方案做得越完善、投入的精力越多，偏离真实需求的程度反而越严重，因为南辕的马车跑得越快离目的地就越远。识别复杂度时还有一个常被误解的地方：不能预设架构必须同时满足高性能、高可用、可扩展这三方面要求——现实中大部分场景复杂度只集中在其中一个维度，少数场景涉及两个，真正需要同时解决三个或以上维度的情况极少见，一旦真的遇到这种情况，要么说明之前的系统设计本身有问题、欠了债，要么是架构师的判断出了偏差；即使确实需要同时应对多个复杂度，也必须先排出优先级，逐个解决，而不是妄想一次架构重构就把所有问题一并解决——”亿级用户平台”的失败案例正是反面教材：一开始就对标腾讯QQ的量级做了40多个子系统的过度设计，结果运维效率低下、开发协同困难、故障定位困难、实际TPS连宣称目标的百分之一都不到，最后接手团队花了两年时间把40多个子系统合并到不到20个才逐步稳定，而且这个团队的做法是先解决子系统数量过多这一个最紧迫的复杂度（换来开发效率提升、小故障基本消失），再在此基础上叠加异地多活方案，而不是想一步到位。有人会担心按优先级顺序解决复杂度，会不会导致后面解决新复杂度时把已经落地的方案推倒重来——这种担忧在理论上成立，但现实中很少发生，因为同一个复杂度问题往往存在多种可选方案，总能挑出综合性价比最高的那个；即便真的需要推倒重来，新方案也必须能同时覆盖已经解决的复杂度（这种理想情况通常只能靠引入新技术实现，例如Hadoop能同时解决大数据处理里高可用、高性能、大容量三个复杂度）。