精华内容
下载资源
问答
  • 逻辑架构和物理架构
    千次阅读
    2018-10-16 16:04:34

    逻辑架构和物理架构

    在实际工作中,我们经常听到“架 构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什 么,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了对架构的一些理解,希望能够补充很多初入门的 人在这方面认识上的不足,纠正一些误解。高手和老鸟就直接跳过吧。

     

    • 架构的分类

     

    对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。

     

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

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

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

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

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

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

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

     

     

    • 架构设计到底是什么

     

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

    之前已经纠正过很多人的误解-架构不只是软件架构。说一下通俗点的理解:

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

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

     

     

    • 关于Tier和Layer

     

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

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

    如下图所示:

     

    顺便再纠正一点,很多人问“到底什么是web服务器,什么是应用服务器”。这个恐怕没有标准答案的。有些人可能觉得,处理静态资源的就是web服务 器,处理动态请求的就是应用服务器,这其实是不准确的。以互联网领域典型的SOA架构为例,上层Web应用所在的服务器,可以叫web服务器,web应用 仅仅负责处理输入/输出,而提供服务宿主的服务器可以称为应用服务器(也包含对业务逻辑和数据访问的处理)。当然,服务的宿主方式可以有很多中,可以是系 统服务,是可执行程序,是web应用,是Socket网络服务...

     

     

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

     

    逻辑分层的好处:

     

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

    物理分层的好处:

     

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

     

    架构师往往是很多开发人员向往的职业,也不是像很多人想象中的那样(画一下PPT或者UML草图,然后交给程序员们去实现,然后自己就自由玩耍 了)。国内很多公司,是没有架构师这种岗位定义的,通常是由技术优秀和经验比较丰富的开发人员担任,身兼多职的情况也并不少见(我见过很多小公司的骨干人 员是身兼技术主管、系统分析师、项目经理、架构师、核心开发人员...)。值得纠正的就是,架构师和系统分析师不同,系统分析师更侧重在项目早期的需求分 析。而架构师,一般贯穿整个软件开发周期,与项目经理也是相辅相成的。微软对于架构师,又分为:软件架构师、系统架构师、解决方案架构师、企业架构师等。 而其它一些厂商,可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师......

    大家不必对这些概念太纠结。按照笔者的理解,国内大互联网公司里,架构师一般只会分2-3个方向:软件架构师和系统架构师(有些企业叫运维架构 师),有些企业对于比较资深DBA而且懂整个系统架构的,还会分出所谓的“数据架构师”。至于具体Title,大可不必纠结,只需了解自己的兴趣,知晓了 大致发展和定位,然后朝该方向努力即可。对于程序员而言,最基本的还是先写出高质量的代码,在实战中逐步提升自己设计思维。

     

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

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

     

    本文出自http://www.cnblogs.com/dinglang,转载请注明出处。

    更多相关内容
  • 3.1 系统逻辑架构

    千次阅读 2018-10-15 11:11:40
    第3章 超级账本的系统架构区块链的业务需求多种多样,一些要求在快速达成网络共识及快速确认区块后,才可以将区块加入区块链中。有一些可以 接受相对缓慢的处理时间,以换取较低级别的信任。各行各业在扩展性、...

    第3章 超级账本的系统架构

    区块链的业务需求多种多样,一些要求在快速达成网络共识及快速确认区块后,才可以将区块加入区块链中。有一些可以 接受相对缓慢的处理时间,以换取较低级别的信任。各行各业在扩展性、可信度、合法性、工作流复杂度以及安全性等方面的需求和用途都不尽相同。我们先来看一 下在企业级区块链系统中常见的模块构成

    一些常用的功能模块有:应用程序、成员管理、智能合约、账本、共识机制、事件机制、系统管理等。纵轴代表用户或者开发 者更关心的内容,越往上代表用户更关注,比如应用程序和钱包等,越靠下是开发者更关注的模块,比如事件机制。而横轴则是从时间的维度来看的,左边是一开始 关注的功能,直到完成所有的功能。

    Hyperledger Fabric 1.0是一种通用的区块链技术,其设计目标是利用一些成熟的技术实现分布式账本技术(Distributed Ledger Technology,DLT)。超级账本采用模块化架构设计,复用通用的功能模块和接口。模块化的方法带来了可扩展性、灵活性等优势,会减少模块修改、 升级带来的影响,能很好地利用微服务实现区块链应用系统的开发和部署。Hyperledger Fabric 1.0设计有几个特点:加 入 会 员 微 信 dedao555

    1)模块插件化:很多的功能模块(如CA模块、共识算法、状态数据库存储、ESCC、VSCC、BCCSP等)都是可插拔的,系统提供了通用的接口和默认的实现,这满足了大多数的业务需求。这些模块也可以根据需求进行扩展,集成到系统中。

    2)充分利用容器技术:不仅节点使用容器作为运行环境,链码也默认运行在安全的容器中。应用程序或者外部系统不能直接操作链码,必须通过背书节点提供的接口转发给链码来执行。容器给链码运行提供的是安全沙箱环境,把链码的环境和背书节点的环境隔离开,链码存在安全问题也不会影响到背书节点。

    3)可扩展性:Hyperledger Fabric 1.0在0.6版本的基础上,对Peer节点的角色进行了拆分,有背书节点(Endorser)、排序服务节点(Orderer)、记账节点 (Committer)等,不同角色的节点有不同的功能。节点可以加入到不同的通道(Channel)中,链码可以运行在不同的节点上,这样可以更好地提 升并行执行的效率和吞吐量。

    4)安全性:Hyperledger Fabric 1.0提供的是授权访问的区块链网络,节点共同维护成员信息,MSP(Membership Service Provider)模块验证、授权了最终用户后才能使用区块链网络的功能。多链和多通道的设计容易实现数据隔离,也提供了应用程序和链码之间的安全通道, 实现了隐私保护。

    3.1 系统逻辑架构

    图3-2所示为Hyperledger Fabric 1.0设计的系统逻辑架构图。

    image.png

    图3-2 Hyperledger Fabric 1.0的系统逻辑架构图

    图3-2所示的系统逻辑架构图是从不同角度来划分的,上层从应用程序的角度,提供了标准的gRPC接口,在API 的基础之上封装了不同语言的SDK,包括Golang、Node.js、Java、Python等,开发人员可以利用SDK开发基于区块链的应用。区块链 强一致性要求,各个节点之间达成共识需要较长的执行时间,也是采用异步通信的模式进行开发的,事件模块可以在触发区块事件或者链码事件的时候执行预先定义 的回调函数。下面分别从应用程序和底层的角度分析应该关注的几个要素。

    1.应用程序角度

    (1)身份管理

    用户注册和登录系统后,获取到用户注册证书(ECert),其他所有的操作都需要与用户证书关联的私钥进行签名,消息接收方首先会进行签名验证,才进行后续的消息处理。网络节点同样会用到颁发的证书,比如系统启动和网络节点管理等都会对用户身份进行认证和授权。

    (2)账本管理

    授权的用户是可以查询账本数据(ledger)的,这可以通过多种方式查询,包括根据区块号查询区块、根据区块哈希查询区块、根据交易号查询区块、根据交易号查询交易,还可以根据通道名称获取查询到的区块链信息。

    (3)交易管理

    账本数据只能通过交易执行才能更新,应用程序通过交易管理提交交易提案(Proposal)并获取到交易背书 (Endorsement)以后,再给排序服务节点提交交易,然后打包生成区块。SDK提供接口,利用用户证书本地生成交易号,背书节点和记账节点都会校 验是否存在重复交易。

    (4)智能合约

    实现“可编程的账本”(Programmable Ledger),通过链码执行提交的交易,实现基于区块链的智能合约业务逻辑。只有智能合约才能更新账本数据,其他模块是不能直接修改状态数据(World State)的。

    2.底层角度

    下面的内容是从Hyperledger Fabric 1.0底层的角度来看,如何实现分布式账本技术,给应用程序提供区块链服务。

    (1)成员管理

    MSP(Membership Service Provider)对成员管理进行了抽象,每个MSP都会建立一套根信任证书(Root of Trust Certificate)体系,利用PKI(Public Key Infrastructure)对成员身份进行认证,验证成员用户提交请求的签名。结合Fabric-CA或者第三方CA系统,提供成员注册功能,并对成 员身份证书进行管理,例如证书新增和撤销。注册的证书分为注册证书(ECert)、交易证书(TCert)和TLS证书(TLS Cert),它们分别用于用户身份、交易签名和TLS传输。

    (2)共识服务

    在分布式节点环境下,要实现同一个链上不同节点区块的一致性,同时要确保区块里的交易有效和有序。共识机制由3个 阶段完成:客户端向背书节点提交提案进行签名背书,客户端将背书后的交易提交给排序服务节点进行交易排序,生成区块和排序服务,之后广播给记账节点验证交 易后写入本地账本。网络节点的P2P协议采用的是基于Gossip的数据分发,以同一组织为传播范围来同步数据,提升网络传输的效率。

    (3)链码服务

    智能合约的实现依赖于安全的执行环境,确保安全的执行过程和用户数据的隔离。Hyperledger Fabric采用Docker管理普通的链码,提供安全的沙箱环境和镜像文件仓库。其好处是容易支持多种语言的链码,扩展性很好。Docker的方案也有 自身的问题,比如对环境要求较高,占用资源较多,性能不高等,实现过程中也存在与Kubernetes、Rancher等平台的兼容性问题。

    (4)安全和密码服务

    安全问题是企业级区块链关心的问题,尤其在关注国家安全的项目中。其中底层的密码学支持尤其重 要,Hyperledger Fabric 1.0专门定义了一个BCCSP(BlockChain Cryptographic Service Provider),使其实现密钥生成、哈希运算、签名验签、加密解密等基础功能。BCCSP是一个抽象的接口,默认是软实现的国标算法,目前社区和较多 的厂家都在实现国密的算法和HSM(Hardware Security Module)。

    Hyperledger Fabric 1.0在架构上的设计具有很好的可扩展性,目前是众多可见的区块链技术中最为活跃的,值得区块链技术爱好者深入研究。


    来源:我是码农,转载请保留出处和链接!

    本文链接:http://www.54manong.com/?id=1086

    '); (window.slotbydup = window.slotbydup || []).push({ id: "u3646208", container: s }); })();
    '); (window.slotbydup = window.slotbydup || []).push({ id: "u3646147", container: s }); })();
    展开全文
  • 系统逻辑架构图怎么画

    万次阅读 2019-12-11 12:35:09
    系统逻辑架构图根据系统组成绘制,不同类型的系统,逻辑架构图会有些许差异,本文以软件系统为例,介绍如何绘制系统逻辑架构图。 绘制工具:PPT 或 VISIO ,当然也可以使用其他工具。 工具/原料 VISIO PPT 方法/...

    转载:https://jingyan.baidu.com/article/86f4a73ec5a78c37d652692a.html (图自己重画)

    系统逻辑架构图根据系统组成绘制,不同类型的系统,逻辑架构图会有些许差异,本文以软件系统为例,介绍如何绘制系统逻辑架构图。
    绘制工具:PPT 或 VISIO ,当然也可以使用其他工具。

    工具/原料

    VISIO
    PPT

    方法/步骤

    本文使用PPT绘制,点击“开始”——“WPS”——“演示文档”,打开一个空白文稿
    在这里插入图片描述
    软件系统架构图可以分为基础设置、数据层、应用层、用户层四个层次。

    基础设施层

    首先绘制基础设施层,基础设置层包括:网络、服务器、存储、存储设备等硬件环境,是系统运行的基础保证,如下图所示。
    在这里插入图片描述

    数据层

    数据层用于存储系统的数据,系统数据有多种类型,包括系统配置数据库、用户管理数据库、元数据库、文件数据库等。如下图所示:
    在这里插入图片描述

    应用层

    应用层根据实际系统设计,可以分为应用层和服务层。
    (1)服务层介于数据层和业务应用层,为业务应用层提供功能支持,也就常说的中间件层,包括即时通讯系统、短信平台、数据访问组件、安全审计组件、数据交换等。
    在这里插入图片描述

    业务应用层

    业务应用层是指具体的业务应用系统功能模块,包括业务报表,GIS管理、业务统计、综合查询、业务表单、与流程等。
    在这里插入图片描述

    用户层

    用户层为用户提供使用系统的入口,包括门户管理系统、单点登录系统等。
    在这里插入图片描述
    至此、一个系统的逻辑架构图就画好了,当然,这里是一个相对简单的系统逻辑架构图,详细的要根据实际系统设计来绘制。

    展开全文
  • 云平台架构设计图,有需要的可以下载看看。主要是功能的组成及分层,正常的云平台架构设计。 有需要的,欢迎各位下载,做个参考,资源分也不多
  • 在不同的架构设计方法中出现的软件架构视图种类很多,本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图,并通过具体案例的分析说明如何运用它们进行架构设计。 当观察和描述事物大局的时候,逻辑架构和...

    http://www.uml.org.cn/zjjs/200906045.asp

     

    在不同的架构设计方法中出现的软件架构视图种类很多,本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图,并通过具体案例的分析说明如何运用它们进行架构设计。

    当观察和描述事物大局的时候,逻辑架构和物理架构是最常用的角度。比如,以我们办公室里的局域网为例:从物理角度看,所有计算机“毫无区别”地连接到路由器上;而从逻辑角度看呢,就发现这些计算机是有区别的——一台计算机充当文件服务器,而其它计算机是可以访问服务器的客户机。如图1所示。

    图1  区分物理视角与逻辑视角

    同样,在软件架构设计过程中,也可以通过区分软件的逻辑架构和物理架构,分别从不同的角度设计和描述软件架构。

    所谓软件架构视图,是指设计和看待整个软件系统的特定视角。每个软件架构视图关注系统架构的不同方面,针对不同的目标和用途。也就是说,架构要涵盖的内容和决策太多了,超过了人脑“一蹴而就”的能力范围,因此采用“分而治之”的办法从不同视角分别设计;同时,也为软件架构的理解、交流和归档提供了方便。

    逻辑架构

    软件的逻辑架构规定了软件系统由哪些逻辑元素组成、以及这些逻辑元素之间的关系。

    软件的逻辑元素一般指某种级别的功能模块,大到我们熟悉的逻辑层(Layer),以及子系统、模块,小到一个个的类。至于具体要分解到何种大小的功能模块才可结束软件架构设计,并不存在一个“一刀切”的标准——只要足够明确简单,能够分头开发就可以了。于是,在实践中我们往往将关键机制相关的架构设计部分明确到类,而一般功能则到模块甚至子系统的接口定义即可。

    值得说明的是,功能模块有时容易识别,有时却比较隐含。而比较全面地识别功能块、规划功能块的接口、明确功能块之间的使用关系和使用机制,正是软件逻辑架构设计的核心任务所在。对此,Ivar Jacobson曾有过极为形象的说法,“软件系统的架构涵盖了整个系统,尽管架构的有些部分可能只有‘一寸深’”。

    图2展示了一个网络设备管理系统逻辑架构设计的一部分,我们借此来举例说明软件逻辑架构设计的3大核心任务:

    识别功能块

    规划功能块的接口

    明确功能块之间的使用关系和使用机制

    软件的逻辑架构是架构设计思维的重要方法。在用例技术已经成为捕获功能需求的事实标准的今天,逻辑架构的设计往往是从用例分析开始的。基于用例的分析方法使逻辑架构的设计变得比较有序——通过对每个关键用例的分析,从逻辑上将用例实现为一组功能块的特定组合,最后综合这些用例分析成果,将一个个独立的协作归纳合并成整个软件系统的逻辑架构。而在用例分析方法产生之前,功能模块的确定多多少少带有些“硬”想出来的味道,特别是并不直接承载业务功能的模块有时比较容易遗漏,直到大规模编程实现阶段才发现。

    物理架构

    软件的物理架构规定了组成软件系统的物理元素、这些物理元素之间的关系、以及它们部署到硬件上的策略。

    物理架构可以反映出软件系统动态运行时的组织情况。此时,上述物理架构定义中所提及的“物理元素”就是进程、线程、以及作为类的运行时实例的对象等,而进程调度、线程同步、进程或线程通信等则进一步反映物理架构的动态行为。

    随着分布式系统的流行,“物理层(Tier)”的概念大家早已耳熟能详。物理层和分布有关,通过将一个整体的软件系统划分为不同的物理层,可以把它部署到分布在不同位置的多台计算机上,从而为远程访问和负载均衡等问题提供了手段。当然,物理层是大粒度的物理单元,它最终是由粒度更小的组件、模块、进程等单元组成的。

    物理架构的应用很广泛。例如,架构设计中可能需要专门说明数据是如何产生、存储、共享和复制的,这时可以利于物理架构,展示软件系统在运行期间数据是由哪些运行时单元如何产生的,数据又如何被使用、如何被存储,哪些数据需要跨网络复制和共享等方面的设计决策。

    由于人们对组成软件系统的“物理元素”存在不同看法(如图3所示),所以在实践中物理架构的用法比较宽泛,不同的人认为的物理架构也可能不尽相同。因此,我们在交流和实践的过程中,应注意区分物理架构所指为何。(也正是因为这个原因,实践中所采用的基于多视图的架构设计方法往往包含更多的视图,从而使每个架构视图的职责更加明确。)


     

    图3    对“物理元素”的不同看法

    从逻辑架构和物理架构到设计实现

    逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元,并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构,以及组成软件系统的目标程序如何部署到硬件上。

    在后续的详细设计和编程实现中,将贯彻和利用逻辑架构和物理架构设计中制定的架构决策,如图4所示。

       

      图4    逻辑架构和物理架构对后续开发的作用

    逻辑架构中关于职责划分的决策,体现为层、子系统、模块等的划分决定,从静态视角为详细设计和编程实现提供切实的指导;有了分解就必然产生协作,逻辑架构还规定了不同逻辑单元之间的交互接口和交互机制,而编程工作必须实现这些接口和机制。 所谓交互机制,是指不同软件单元之间交互的手段。交互机制的例子有:方法调用、基于RMI的远程方法调用、发送消息等。

    至于物理架构,它关注的是软件系统在计算机中运行期间的情况。物理架构设计方案中规定了软件系统如何使用进程和线程完成期望的并发处理、进程线程这些主动对象(Active Object)会调用哪些被动对象(Passive Object)参与处理、交互机制(如消息)为何等等问题,从而为详细设计和编程实现提供了工作目标的动态视图。

    设备调试系统案例简介

    下面通过一个实际案例的分析,来帮助领会逻辑架构和物理架构这两种架构视图对架构设计的指导作用。

    该案例是某型号设备调试系统。设备调试员通过使用该系统,可以察看设备状态(设备的状态信息由专用的数据采集器实时采集)、发送调试命令。该系统的用例图如图5所示。


      
    图5    设备调试系统的用例图

    逻辑架构设计

    首先根据功能需求进行初步设计,进行大粒度的职责划分。如图6所示。

     

    图6    设备调试系统的逻辑架构

    之后,还有很多与逻辑架构设计相关的工作要做。例如,图7所示的CRC卡描述了上面的三层架构每一层的职责与协作者:

    应用层负责设备状态的显示,并提供模拟控制台供用户发送调试命令。

    应用层使用通讯层和设备控制层进行交互,但应用层不知道通讯的细节。

    通讯层负责在RS232协议之上实现一套专用的“应用协议”。

    当应用层发送来包含调试指令的协议包,由通讯层负责按RS232协议将之传递给设备控制层。

    当设备控制层发送来原始数据,由通讯层将之解释成应用协议包发送给应用层。

    设备控制层负责对调试设备的具体控制,以及高频度地从数据采集器读取设备状态数据。

    设备控制指令的物理规格被封装在设备控制层内部,读取数采器的具体细节也被封装在设备控制层内部。

    图7    用CRC卡描述每层的职责和协作者

    物理架构设计

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

    多个逻辑层(Layer)可以映射到一个物理层(Tier),这是很多从事分布式开发的读者都了解的。在进行设备调试系统的物理架构设计之时,也体现了这一点。如图8所示,设备调试系统共包含2个物理层:桌面部分和嵌入部分。作为逻辑层的应用层和通讯层最终将成为桌面部分,而设备控制层最终成为嵌入部分。

    图8    逻辑层(Layer)到物理层(Tier)的映射

    物理层作为组成软件系统的物理单元,最终又要映射到具体的硬件,这也是物理架构设计要考虑的,对于分布式软件系统的设计而言尤其不可或缺。图9展示了这一点。可以看出,设备控制部分驻留在调试机中(调试机是专用单板机),而桌面部分以常见的“Windows可执行程序”的形式运用于PC机之上。

     

    图9    设备调试系统架构的物理架构

    我们还可能根据具体情况的需要,通过物理架构视图更明确地表达具体目标模块及其通讯结构,如图10所示。

    图10 设备调试系统的物理架构

    总结

    从简单系统到复杂系统的变化,对架构设计的冲击决不仅仅是量变的问题。通过引入了软件架构视图的概念,有助于软件架构师控制架构设计的复杂性。

    软件架构视图的概念和软件架构基本概念是完全相容的,后者针对软件系统的整体目标,而前者针对特定目标子集,这样一来,重点突出了,问题明确了,软件架构师的经验也就活跃了起来。

    逻辑架构和物理架构相分离的设计方法在软件实践中比较常用。逻辑架构和物理架构是软件架构设计的重要方面。逻辑架构致力于将软件系统分解成不同的逻辑单元,并规定这些逻辑单元之间的交互接口和交互机制。物理架构则更重视软件系统运行时的动态结构,以及组成软件系统的目标程序如何部署到硬件上。

    展开全文
  • MySQL逻辑架构及工作流程

    千次阅读 多人点赞 2018-08-31 18:43:02
    同时,MySql既可以嵌入到应用程序中,也可以支持数据仓库、内容索引和部署软件、高可用的冗余系统、在线事务处理系统等各种应用类型。  为了更心如的理解MySql服务器,我们需要理解MySql各部件之间如何协同工作。...
  • 解读OpenShift的逻辑架构和技术架构

    千次阅读 2022-04-07 12:20:08
    作者:魏新宇 郭跃军来源:大数据DT(ID:hzdashuju)01 OpenShift的逻辑架构OpenShift的逻辑架构图如图2-6所示。▲图2-6 OpenShift逻辑架构图2-6中的关键组件介绍如下。底层基础设施:OpenShif...
  • 这篇英文ppt主要介绍了自动驾驶系统架构的设计包括逻辑架构、功能架构、网络架构和线控架构等等。
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...
  • 权限系统的基本概念和架构

    万次阅读 热门讨论 2020-12-21 19:33:06
    权限系统是我们在系统设计和应用中一种非常常见的系统。一般来说权限系统的功能分为认证和授权两种。认证就非常简单的,验证完用户名密码就算认证成功,而授权里面的套路就很多了,本文将会详细讲解权限系统中的一些...
  • 通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户
  • )即部署逻辑架构等同于网络拓扑2.(系统逻辑架构,则更偏向于系统的功能流转,与功能架构关联 )即系统逻辑架构等同于应用架构、业务架构3.(体系架构和总体架构一直认为是一个总括的名词,它应该由系统定位、功能...
  • Servlet学习之系统架构

    千次阅读 2022-04-01 20:22:18
    系统架构的分类2.C/S架构2.1 常见的C/S架构的软件或者系统2.2 特点2.3 优点和缺点3.B/S架构3.1 常见的B/S架构的软件或者系统3.2 特点3.3 优点和缺点4.两种架构适合的场景5.B/S架构通信原理 1.系统架构的分类 系统...
  • 架构类型以及软件架构逻辑详解

    万次阅读 2019-02-21 09:04:17
    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。 内核(core)通常只包含系统运行的最小功能。插件则是互相独立...
  • 如何进行系统架构设计?

    千次阅读 2020-03-02 17:30:51
    一个软件项目在需求确定后,就可以开始系统架构设计了。架构设计不同于编写代码,需要遵循严格的语法和编程规范。它没有规范可遵循,存在即合理,适合系统开发和运行的架构就是最合理的系统架构系统架构设计...
  • mysql逻辑架构

    千次阅读 2018-12-03 10:57:39
    mysql 逻辑架构组成
  • 分布式系统架构

    千次阅读 2022-03-24 16:30:08
    2.分布式系统架构:运行在多个处理器上的软件架构设计。 3.分布式系统:建立在网络之上支持分布式处理的软件系统,由通信网络互联的多处理机体系结构上执行任务的系统。具有高度的内聚性和透明性。 内聚性:每一个...
  • 分布式系统架构网络之IDC机房

    万次阅读 2017-09-28 16:46:39
    如下所示是IDC机房的网络架构图,一般分为出口路由区、核心交换区、接入网络区及增值业务区四个区域。 1、出口路由区的主要功能是作为IDC机房的出口,与国干网(CHINANET骨干网)和本身的城域网互联,完成外部...
  • 论软件系统架构风格

    千次阅读 2022-04-23 16:24:24
    系统致力于实现全国保险业务种类的整合、数据分析、订单汇总、账单汇总,为集团人员提供全国保险账单的管理、安全监控、数据保护方面提供全方位的软件支持,在该项目中我主要担任系统架构师岗位,负责整体架构设计...
  • 我们画的架构图、流程图、结构图、功能图、逻辑图等,都需要好看、好懂、好用、好搞,因为: 好看是为了提升沟通效率, 好懂是为了提升交流共识, 好用是为了提升交付质量, 好搞是为了提升实施速度。 架构图有...
  • 系统架构师--考试大纲

    千次阅读 2021-06-01 14:18:34
    开始接触DDD相关模式,同时整个人精神压力瞬间减轻,工作强度减小,想着在某些方面提升自己防止以后被优化,国企又比较注重一些证书,萌生了考一些证的想法,于是准备先考系统架构师,趁着公司系统架构调整的东风,...
  • 理解Hyperledger Fabric超级账本的逻辑架构。 理解Hyperledger Fabric超级账本的实际运行时架构。 任务实现 进步非常快。现在我们结合图形,然后根据对应的解释全面理解Hyperledger Fabric的架构。 2.1.1 比较...
  • 系统架构

    万次阅读 2018-08-03 11:48:57
    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。  简单说明: 1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境 ...
  • 于是,你重新审视了自己的系统架构,分析系统中有哪些可以优化的点。 目前来看,工程的部署方式还是采用一体化架构,也就是说所有的功能模块,比方说电商系统中的订单模块、用户模块、支付模块、物流
  • 网络安全架构

    千次阅读 2021-03-05 10:29:07
    网络安全架构 2021/3/5 一.安全域 安全域 安全域是边界防护的基础 具有相同安全业务级别 统一的边界访问策略控制 通常将安全域分为 办公域 办公服务域 线上业务域1.2.3.等 开发域 测试域 对外...
  • 信息系统设计是开发阶段的重要内容,其主要任务是从信息系统的总体目标出发,根据系统逻辑功能的要求,并结合经济、技术条件、运行环境和进度等要求,确定系统的总体架构和系统各组成部分的技术方案,合理选择计算机...
  • 各种系统架构图与详细说明

    万次阅读 2018-11-13 20:29:19
    共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立行业...
  • 推荐系统架构详解

    千次阅读 2020-11-28 00:54:36
    之前对推荐系统进行学习的过程中,发现自己只是拘泥于其中的一小部分进行学习,没有一个全局系统的认知,经常容易陷入困惑,因此借分享会机会,将推荐系统架构梳理一遍,在梳理的过程中才对推荐系统有了更加清楚的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 280,266
精华内容 112,106
关键字:

内容网络系统逻辑架构