架构设计怎么做,设计原则及面试题详解？

导读
本文主要从架构设计的本质、架构设计原则、架构设计方法论三个方面来进行阐述，架构设计除了掌握技术框架、技术组件、技术原理性知识外，也需要系统性掌握架构基础知识，以架构设计原则为指导，掌握架构设计方法论，通过不断的优化和迭代，来实现更优秀的架构设计。
【架构设计怎么做,设计原则及面试题详解？】01
在了解架构本质之前先了解下架构的定义，百度百科对架构的定义：架构又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
从定义中我们提炼出几个关键字：组件、结构、关系。
架构是将软件组件按照一定结构连接起来的，软件组件怎么来找、用什么结构来连接、如何来连接，这些都是软件复杂度所带来的问题。
架构设计本质就是解决软件复杂度带来的问题，软件复杂度表现形式有很多种，比如业务复杂度、性能复杂度、可用性复杂度、可扩展性复杂度、安全复杂度等；任何一个系统都有它侧重解决的复杂度问题，理解每个架构方案背后需要真正解决的是软件复杂度的什么问题，是评判一个架构设计目的性的关键因素，这也是做架构设计中常提的系统约束条件。
业务复杂度体现的是如何来拆解业务，找到合适的软件元素和组件，按合适结构进行连接；性能复杂度体现的是找到软件元素，进行合适连接形成一定结构，达到高性能要求。比如说一个大型ERP系统，属于业务复杂度高的系统，你该如何去拆分它，拆分成一个个独立完备、具有明确业务边界的组件，这是做架构设计需要思考的。再比方说做一个秒杀系统，系统复杂度要求就是性能复杂度，怎么能扛住秒杀的洪峰，这是性能复杂度需要解决的问题。
02
软件开发和架构设计的区别
软件开发更多是面向确定性逻辑问题，依据自身对需求的理解进行实现，实现方式较为固定，流程化开发完成需求功能，实现最终目标。比方说实现订单接收的能力，分几步：参数验证、商品查询、库存预占、生成订单、扣减库存、修改订单状态、状态回传，业务逻辑较为固定，如果再加上编码规范以及框架约束，除了数据模型以及编码设计之外，其他方面涉及较少。
架构设计更多是面向不确定性问题，怎么将系统拆分成组件，怎么去识别是不是组件、组件和组件之间怎么进行连接，这些都是有很多种可能性的架构方案，解决一个软件复杂度问题方案，有方案A、方案B，甚至有方案C，应该用哪种，原因是什么，都是架构设计需要思考的问题。在多种方案之间如何来进行决策，如何判断自己选择的方案是合理的，当然决策能力也不是拍脑袋来决定的，它其实也需要一系列原则来进行指导，通过这些指导原则加上实际经验来决策最优方案。
03
架构设计三原则
谈到架构设计不得不说三个基本原则，作为架构设计过程中的参考，更好帮忙去做分析、做决策、做支持。
首先提到就是合适原则，一切不按实际场景出发的架构设计都是在耍流氓。比如你想买个车子，买贵觉得性价比不高，买便宜了觉得开起来不舒适，你最终会挑一个适合现在经济能力范围内又比较舒适的车子，这就是合适原则。以当前业务需求和非功能性需求为目标，匹配业务发展所处阶段，合理利用资源发挥最大价值（买车子需要匹配当前经济状态）；需要结合实际场景，合适的系统架构（我买车子只是为了代步，不能说我觉得跑车气派，我就买个跑车，这和业务实际场景不符合）；还需要和当前的业务规模以及最近1-2年的发展规划相互匹配（虽然我一次性付不起，但有稳定经济收入，我可以考虑贷款，分2年期。这样我既买到理想的车型，也不担心压力大）；新技术推出，势必是解决某一场景下的问题，但并不能解决所有问题，任何架构都要综合来看，结合合适原则综合选择。