架构设计我们一般遵循这样的流程：
（1）分析系统复杂性，明确和梳理出系统的复杂点。比如是业务逻辑复杂，还是性能瓶颈，是系统部署运维困难，还是可用性差等等。做好这一步，可以避免我们花费无用功，避免设计优化完毕却与实际情况大相径庭；对于多复杂点，可以排列优先级，规划和合并，同类同处理。
（2）设计主要方案和备选方案。一般我们可以设计出3--5个来，各自的差异性要大，技术选型也要大胆，不要局限性，从宏观层面去分析，而不是具体的分析什么接口什么数据这样的细节。
（3）评估和选择备选方案。能参与评选的，基本都是能够满足需要，可以达到目标的，区别在与是否满足上节说的 设计原则，所以这就要求我们从不同的维度去比较，比如：性能、可用性、成本、复杂度、安全性、可扩展性等等。比如几个常用的技术栈：nginx、es、mysql、redis、cache等。
（4）详细方案的设计。根据选择的方案，进一步的优化和细化，要接地气了，技术方案要具体的实现和对接，所以有个前缀要求就是在选型阶段只要要对相关技术选型有所了解，个别关键点要深入理解等。这一阶段甚至会出现一种情况，比如由于某些关键点在选型时的忽略，导致详细设计阶段发现问题，具体的实现又不可行，需要重新选择，所以在评估阶段需要博采众长，避免一家之言。分阶段，分步骤、分系统，依次降低复杂度，减少细节推翻方案的成本。
实战大于理论，好像也未必。毕竟还要好多靠ppt吃饭的，而且饭碗很香，哈哈。对于我们搞技术的来说，还是实战要大于理论，避免成为ppt架构师，深入的理解技术的细节和原理，会更有助于我们对技术的选型。
