关于架构设计的概念和本质-IT知识

　　在IT行业，大家对于架构肯定不陌生了。然而关于架构设计的概念和本质，还是有许多人没有真正的理解。本文就来带大家详解架构设计的概念和本质，内容包括认识架构、理解架构师岗位、架构的分类、架构的级别、应用架构的发展以及架构设计的注意事项。感兴趣的朋友可以一起来看看!

　　1、认识架构

　　架构的本质是经过系统性地思考，权衡利弊之后，在现有资源约束下的最合理决策，最终明确的系统骨架:，包括子系统, 模块, 组件。以及他们之间协作关系，约束规范,，指导原则。并由它来指导团队中的每个人思想层面上的一致。要全面理解架构设计的概念，还需要掌握以下一些知识点的理解。

　　(1)系统与子系统

　　系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。

　　(2)模块与组件

　　都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。模块就是从逻辑上将系统分解， 即分而治之， 将复杂的问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

　　(3)框架与架构

　　框架是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。框架是规范，架构是结构。软件架构指软件系统的顶层结构。

　　2、理解架构师岗位

　　系统架构师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。因此，作为主导系统全局分析设计和实施、负责软件架构和关键技术的决策者，架构师人才需求缺口大，薪资待遇高。一般来讲，架构师的主要工作内容是领导与协调整个项目中的技术活动，然后推动主要的技术决策，并最终表达为软件构架，接着确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”。同时还需要理解、评价并接收系统需求。总的来讲，一个合格的架构师需要做到理解业务，全局把控，选择合适的技术，解决关键问题、指导研发落地实施。

　　3、架构的分类

　　(1)业务架构

　　包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

　　(2)应用架构

　　硬件到应用的抽象，包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓的应用就是各个逻辑模块或者子系统。

　　(3)数据架构

　　数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

　　(4)代码架构

　　子系统代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

　　(5)技术架构

　　确定组成应用系统的实际运行组件，这些运行组件之间的关系，以及部署到硬件的策略。技术架构主要考虑系统的非功能性特征，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这也是架构设计工作中最为困难的工作。

　　(6)总结

　　架构分类可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构。业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另一方面影响技术选型。熟悉业务，形成业务架构，根据业务架构，做出相应的应用架构，最后技术架构落地实施。如何针对当前需求，选择合适的应用架构，如何面向未来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都需要深入思考的问题。

　　4、架构的级别

　　架构的级别分别是系统级、应用级、模块级和代码级。系统级即整个系统内各部分的关系以及如何治理分层;应用级即单个应用的整体架构，及其与系统内单个应用的关系等;模块级即应用内部的模块架构，如代码的模块化、数据和状态的管理等;代码级即从代码级别保障架构实施。

　　5、应用架构的发展

　　从本质上来看，业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。架构发展路程，即从单体应用到分布式应用服务化，最后到微服务。

　　6、架构设计的注意事项

　　(1)业务开发人员也需要关注架构设计

　　架构的再好，最终还是需要代码来落地，并且组织越大这个落地的难度越大。不单单是系统架构，每个解决方案每个项目也有自己的架构，如分层、设计模式等。如果每一块砖瓦不够坚固，那么整个系统还是会有崩塌的风险。

　　(2)架构设计并不是一开始就很完美

　　世上没有最好的架构，只有最合适的架构,不要企图一步到位。我们需要的不是一下子造出一辆汽车，而是从单轮车→自行车→摩托车，最后再到汽车。想象一下两年后才能造出的产品，当初市场还存在吗?

　　(3)不要为虚无的未来而过度设计

　　在创业公司初期，业务场景和需求边界很难把握，产品需要快速迭代和变现，需求频繁更新，这个时候需要的是快速实现。不要过多考虑未来的扩展，说不定功能做完，效果不好就无用了。如果业务模式和应用场景边界都已经比较清晰，是应该适当的考虑未来的扩展性设计。

　　(4)架构技术是为业务而存在的

　　不要为了技术而技术，在技术选型和架构设计中，脱离网站业务发展的实际，一味追求时髦的新技术，可能会将技术发展引入崎岖小道，架构之路越走越难。考虑实现成本、时间、人员等各方面都要综合考虑，理想与现实需要折中。

　　以上内容为大家介绍了关于架构设计的概念和本质，本文由多测师亲自撰写，希望对大家有所帮助。了解更多IT相关知识：https://www.duoceshi.com/xwzx-hydt/