软件框架_蔷薇框架软件 - CSDN
精华内容
参与话题
  • 软件架构与框架

    千次阅读 2018-06-02 19:53:59
    描述软件架构与框架之间的区别与联系 定义 软件架构:软件架构是一个...软件框架软件框架是面向领域(如 ERP、计算领域等)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供了一些定义良好的可...

    描述软件架构与框架之间的区别与联系

    定义

    • 软件架构:软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。设计软件架构就是把系统分解为一些部件,描述这些部件的职责及它们之间的协作行为。
    • 软件框架:软件框架是面向领域(如 ERP、计算领域等)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供了一些定义良好的可变点以保证灵活性和可扩展性。也就是说软件框架是领域分析结果的软件化,是领域内最终应用的模板,是特定语言和技术的架构应用解决方案。

    区别

    简单来说,两者的区别在于架构不是软件,而框架是软件。

    软件架构不是软件,而是关于软件如何设计的重要决策。软件架构决策涉及到如何将软件系统分解成不同的部分、各部分之间的静态结构关系和动态交互关系等。经过完整的开发过程之后,这些架构决策将体现在最终开发出的软件系统中;当然,引入软件框架之后,整个开发过程变成了“分两步走”,而架构决策往往会体现在框架之中。

    框架是一种特殊的软件,由实际的代码构建而成,它并不能提供完整无缺的解决方案,而是为你构建解决方案提供良好的基础,是软件系统、子系统的半成品。软件框架为具体的解决方案提供了基础,提供了基础服务和可扩展点,同时软件框架也建立了一些约束,开发人员在此基础上进行特定业务功能的定制开发。

    • 框架是具体语言和技术相关的,而架构与具体语言和技术无关。
    • 框架是集成了你的代码和多种第三方解决方案的工具,让你聚焦 业务逻辑代码不是技术实现

    联系

    软件架构是引导如何设计软件框架的重要决策。它决定了软件系统如何划分,在一定程度上描述了被划分的各个部分之间的静态、动态关系。软件架构的决策体现在软件系统的框架中。

    框架是一个可实例化的、部分完成的软件系统或子系统,它为一组系统或子系统定义了架构,并提供了构造系统的基本构造块,还为实现特定功能定义了可调整点。在面向对象环境中,框架由抽象类和具体类组成。(A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made. In an object-oriented environment a framework consists of abstract and concrete classes.)

    ——《面向模式的软件体系结构(第一卷)》

    总而言之,软件架构指导软件框架的设计,而软件框架是一种或多种架构的组合的实现。

    以你的项目为案例

    • 绘制三层架构模型图,细致到分区

      这里写图片描述

    • 结合你程序的结构,从程序员角度说明三层架构给开发者带来的便利

      • 总的来说,使用三层架构可以做到关系分离、高级服务与低级服务分离、特定于应用的服务与一般性服务分离。三层架构可以减少耦合和依赖性、增强内聚性、提高潜在的复用性并且使概念更加清晰。这可以使得不同层的开发者之间专注于本层开发,而无需考虑除本层以外的开发。在我的程序中,UI层、Domian层和Technical层三者之间的耦合度很小,从而使得各层的开发相互独立,大大提高了开发和调试的效率。
      • 封装和分解了相关的复杂性,有利于提供开发效率。在我的程序中,显示菜单数据、处理订单数据和存储交易数据相互分开,数据流得到了有效组织和管理,从而大大减少了开发复杂度。
      • 较低层的复用性较高,为开发者减少了重新开发的麻烦以及代码量。
      • 通过逻辑划分,有利于开发者进行高效的团队开发。
      • 各个层次清晰,每个层次都提供了接口定义:

        • 很容易用新的实现替换原来的层次实现。例如对sql进行性能优化,并不会影响其他层的代码结构。有利于后期维护。
        • 有利于实现切面编程,减轻业务的复杂程度,加快编码效率。
        • 每个层次的定位明晰,业务处理的内容明确。依据层次,可以划分不同的分工。开发人员可以只关注整个结构的其中某一层。
        • 接口定义也提供了良好的可扩展性。例如数据库从mysql切换到oracle,只需要通过配置来切换。
      • 接口设计需要符合对扩展开发,对修改关闭的原则,增强了系统的安全性

    研究 VUE 与 Flux 状态管理的异同

    • 同: Flux 思想是为了解决传统 MVC 架构不能有效解决大型业务中复杂数据流的管理问题而产生的一种软件架构思想。VUE 和 Flux 的状态管理都是基于 Flux 思想的有效实现,通过对数据流进行严格管理来规范数据在 Web 应用中流动方式的框架。

    • 异: VUE 与 Flux 在状态管理上的差异主要体现在对数据流的管理方式不同。

      • Flux 通过强制数据的单向流动来解决业务数据复杂度的问题。它主要将一个应用分成四个部分:

        • View: 视图层
        • Action(动作):视图层发出的消息(比如mouseClick)
        • Dispatcher(派发器):用来接收Actions、执行回调函数
        • Store(数据层):用来存放应用的状态,一旦发生变动,就提醒Views要更新页面

        这里写图片描述

        Flux 数据流的顺序是:

        View 发起 Action --> Action 传递到 Dispatcher --> Dispatcher 接收 Action,并通知 Store 进行更新 --> Store 更新状态并通知 View 进行改变 --> View 收到通知后,更新相应页面内容

        在这个过程中,数据总是单向流动,任何相邻的部分都不会发生数据的双向流动。这保证了数据流的清晰。

      • VUE 的状态管理由vuex实现。VUE 没有使用 Dispatcher 来接收 Actions 、执行回调函数并通知 Store 改变状态,而是通过使用 Mutation 来改变状态。VUE 的状态管理的核心概念如下:

        • State: Vuex 使用 单一状态树 —— 是的,用一个对象就包含了全部的应用层级状态。至此它便作为一个『唯一数据源(SSOT)』而存在。这也意味着,每个应用将仅仅包含一个 store 实例。
        • Getters: 从state中获取状态值
        • Mutation: 更改 Vuex 的 store 中的状态的唯一方法是提交 mutation。Vuex 中的 mutations 非常类似于事件:每个 mutation 都有一个字符串的 事件类型 (type) 和 一个 回调函数 (handler)。这个回调函数就是我们实际进行状态更改的地方,并且它会接受 state 作为第一个参数
        • Action: 类似于 mutation,不同在于:Action 提交的是 mutation,而不是直接变更状态;Action 可以包含任意异步操作。

        这里写图片描述

        VUE 的状态变更相当于是 action 产生的副作用,mutation 的作用是将这些副作用记录下来,这样就形成了一个完整数据流闭环,数据流的顺序如下:

        在视图中触发 action,并根据实际情况传入需要的参数 -->  action 中触发所需的 mutation,在 mutation 函数中改变 state --> 通过 getter/setter 实现的双向绑定会自动更新对应的视图。

    参考文档

    1. 软件框架和软件结构的区别
    2. 一图胜千言:谈框架和架构的区别
    3. 什么是Flux架构?
    4. 浅谈前端状态管理(上)
    5. 浅谈前端状态管理(下)
    6. Vue 和 React 对比
    7. Flux 架构入门教程
    8. 关于 Flux, Vuex, Redux 的思考
    展开全文
  • 常见的五种软件架构

    万次阅读 2019-05-27 00:19:21
    软件架构(software architecture)就是软件的基本结构。 合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect),只有资深程序员才可以担任。 O'Reilly 出版过一本免费的小...

    软件架构(software architecture)就是软件的基本结构。

    合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位(architect),只有资深程序员才可以担任。

    O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》PDF), 介绍了五种最常见的软件架构,是非常好的入门读物。我读后受益匪浅,下面就是我的笔记。

    一、分层架构


    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。

    这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。

    虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。

    • 表现层(presentation):用户界面,负责视觉和用户互动
    • 业务层(business):实现业务逻辑
    • 持久层(persistence):提供数据,SQL 语句就放在这一层
    • 数据库(database) :保存数据

    有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。

    用户的请求将依次通过这四层的处理,不能跳过其中任何一层。

    优点

    • 结构简单,容易理解和开发
    • 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
    • 每一层都可以独立测试,其他层的接口通过模拟解决

    缺点

    • 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
    • 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
    • 软件升级时,可能需要整个服务暂停
    • 扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难

     

    二、事件驱动架构


     

     

    事件(event)是状态发生变化时,软件发出的通知。

    事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。

    • 事件队列(event queue):接收事件的入口
    • 分发器(event mediator):将不同的事件分发到不同的业务逻辑单元
    • 事件通道(event channel):分发器与处理器之间的联系渠道
    • 事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作

    对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。

    优点

    • 分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
    • 适用性广,各种类型的项目都可以用
    • 性能较好,因为事件的异步本质,软件不易产生堵塞
    • 事件处理器可以独立地加载和卸载,容易部署

    缺点

    • 涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
    • 难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚
    • 分布式和异步特性导致这个架构较难测试

     

    三、微核架构


    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。

    内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。

    优点

    • 良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
    • 功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
    • 可定制性高,适应不同的开发需要
    • 可以渐进式地开发,逐步增加功能

    缺点

    • 扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
    • 开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制

     

    四、微服务架构


    微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。

    每一个服务就是一个独立的部署单元(separately deployed unit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。

     

     

    微服务架构分成三种实现模式。

    • RESTful API 模式:服务通过 API 提供,云服务就属于这一类
    • RESTful 应用模式:服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部
    • 集中消息模式:采用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群

    优点

    • 扩展性好,各个服务之间低耦合
    • 容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
    • 容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
    • 易于测试,可以单独测试每一个服务

    缺点

    • 由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。
    • 一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。
    • 分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。

     

    五、云架构


    云结构(cloud architecture)主要解决扩展性和并发的问题,是最容易扩展的架构。

    它的高扩展性,主要原因是没使用中央数据库,而是把数据都复制到内存中,变成可复制的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里,最好要进行数据持久化。

    这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。

    • 处理单元:实现业务逻辑
    • 虚拟中间件:负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。

     

     

     

    虚拟中间件又包含四个组件。

    • 消息中间件(Messaging Grid):管理用户请求和session,当一个请求进来以后,决定分配给哪一个处理单元。
    • 数据中间件(Data Grid):将数据复制到每一个处理单元,即数据同步。保证某个处理单元都得到同样的数据。
    • 处理中间件(Processing Grid):可选,如果一个请求涉及不同类型的处理单元,该中间件负责协调处理单元
    • 部署中间件(Deployment Manager):负责处理单元的启动和关闭,监控负载和响应时间,当负载增加,就新启动处理单元,负载减少,就关闭处理单元。

    优点

    • 高负载,高扩展性
    • 动态部署

    缺点

    • 实现复杂,成本较高
    • 主要适合网站类应用,不合适大量数据吞吐的大型数据库应用
    • 较难测试
    展开全文
  • 软件的架构与框架

    2020-04-21 00:46:11
    这些天,总是看到有地方说,搭建XX系统的框架,然后又出现搭建XX系统的架构。很明显这个所谓的“架构”和“框架”,它们之间确实存在联系,但它们绝对不是一回事。所以我也来讨论讨论吧,写的不好,请看友多担待。 ...

    开始

    这些天,总是看到有地方说,搭建XX系统的框架,然后又出现搭建XX系统的架构。很明显这个所谓的“架构”和“框架”,它们之间确实存在联系,但它们绝对不是一回事。所以我也来讨论讨论吧,写的不好,请看友多担待。

    讨论

    软件架构?框架之间?

    • 软件架构:软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。设计软件架构就是把系统分解为一些部件,描述这些部件的职责及它们之间的协作行为。
    • 软件框架:软件框架是面向领域(如 ERP、计算领域等)的、可复用的“半成品”软件,说白了吧就是面向行业的,它实现了该领域或行业的共性部分,并提供了一些定义良好的可变点以保证灵活性和可扩展性。也就是说软件框架是领域或行业分析结果的软件化,是领域或行业内最终应用的模板,是特定语言和技术的架构应用解决方案。

    很明显软件的架构是一个系统草图,是关于软件设计方面的重要的决策,它将软件规范的分为各个部分,并且决定各部分内部结构以及各部分之间的联系。经过开发之后,软件架构可以体现在软件当中。而软件框架是软件的一部分,它是软件的半成品,为软件提供基础的结构和一些规范约束,然后开发人员在软件框架的基础上进行开发。软件架构和软件框架的联系 框架技术和架构技术的出现,都是为了解决系统日益复杂所带来的困难而采取的“分而治之”的思维的结果:先大局后局部,就出现了架构;先通用后专用,就出现了框架。架构是问题的抽象解决方案,关注大局而忽略细节;而框架是通用半成品,还必须根据具体需求进一步定制开发才能变成应用系统。

    框架

    说到这里了,如果作为程序员的你,如果你从事软件开发2-3年以上,你肯定能体会到什么是框架。互联网软件开发发展到至今,纵观各个行业,细化到各个公司,都会在3-4年中产生符合自己公司行业,业务的框架。这个框架一开始可能不健全,不完美,不过随着时间的推移,这个框架会不断的更新,不断的优化,以至于使用各个公司自身的软件研发的扩展。

    问题

    起初您的开发可能是各种拼凑模式,从而可以快速的搭建一个项目,甚至一个产品交付给了客户。那么当这个行业领域客户群体基于稳定的时候,公司一定需要有自己稳定可扩展的框架。这样,将来任何一个项目或者产品,都可以基于这个框架进行扩展开发,不至于当拿到开发需求的时候,每次都去搭建框架,费时费力不说,还不健全。

    解决

    必须在发展的过程中,逐渐完善这个软件架构,方便将来的软件开发。现在大部分公司已经做到这点,有专门的部门进行这种“平台”的搭建,其他部门只需要基于这个“平台”继续开发相应的业务功能即可。说到这里了,很多人就想了,你这不就说的“中间件”,“二次开发平台”,“中台”吗?是吧,都可以,因为没个公司对它的叫法不同,但是它起的作用,毋庸置疑都是相似的。

    架构

    软件架构引导开发人员设计软件框架,是软件框架的重要决策。说白了,您从事的什么行业或者领域的软件或产品开发,相关这个行业或者领域的软件架构就是引导着框架形成。其实很好理解,通信行业的软件架构绝对和金融行业的不会相同,每个公司的业务方向,它们的软件架构也会引导着适合自己公司的软件架构。

    总结

    所以当软件开发到了一定程度的时候,软件框架就应该形成,它的出现是因为所开发的软件所处的行业或领域,由这个行业或者领域的软件架构引导出来的。如果每次有了新的项目和产品的时候,总是从框架搭建开始,就不太合理了。首要任务,要形成符合自己的框架。

    展开全文
  • 软件架构介绍

    千次阅读 2019-06-18 21:21:12
    一、软件架构是个什么概念,架构的定义: 1.软件架构是一个系统的草图。 2.软件架构描述的对象是直接构成系统的抽象组件。 3.各个组件之间的连接则明确和相对细致地描述组件之间的通讯。 4.在实现阶段,这些抽象...

    在这里插入图片描述

    一、软件架构是个什么概念,架构的定义:

    1.软件架构是一个系统的草图。
    2.软件架构描述的对象是直接构成系统的抽象组件。
    3.各个组件之间的连接则明确和相对细致地描述组件之间的通讯。
    4.在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。
    5.在面向对象领域中,组件之间的连接通常用接口来实现。

    二、架构师有细分,基本上可以分为三类:

    1. 系统架构师:服务器负载,可靠性,伸缩,扩展,数据库切分,缓存应用等
    2. 应用架构师:理解业务,梳理模型,设计模式,接口,数据交互等
    3. 业务架构师:也可以叫业务领域专家、行业专家、产品咨询师、资深顾问通常我们说的架构师是1和2的结合

    三、常见软件架构分类:

    1)分层架构

    分层架构(layered architecture)是最常见的软件架构,也是事实上的标准架构。如果你不知道要用什么架构,那就用它。
    这种架构将软件分成若干个水平层,每一层都有清晰的角色和分工,不需要知道其他层的细节。层与层之间通过接口通信。
    虽然没有明确约定,软件一定要分成多少层,但是四层的结构最常见。
    在这里插入图片描述

    表现层(presentation):用户界面,负责视觉和用户互动
    业务层(business):实现业务逻辑
    持久层(persistence):提供数据,SQL 语句就放在这一层
    数据库(database) :保存数据
    

    有的软件在逻辑层和持久层之间,加了一个服务层(service),提供不同业务逻辑需要的一些通用接口。
    用户的请求将依次通过这四层的处理,不能跳过其中任何一层。
    在这里插入图片描述
    优点

        结构简单,容易理解和开发
        不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
        每一层都可以独立测试,其他层的接口通过模拟解决
    

    缺点

        一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
        部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
        软件升级时,可能需要整个服务暂停
        扩展性差。用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难
    

    2)事件驱动架构

    事件(event)是状态发生变化时,软件发出的通知。

    事件驱动架构(event-driven architecture)就是通过事件进行通信的软件架构。它分成四个部分。
    在这里插入图片描述

    事件队列(event queue):接收事件的入口
    分发器(event mediator):将不同的事件分发到不同的业务逻辑单元
    事件通道(event channel):分发器与处理器之间的联系渠道
    事件处理器(event processor):实现业务逻辑,处理完成后会发出事件,触发下一步操作
    

    对于简单的项目,事件队列、分发器和事件通道,可以合为一体,整个软件就分成事件代理和事件处理器两部分。
    在这里插入图片描述
    优点

        分布式的异步架构,事件处理器之间高度解耦,软件的扩展性好
        适用性广,各种类型的项目都可以用
        性能较好,因为事件的异步本质,软件不易产生堵塞
        事件处理器可以独立地加载和卸载,容易部署
    

    缺点

        涉及异步编程(要考虑远程通信、失去响应等情况),开发相对复杂
        难以支持原子性操作,因为事件通过会涉及多个处理器,很难回滚
        分布式和异步特性导致这个架构较难测试
    

    3)微核架构

    微核架构(microkernel architecture)又称为"插件架构"(plug-in architecture),指的是软件的内核相对较小,主要功能和业务逻辑都通过插件实现。
    在这里插入图片描述
    内核(core)通常只包含系统运行的最小功能。插件则是互相独立的,插件之间的通信,应该减少到最低,避免出现互相依赖的问题。

    优点

        良好的功能延伸性(extensibility),需要什么功能,开发一个插件即可
        功能之间是隔离的,插件可以独立的加载和卸载,使得它比较容易部署,
        可定制性高,适应不同的开发需要
        可以渐进式地开发,逐步增加功能
    

    缺点

        扩展性(scalability)差,内核通常是一个独立单元,不容易做成分布式
        开发难度相对较高,因为涉及到插件与内核的通信,以及内部的插件登记机制
    

    4)微服务架构

    微服务架构(microservices architecture)是服务导向架构(service-oriented architecture,缩写 SOA)的升级。

    每一个服务就是一个独立的部署单元(separately deployed unit)。这些单元都是分布式的,互相解耦,通过远程通信协议(比如REST、SOAP)联系。
    在这里插入图片描述
    微服务架构分成三种实现模式。

        RESTful API 模式:服务通过 API 提供,云服务就属于这一类
        RESTful 应用模式:服务通过传统的网络协议或者应用协议提供,背后通常是一个多功能的应用程序,常见于企业内部
        集中消息模式:采用消息代理(message broker),可以实现消息队列、负载均衡、统一日志和异常处理,缺点是会出现单点失败,消息代理可能要做成集群
    

    优点

        扩展性好,各个服务之间低耦合
        容易部署,软件从单一可部署单元,被拆成了多个服务,每个服务都是可部署单元
        容易开发,每个组件都可以进行持续集成式的开发,可以做到实时部署,不间断地升级
        易于测试,可以单独测试每一个服务
    

    缺点

        由于强调互相独立和低耦合,服务可能会拆分得很细。这导致系统依赖大量的微服务,变得很凌乱和笨重,性能也会不佳。
        一旦服务之间需要通信(即一个服务要用到另一个服务),整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类,一种解决方案是把它们拷贝到每一个服务中去,用冗余换取架构的简单性。
        分布式的本质使得这种架构很难实现原子性操作,交易回滚会比较困难。
    

    5)云架构

    云结构(cloud architecture)主要解决扩展性和并发的问题,是最容易扩展的架构。

    它的高扩展性,主要原因是没使用中央数据库,而是把数据都复制到内存中,变成可复制的内存数据单元。然后,业务处理能力封装成一个个处理单元(prcessing unit)。访问量增加,就新建处理单元;访问量减少,就关闭处理单元。由于没有中央数据库,所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里,最好要进行数据持久化。

    这个模式主要分成两部分:处理单元(processing unit)和虚拟中间件(virtualized middleware)。

        处理单元:实现业务逻辑
        虚拟中间件:负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
    

    在这里插入图片描述
    虚拟中间件又包含四个组件。

        消息中间件(Messaging Grid):管理用户请求和session,当一个请求进来以后,决定分配给哪一个处理单元。
        数据中间件(Data Grid):将数据复制到每一个处理单元,即数据同步。保证某个处理单元都得到同样的数据。
        处理中间件(Processing Grid):可选,如果一个请求涉及不同类型的处理单元,该中间件负责协调处理单元
        部署中间件(Deployment Manager):负责处理单元的启动和关闭,监控负载和响应时间,当负载增加,就新启动处理单元,负载减少,就关闭处理单元。
    

    优点

        高负载,高扩展性
        动态部署
    

    缺点

        实现复杂,成本较高
        主要适合网站类应用,不合适大量数据吞吐的大型数据库应用
        较难测试
    
    展开全文
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    像学写文章一样,在学会字、词、句之后,就应上升到段落...软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。  软件设计人员学习软件架构知识旨在站在...
  • 软件架构详解(附图)

    万次阅读 多人点赞 2016-05-24 15:31:21
    软件架构(software architecture) 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。...
  • 软件构架、架构和框架的区别

    万次阅读 2004-08-02 09:37:00
    软件框架(Software Framework)介绍 面向某领域(包括业务领域,如ERP,和计算领域,如GUI)的、可复用的“半成品”软件,它实现了该领域的共性部分,并提供一系列定义良好的可变点以保证灵活性和可扩展性。...
  • 软件框架理解

    千次阅读 2019-03-01 22:18:49
    一、软件框架 一个公司是由公司中的各部部门来组成的,每一个部门拥有特定的职能,部门与部门之间通过相互的配合来完成让公司运转起来。 一个软件框架是由其中各个软件模块组成的,每一个模块都有特定的功能,模块...
  • 软件框架结构模板Reference 分域 分界 分层 分类 说明 划分 解释 API (Application Program Interface) 应用程序编程接口,对客户提供 SDI (Software Development ...
  • 每个人可能都会有自己的框架,但是法无定法,万法归宗,下面小白给出自己做开发时使用的软件框架。你既可以直接拿去使用,也可以在此基础上开创属于你的框架。 下面讲述的框架,来自小白使用的机器人,是用C++语言...
  • TDA2x软件框架分析

    千次阅读 2019-01-29 13:57:08
    TDA系列SOC采用异构多核设计,架构复杂,上手比较困难,本文将结合本人对TDA2xx开发SDK(vision_SDK)的理解,对TDA软件框架做一个描述,抛砖引玉做一个指引性的指导文章,方便同在TDA平台做开发的各位小伙伴。...
  • 基于Qt的软件框架设计

    万次阅读 2017-06-30 08:25:32
    Qt软件框架-- 适用于一般的数据采集与控制系统
  • 软件框架

    千次阅读 2011-12-13 19:18:28
    软件框架 -转 ( 本文源自《.NET通信框架的设计、实现与应用》书稿第一章内容,未经许可,不得转载。)  转自zhuweisky  框架和类库等概念的出现都是源于人们对复用的渴望。“不要重复发明轮子”,成了...
  • 软件框架和软件架构的区别?

    千次阅读 2017-02-08 17:43:23
    软件框架和软件架构的区别?  初学java,遇到jdk,sdk概念:软件开发工具包(外语首字母缩写:SDK、外语全称:Software Development Kit)一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、...
  • 软件框架、架构、模式之我见

    千次阅读 2004-12-10 23:18:00
    软件框架、架构、模式之我见软件框架软件框架就是Software Frameworks,它定义了软件系统在某个平台上为完成某项功能所提供普遍操作、以及这些普遍操作的内在实现过程。换一种说法,软件框架提供了若干操作接口,...
  • 我的嵌入式软件开发框架浅见

    万次阅读 2019-09-01 20:30:03
    因主要是从事应用软件开发,现在讲的是嵌入式应用软件框架。一般好的程序框架,不单单只是应用软件的框架,是一个系统的。如linux系统架构,由于本人才疏学浅只能自我编写个应用程序的浅见。 1.需要有分离分层的...
  • 什么是软件框架

    千次阅读 2012-03-13 17:26:15
    框架是一个应用程序的半成品。框架提供了可在应用程序之间共享的可覆用的公共结构。开发者把框架融入他们自己的应用程序,并...而且,框架一般是成熟的,不断升级的软件。  可以说,一个框架是一个可复用的设计构件,
  • 基于Qt软件框架设计

    千次阅读 2019-04-23 11:56:01
    Qt,在很多人的认识里是一个做界面的框架,只用来做界面,而后端往往是用别的来实现。在本人的实践中, 我把界面与后端的实现都用Qt来实现了。 2、软件分层 一般来说,我们的软件架构会很成很多层,这里我们分三层...
  • 软件框架以及编码规范说明文档

    千次阅读 2005-07-13 09:56:00
    1 文档简介 此文档主要是描述软件架构和编码的技术规范。... 2 软件框架2.1 框架介绍本框架主要是基于Hibernate 3.0 + Struts 1.2.x + Servlet 2.4 + Jsp 2.0 + JSTL 1.2 ( Spring 1.2)构建而成。推荐使用ecli
  • 软件架构和软件框架-用例模型设计应用(1)来自:网上软件架构是一种思想,一个系统蓝图,对软件结构组成的规划和职责设定。而软件框架是一个实现,一个半成品,是针对一个特定问题的解决方案和辅助工具。这一篇讲...
1 2 3 4 5 ... 20
收藏数 590,138
精华内容 236,055
关键字:

软件框架