逻辑架构和物理架构

逻辑架构和物理架构

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

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

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

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

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

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

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

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

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值