架构设计第一步：识别复杂度
前文讲过，架构设计的本质目的是为了解决软件系统的复杂性,所以我们在设计架构时首先要的就是识别系统的复杂性。只有正确分析出软件系统的复杂性,后续的架构才不会偏离方向。如果一个系统的复杂性是功能耦合严重，逻辑复杂，而架构师设计出一个TPS达到50000/s的系统也没有任务意思，因为没有解决系统的问题。
架构的复杂性主要来源于”高性能”,”高可用”,”可扩展”等几个方面,但是架构师u判断架构复杂性时不能生搬硬套,认为任务架构都必需满足这三个方面。实际上大部分系统只要满足其中一个或者二个就可以了。如果真要同时满足这三个方面，要么就是之前的设计有问题,要么就是架构师判断失误。就算真要同时满足这三个方面，也要有优先级顺序。
如果运气不好接手了一个每个复杂度都有问题的系统，也是应该一个一个的去解决问题，而不是幻想一次架构重构解决所有的问题。如果同时要解决这么多问题,可能会面临以下问题。
- 要做的事情大多，反而无从下手
- 设计方案太复杂，落地时间太长
- 同一个方案要解决不同的复杂性，有的设计点是矛盾的。如要提高系统的高可用性，就要及时把数据及时写到硬盘上，而把写硬盘又会影响系统的高性能。
因为，正确的作法是把主要的复杂度问题都列出来，然后根据业务、技术和团队对问题进行优先级排序,优先解决最主要的复杂度问题。
对于按照复杂度优先级解决问题的方式，可能会存在这样一个担忧，解决了优先级靠前的复杂度问题后，解决后续复杂度的方案需要将之前已经落地的方案推倒重来。这个担忧只是存在理论上的可能性，因为由于软件系统的可塑性和易用性，对于同一个复杂度问题，软件系统设计方案可以有很多个，总是可以挑选一个性价比最高的方案。
即使真的要推倒重来，那么新的方案也必须同时解决之前已经解决的复杂度问题，一般来说要达到这种情况，都是依靠引进新的技术。例如，引入Hadoop可以同时解决高性能、高可用、大容量三个大数据处理的复杂度问题。
识别复杂度对架构师来说是一个挑战，因为复杂度并不是写在需求上面，需要架构师自己去判断。有经验的架构师能够一眼就看出来系统的复杂度在哪。但如果经验不足的话，那么就只能通过排除法了,从不同的角度进行逐一的进行分析了。
