架构设计的真正目的：解决复杂度，而非追求"高XX"或复制别人

整个软件技术发展史本质上是一部与”复杂度”斗争的历史，架构的出现也不例外，因此架构设计的主要目的可以归结为一句话：解决软件系统复杂度带来的问题。这条准则虽然简洁，但能实实在在地回答两类架构师最常见的困惑。对”新手”架构师来说，它能提供明确的下手方式：面对一堆需求不知从何入手时，答案是先识别系统复杂性到底体现在哪里，再针对这些复杂点设计架构，而不是把高性能、高可用、高扩展这些”高XX”逐一都做一遍——架构设计不需要面面俱到，只需要有针对性地解决已识别出的复杂点；面对业界不同公司给出差异很大的方案时，判断标准是去理解每个方案背后到底解决的是什么复杂点，再对比自己业务的复杂点是否相似，而不是简单地”参考名气大的那个”。对”老鸟”架构师来说，它能防止贪大求全的焦油坑：”我们的系统一定要做到每秒TPS 10万”——如果系统的复杂度根本不在性能这部分，做到10万毫无意义；”淘宝的架构是这么做的，我们也要这么做”——淘宝的架构是为了解决淘宝自己的业务复杂度而设计的，绝大多数业务的用户量根本达不到淘宝的量级，复制淘宝的架构等于复制一个自己用不上的解法；”Docker很流行，我们的架构应该把它用进来”——Docker只是为了解决资源重用和动态分配而设计的，如果系统的复杂度根本不在这方面，引入它没有任何意义。以一个学生管理系统为例：先逐项排查复杂度来源会发现，性能不复杂（访问频率低，MySQL+Nginx足够）、可扩展性不复杂（功能稳定）、安全性简单（做好ACL和账号密码管理即可）、成本无需关注，唯独存储可靠性有点复杂（学生数据一旦全部丢失只能人工逐条修复，代价太高，需要考虑机器故障和机房故障两类异常场景），于是这个系统真正值得投入架构设计精力的地方，就只有存储可靠性这一个点，而不是不分主次地把所有”高XX”都做一遍。