TOP

架构基本概念和架构本质(一)
2020-03-23 14:43:58 】 浏览:97次 本网站的内容取自网络,仅供学习参考之用,绝无侵犯任何人知识产权之意。如有侵犯请您及时与本人取得联系,万分感谢。
Tags:架构 基本 概念 本质

CSDN看到一篇介绍架构设计的博客,内容提纲挈领,内容丰富。依据原文整理,加上自己的理解和总结。 推荐给大家。点击原文可以查看出处。

原文链接:https://blog.csdn.net/hguisu/article/details/78258430

什么是架构和架构本质

在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。

Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?

想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构:

区分系统、模块、组件、框架和架构

S君: 区分系统、模块、组件、框架和架构

  • 系统(system)和子系统:有关联的个体,根据某种规则运行,共同完成独特的功能。子系统:系统的组成部分。

  • 模块(module)和组件(component):模块和组件都是系统的组成部分,只是从不同角度拆分系统而已。 从逻辑角度拆分得到的是模块,从物理角度拆分得到的是组件。 模块是为了实现职责分离, 组件是为了实现复用。

  • 框架:为了实现某个业界标准或完成特定基本任务的软件组件规范,按照规范提供所要求基础功能的软件产品。

  • 架构:顶层设计

系统与子系统

系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。

子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。

模块与组件

都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。

模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。

组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。

框架与架构

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

框架是规范,架构是结构。

架构重新定义

S君:架构是什么?架构师解决什么问题?

  • 架构是经过系统性地思考1, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架2。包括子系统, 模块, 组件. 以及他们之间协作关系3, 约束规范, 指导原则4。并由它来指导团队中的每个人思想层面上的一致。

  • 架构师能力要求:理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施。

我在这重新定义架构:软件架构指软件系统的顶层结构。

架构是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架。包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则。并由它来指导团队中的每个人思想层面上的一致。涉及四方面:

  • 系统性思考的合理决策:比如技术选型、解决方案等。

  • 明确的系统骨架:明确系统有哪些部分组成。

  • 系统协作关系:各个组成部分如何协作来实现业务请求。

  • 约束规范和指导原则:保证系统有序,高效、稳定运行。

因此架构师具备能力:理解业务,全局把控,选择合适技术,解决关键问题、指导研发落地实施。

架构的本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。

那什么样的系统要考虑做架构设计 技术不会平白无故的出和自驱动发展起来,而架构的发展和需求是基于业务的驱动。

架构设计完全是为了业务:

  1. 需求相对复杂。
  2. 非功能性需求在整个系统占据重要位置。
  3. 系统生命周期长,有扩展性需求。
  4. 系统基于组件或者集成的需要。
  5. 业务流程再造的需要。

架构分层和分类

S君:

业务架构是战略,应用架构是战术,技术架构是装备

  • 业务架构(俯视架构):包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

  • 应用架构(剖面架构): 承接业务架构和技术架构。应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。
    应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。

  • 技术架构:确定组成应用系统的实际运行组件(技术选型),这些运行组件之间的关系,以及部署到硬件的策略。
    技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握

  • 三者关系:
    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地

补充材料:节选《软件架构设计》 关注微信公众号回复【架构设计】获取相关书籍

  • 架构五视图:

  • 逻辑架构:逻辑架构关注功能,不仅包括用户可见的功能,还包括为实现用户功能而必须提供的“辅助功能模块”。

  • 开发架构:开发架构关注程序包,不仅包括要编写的源程序,还包括可以直接使用的第三方SDK 和现场框架、类库,以及开发的系统将运行于其上的系统软件或中间件。关注编译时刻的静态依赖关系。

  • 运行架构:运行架构关注进程、线程、对象等运行时概念,以及相关的并发,同步,通信等问题。运行架构关注运行期间各个单元的交互。

  • 物理架构:物理架构关注“目标程序及其依赖的运行库和系统软件”最终如何安装或部署到物理机器,以及如何部署机器和网络来配合软件系统的可靠性,可伸缩性等要求。

  • 数据架构:数据架构关注持久化数据的存储方案,不仅包括实体及实体关系的存储格式、还包括数据传递,数据复制,数据同步等策略。

架构分类可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构、数据架构

image

业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

业务架构(俯视架构):

包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

看看京东业务架构(网上分享图):

image

应用架构(剖面架构,也叫逻辑架构

请关注公众号获取更多资料


架构基本概念和架构本质(一) https://www.cppentry.com/bencandy.php?fid=97&id=281680

首页 上一页 1 2 3 4 下一页 尾页 1/4/4
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇springboot windows10风格 activi.. 下一篇图解Java设计模式之装饰者模式

评论

验 证 码:
表  情:
内  容: