逻辑架构和物理架构

在实际开发工作中,我们经常听到“架构设计”和“架构师”这样的名词,它并不新鲜和神秘,但是却很少有人对“架构”有全面的了解和认识,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了实践中对架构的一些理解,希望能够补充很多人对此认识上的不足,纠正一些误解。

  • 架构的分类

对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。

这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。我们通常会重点关注“逻辑架构”和“物理架构”。

逻辑架构:逻辑架构关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

开发架构:开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。

运行架构:顾名思义,更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题,比较常见的“线程同步”问题、死锁问题、对象创建和销毁(生命周期管理)问题等等。开发架构,更关注的是飞机起飞之前的一些准备工作,在静止状态下就能规划好做好的,而运行架构,更多考虑的是飞机起飞之后可能发生的一些问题。

物理架构:物理架构,更关注的系统、网络、服务器等基础设施。例如:如何通过服务器部署和配置网络环境,来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子,如何通过设计基础设施的架构,来保障网站能支持同时10W人在线、7*24小时提供服务,当超过10W人或者低于10W人在线时,可以很方便的调整部署架构来支撑。

数据架构:数据架构,更关注的是数据持久化和存储层面的问题,也可能会包括数据的分布、复制、同步等问题。更贴切来讲,如何选择需要的关系型数据库、流行的NOSQL,如何保障数据存储层面的性能、高可用性、灾备等等。很多时候,和物理架构是有紧密联系的,但它更关注数据存储层面的,物理架构更关注整个基础设施部署层面。

上面讲了那么多,相信国内很少有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中,架构大致分为两种:软件架构、系统架构。前三种视图,可以归纳为软件架构,而后两种架构,则归为系统架构。这也比较符合国内大部分中小型互联网公司的分工和布局。

根据应用特性的不同,关注侧重点可能不同。例如,某些门户类的互联网应用,读多写少而且业务相对比较简单,则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用,例如电商这类大规模交易型的应用,对每个层面和每个环节都会比较关注。对于业务型的系统,例如一些生产型企业使用的ERP,或者仅供企业内部使用的一些MIS、OA应用,通常更关注功能和复杂的业务和实现、扩展,而很少会对性能等方面又太多要求,这类应用则更关注纯软件架构层面。这里,不展开做具体讨论。

  • 架构设计到底是什么

在长期的技术招聘面试中,我发现在很多人眼中,架构就是分层,架构设计就是“三层架构”(或者四层、五层...反正分层越多就说明项目越复杂而且架构就越牛),或许是受到诸如PetShop之类的示例项目的影响,这里暂时不去追究原因了,先纠正很多人的一些误解吧。先说一下笔者的理解:

架构就、是实用而且优雅的设计,它不在于分多少层,或者应用了多少种设计模式/架构模式。它应该是以满足实现用户需求为前提,以开发人员普遍可接受为根本的,而且要符合系统特性和业务发展需要的,从软件设计的角度,能够达到层次和结构清晰、可维护、可重用、可扩展...就非常优秀了,无需刻意去纠结分了多少层,是否使用了什么模式等。以面向对象为例,基本目标是“高内聚、低耦合”,为此我们可能会遵循一些常见的设计原则(例如经典的SOLID设计原则)。最后纠正一点,通常我们所说的模式,其实又分为很多种,并不是仅仅指的是“设计模式”。它通常包括:企业架构模式、设计模式、SOA模式、企业集成模式等等。

强调一下,架构要讲求“实用”,而且开发人员普遍可接受,否则再“优雅”的设计,都会沦为高成本的“花架子”,生搬硬套只会让项目“流产”。

 

  • 关于Tier和Layer

笔者曾多次在一些技术社区和论坛看到一些关于TierLayer的争论,众说纷纭。其实最容易被广泛认可和接受的理解就是:Tier通常指的是物理上的分层,由执行同样功能的一台(或者一组)服务器定义。而Layer通常指的是逻辑上的分层,对于代码的组织,例如:我们通常提到的“业务逻辑层,表现层,数据访问层”等等。

Tier指代码运行的位置,多个Layer可以运行在同一个Tier上的,不同的Layer也可以运行在不同的Tier上,当然,前提是应用程序本身支持这种架构。以J2EE和.NET平台为例,大多数时候,不同的Layer之间都是直接通过DLL或者JAR包引用来完成调用的(例如:业务逻辑层需要引用数据访问层),这样部署的时候,也只能将多个Layer同时部署在一台服务器上。相反,不同的Layer之间如果是通过RPC的方式来实现通信调用的,部署的时候,便可以将不同的Layer部署在不同的服务器上面,这也是很常见的解耦设计。

如下图所示:

  • 逻辑分层和物理分层的好处

逻辑分层的好处:

  1. 代码组织更清晰
  2. 更易于维护
  3. 更好的代码重用性
  4. 更好的团队开发体验性
  5. 更高的代码清晰度

物理分层的好处:

 

  1. 性能
  2. 可伸缩性
  3. 容错性
  4. 安全性
  • 架构师的分类

架构师往往是很多开发人员向往的职业,它并不神秘,也不是像很多人想象中的那样(画一下PPT或者UML草图,然后交给程序员们去实现,然后自己就自由了)。国内很多公司,是没有架构师这种岗位定义的,通常是由技术优秀和经验比较丰富的开发人员担任,身兼多职的情况也并不少见(很多人是身兼主管、系统分析师、项目经理、架构师、核心开发人员...)。值得纠正的就是,架构师和系统分析师不同,系统分析师更侧重在项目早期的需求分析。而架构师,一般贯穿整个软件开发周期,与项目经理也是相辅相成的。微软对于架构师,又分为:软件架构师、系统架构师、解决方案架构师、企业架构师等。而其它一些厂商,可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师......大家不必对这些概念太纠结。按照笔者的理解,国内大互联网公司里,架构师一般只会分2-3个方向:软件架构师和系统架构师(有些企业叫运维架构师),有些企业对于比较资深DBA而且懂整个系统架构的,还会分出所谓的“数据架构师”。至于具体Title,大可不必纠结,只需在知晓了大致发展定位,然后朝该方向努力即可。对于程序员而言,先写出高质量代码,在实战中逐步提升自己设计思维即可。

限于笔者水平和理解有限,文中全部文字和描述等全凭笔者记忆写出,难免出现错误,敬请热心的读者及时批评和指正。

由于时间有限,部分图片笔者画的比较粗糙,也请读者谅解。

时间: 2024-10-27 11:08:48

逻辑架构和物理架构的相关文章

分布式架构之--逻辑架构与物理架构

原文:http://blog.csdn.net/dinglang_2009/article/details/38636151?utm_source=tuicool 在现实开发过程和工作中,我们经常听到“架构设计”和“架构师”这样的名词,它并不神秘,但是却很少有人对“架构”有全面的了解和认识,更谈不上掌握了.事实上,也只有极少数人能成为或者被冠以“架构师”这样的title.为此,笔者总结了实践中对架构的一些理解,希望能够补充很多人对此认识上的不足,纠正一些误解. 架构的分类 对于“架构”来讲,理论

微软商业智能解决方案的物理架构

一.物理基础结构 在开发BI项目之前,需要考虑关键服务器的分配和放置,还要考虑开发.测试和生产环境中安装的服务.虽然,MSSqlService2008将全部BI组件 安装在一台物理服务器上惊醒评估或开发,但在生产环境下很少这样做. 1.1 创建准确的基线调查 *物理服务器名称,实际位置,所有网络接口卡的IP地址,域成员. *每台物理服务器的操作系统配置,操作系统的版本.安装的服务包.管理员登录凭证.安装的核心操作系统服务,生效的组策略对象设置. *每台物理服务器上安装的逻辑服务器和服务. *开发

逻辑架构、体系架构、整体架构、功能架构

1.(逻辑本身跟物理是对应的,逻辑架构前面还缺少一个定语,比如部署逻辑架构,偏向于系统逻辑部署,与物理部署架构关联:)即部署逻辑架构等同于网络拓扑2.(系统逻辑架构,则更偏向于系统的功能流转,与功能架构关联 )即系统逻辑架构等同于应用架构.业务架构3.(体系架构和总体架构一直认为是一个总括的名词,它应该由系统定位.功能.技术.逻辑部署.物理部署等等专注于某一方面架构共同组成 )即体系架=整体架构=设计架构,不同叫法而已.

系统架构师-基础到企业应用架构-企业应用架构

一.上篇回顾 我们先来回顾下上篇讲解的内容,我们前面的几节分别讲述了,业务逻辑层.数据访问层.服务层.表现层,我们了解了这些分层的职责和分层之间的大概的关联 关系,本篇可能主要是简单的介绍下企业应用的几类模式,结合这几个分层直接的交互来完成系统功能的构建.我们还是先对我们学习的四个分层的职责和功能做个大 概的回顾,我们先来看看下图来回顾下我们讲述的内容. 我想通过上图,大家能回忆起我们讲述的相关内容,然后整理好自己的思路,我们本文将会针对这几个分层进行相应的模式的讲解,并且会结合实例来说明企业应

数据库学习之--Oracle 架构与MySQL架构对比

数据库学习之--Oracle 架构与MySQL架构对比 一.Oracle .MySQL应用对比 如果要说明三者的区别,首先就要从历史入手. Oracle:中文译作甲骨文,这是一家传奇的公司,有一个传奇的大老板Larry Ellision. Ellision 32岁还一事无成,读了三个大学,没得到一个学位文凭,换了十几家公司,老婆也离他而去.开始创业时只有1200美元,却使得Oracle公司连续12年销售额每年翻一番. Oracle成立于1977年,早期的理论基础,反而来自于一篇IBM的论文<A

架构设计深入学习02--概念架构与细化架构

胜兵先胜而后求战,败兵先战而后求胜—<孙子兵法>. 这部分有些内容比较陈旧,但原理和思路还是一致的. 通常来说,概念架构满足"架构=组件+交互"且只关注高层组件,之后对齐进行笼统的界定,给为他们之间的关心,此外,概念架构不涉及接口细节.这儿需要牢记的是,重大需求塑造概念设计,这儿的重大需求就是预架构中的功能.质量及约束3类需求中的关键部分. 概念架构阶段的3个步骤 初步设计:基于关键功能,借助鲁棒图进行以发现职责为目的的初步设计,对于新系统很重要. 高层分割:对系统黑盒进行

架构设计-谈谈架构

1.什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解.   此君说的架构和彼君理解的架构未必是一回事. 我们主要针对互联网服server系统(类似网站)来定义架构:架构是系统的骨架,支撑和链接各个部分,包括组件.连接件.约束规范,以及指导这些内容设计与演化的原理. 组件:类似应用服务,独立模块.数据库.nginx等等.     连接件:分布式调用.进程间调用.调用使用http协议还是tcp协议.组件之间的交互关系.     约束规范:    定规则做限制:例

架构-三层架构:三层架构

ylbtech-架构-三层架构:三层架构 三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:界面层(User Interface layer).业务逻辑层(Business Logic Layer).数据访问层(Data access layer).区分层次的目的即为了“高内聚低耦合”的思想.在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构.微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层.业务逻辑层(又或称为领域层).表

DDD CQRS架构和传统架构的优缺点比较

明天就是大年三十了,今天在家有空,想集中整理一下CQRS架构的特点以及相比传统架构的优缺点分析.先提前祝大家猴年新春快乐.万事如意.身体健康! 最近几年,在DDD的领域,我们经常会看到CQRS架构的概念.我个人也写了一个ENode框架,专门用来实现这个架构.CQRS架构本身的思想其实非常简单,就是读写分离.是一个很好理解的思想.就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.关于CQRS架构的介绍其实已经非常