精华内容
参与话题
问答
  • 软件架构和架构风格

    万次阅读 多人点赞 2018-08-31 20:08:07
    今天给大家分享一下架构方面的东西。都是一些相对基础的东西,有错误的话请指正。 首先我们来介绍一下什么是架构架构一词来源于建筑,代表系统高层次的一些设计角色。比如建筑领域的一栋大楼的架构,指的就是大楼...

    今天给大家分享一下架构方面的东西。都是一些相对基础的东西,有错误的话请指正。

    首先我们来介绍一下什么是架构。架构一词来源于建筑,代表系统高层次的一些设计角色。比如建筑领域的一栋大楼的架构,指的就是大楼有多高、每一层有多高、有多少层、每一层包括多少房间、有几部电梯、消防通道在哪里、哪里是卫生间、哪里走线路、给排水管道在哪里等等。都是一些高层次的决策。这些高层次的决策从更高的层面为我们描述了这个系统的梗概、也可以说描绘了系统的蓝图。是对系统高层次的抽象。

    架构也被称为体系结构,有很多的定义。个人比较认可的一个定义:架构=构件+交互

    这又引出来什么是构件。所谓的构件是指具有一定功能,能独立提供服务或者跟其他构件配合提供服务。构件可大可小,大的可以是独立的服务、系统、子系统、组件。小的可以是模块、对象或方法。在不同的抽象层次上我们能够得到不同的构件。这点跟面向对象中的对象很类似。

    从上面架构的定义我们能知道,所谓的架构,就是用来定义软件系统有哪些组件、如何划分组件、组件的职责是什么,同时还用来定义构件之间的交互方式。是通过MQ、RPC或者通过http、或者是直接调用。

    上面说的是架构的定义,还要介绍另一个概念:架构风格,或者说体系结构风格。

    说到风格,我们说一个人具有什么样的穿衣风格时就可以大概知道搭配方式。比如某人的穿衣风格很骚,我们很容易就想到齐逼短裙、低胸。。。

    大家对架构风格不熟悉,但是一定熟悉设计模式。

    所谓的设计模式就是前人针对特定问题的一套解决方案,或者说是套路。

    架构风格也被称为架构模式,换句话说是架构方面的套路。也可以说是前人在架构方面总结出来的,用以解决特定问题的方法。下面来看下官方定义:架构风格是用来描述某一特定应用领域软件系统的组织方式的惯用法,反映了众多系统所具有的结构和语义特性,指导如何使用构件构造一个完整的系统。

    这个定义很好,看了跟不看一样。。。都不懂。。总而言之就是针对架构方面的一些套路。总结这些模式的目的是什么呢?是重用!

    软件方面的模式可以分为三个层次:代码模式、设计模式、架构模式。

    代码模式也可以说是编码时的套路,一些技巧。是最低层次的套路。只能影响某一方法或类中的一些细节。

    设计模式解决了一般性的设计问题,影响一个模块内部。是中等层次的重用策略。

    架构模式最高层层次的重用策略,实现定义好一些子系统、层,指定他们的责任,并给出把它们组织在一起的法则和指南。

    下面我们来介绍一下一些常用的架构风格。包括:管道过滤器风格、面向对象风格、分布式架构、SOA风格、微服务风格等等。

    今天我们主要介绍SOA和微服务风格。

    SOA 是Service Orientated Architure的缩写,即面向服务架构。表示每一个功能都是通过一个独立的服务来提供,服务定义了明确的可调用接口,服务之间的编排调用完成一个完整的业务。

    微服务是指可以部署在单个或多个服务器上的具有一定业务功能的轻量的服务。

    在介绍它们之前,先介绍一下架构风格的演化过程,就很容易理解架构风格了。

    首先我们来介绍一下单体应用。针对单体的网络应用,我们一般会把它进行分层,比如这里我们把它分成ui层、业务逻辑层和DAO层。

                                      

     

    分层的好处是什么呢?

    1.通过分离关注点,降低复杂度。

    人处理复杂问题的能力是有限的。通过分层可以把相同的职责划分在一起,分析某一层时可以只关注当前层,而不用管其他层。这也是面向对象的一大优点。

    2.各层只能与相邻层交互,只要接口定义好,内聚性高耦合度小。功能集中。每一层可以很容易替换。

    3.不同的层可以分别部署。

    分层只是从逻辑视图方面划分系统有什么逻辑组件。我们可以把不同的层放在不同的机器上。架构的物理视图是用来描述逻辑组件部署到物理机器上的策略。

    在单体式应用中,我们不但水平方向上进行分层,还会在垂直方向上对某一层划分模块。

    类似下图。

                                  

     

    下面来介绍下演化到分布式应用。

    分布式应用将系统部署到多台机器、多个位置。也是一种垂直纬度的划分。

    有以下几种划分的方法:

    1.垂直方向不划分,整体部署。前面通过负载均衡服务如ngix进行负载均衡处理。

    缺点:

    a.某些业务需要扩充,只能整体部署。

    b.某个模块需要升级时只能整体部署。

    2.垂直方向切分成多个应用。每个应用分别部署,共同组成完成的系统。

    更进一步,如果我们在垂直方向上切分的很细。就变成了下面的结构。

                                    

     

    细粒度切分之后就变成了SOA和微服务。

    通过上面的单体式架构风格的演化过程能够发现,SOA和微服务架构也是分布式架构的一种。但是各有侧重。

    SOA架构的几个特点:

    1.松耦合

    调用者和服务提供者通过服务注册寻址和调用,耦合度小。

    2.接口标准化

    SOA中的每个服务遵循一定的接口规范。这些协议是跨平台、跨语言的。

    3.粗粒度

    SOA中的服务应该尽量的面向业务,与一般定义api提供小粒度的接口的原则不同。

    SOA是一种思想、一组规范。它的实现是通过WebService技术来实现的 。

    不知道大家有没有调用过Webservice接口。C++调用的话有以下几个步骤:

    1.获得服务的wsdl文件。

    2.使用gsoap工具生成服务接口头文件。

    3.使用gsoap工具生成服务接口代理的实现。

    4.在代码里直接对第三步生成的实现进行调用即可。(要设置服务所在的地址)

    在webservice中有以下协议栈

                              

     

    UDDI是Universal Description Discovery and Integration的缩写。表示通用发现和描述协议。

    SOA中包含三种角色:

    服务提供者、服务调用者和服务注册中心。

    服务提供者提供服务,并将服务注册到服务注册中心。

    服务调用者通过wsdl中的描述调用服务提供者接口。分两次使用,第一次是在开发时通过wsdl获得服务提供的接口进行开发。第二次是在运行时通过wsdl去服务注册中心查询服务位置。

    服务注册中心是连接服务提供者和服务调用者的纽带。可选的角色。可选时服务调用者静态绑定服务并调用。

    以上是对SOA服务架构的简单介绍。

    下面介绍微服务架构。

    微服务架构跟SOA架构是很像的,都是将一个粗粒度的应用拆分成细粒度的应用。拆分的粒度和方法不同。

    相同点:

    1.微服务是对SOA思想的升华。

    2.两者都是语言无关、跨平台的。

    不同点:

    1.微服务强调按照领域进行拆分应用,拆分后的应用可以敏捷开发和部署。

    2.微服务倡导服务的细粒度,切分到不能再分为止。SOA只是在接口方面要求规范化,尽量粗粒度。

    3.微服务把应用拆分成单个服务,借助容器技术,应用从上至下完全独立,甚至每个应用可以有自己独立的DB。开发运维一体化。而SOA只要求接口独立。内部实现可以不独立。

    4.微服务倡导去中心化,将所有的逻辑包括负载均衡、动态路由、服务发现、熔断等通用逻辑放在服务内部。而SOA

    微服务的service mesh

    服务网格。用来治理微服务复杂性的技术和工具。与服务一起部署,但是对服务透明,形成一个分布式的代理网络。

    以sidecar形式部署在服务的两侧,所有的服务通过sidecar进行通信。

    sidecar的中文意思是旁边有箱子的摩托车,类似当年鬼子进村的摩托车。sidecar可以实现负载均衡、服务发现、动态路由、熔断等。是去中心的化的核心。

                                

     

    展开全文
  • 4G网络架构

    万次阅读 2016-05-21 20:00:15
    1,4G是第四代移动通信技术,该技术包括TD-LTE和FDD-LTE两种制式,严格意义上来讲LTE只是3.9G,只有升级版的LTE Advanced才满足国际电信联盟对4G的要求。 4G是集3G与WLAN于一体,并能够快速传输数据、高质量、...
    
    

    14G是第四代移动通信技术,该技术包括TD-LTEFDD-LTE两种制式,严格意义上来讲LTE只是3.9G,只有升级版的LTE Advanced才满足国际电信联盟对4G的要求。

    4G是集3GWLAN于一体,并能够快速传输数据、高质量、音频、视频和图像等。4G能够以100Mbps以上的速度下载,比目前的家用宽带ADSL4兆)快25倍,并能够满足几乎所有用户对于无线服务的要求。

    2LTE网络结构如下:

    整个LTE网络从接入网和核心网方面分为E-UTRANEPC两个大的部分。相比于3G技术,对应于3G技术中的UTRANEPC部分。

    1)E-UTRANEvolved Universal Terrestrial RadioAccess Network

    E-UTRAN在系统性能和能力方面的研究目标主要是以下几点:

    A:更高的空中接口峰值速率以及频谱效率。

    B:在E-UTRAN中,eNodeB之间底层采用IP传输,在逻辑上通过X2 接口互相连接,即形成Mesh 型网络。这样的网络结构设计主要用于支持UE 在整个网络内的移动性,保证用户的无缝切换。而每个eNodeB 通过S1 接口和移动性管理实体/接入网关(MobilityManagement Entity (MME)/Serving Gateway(S-GW))连接,一个eNodeB 可以和多个MME/S-GW 互连,反之亦然。

    C:在E-UTRAN网络中,由于没有了RNC,整个E-UTRAN的空中接口协议结构与原来的UTRAN相比有了较大的不同,特别是不同功能实体的位置出现了很多的变化。原来由RNC承担的功能被分散到了eNodeBMME/S-GW上。

    2EPCEvolvedPacket Core

    EPC 核心网主要由移动性管理设备(MME服务网关(S-GW、分组数据网关(P-GW)、存储用户签约信息的HSS、策略控制单元(PCRF)等组成,其中S-GW P-GW可以合设,也可以分设。EPC 核心网架构秉承了控制与承载分离的理念,将分组域中SGSN 的移动性管理、信令控制功能和媒体转发功能分离出来,分别由两个网元来完成,其中,MME 负责移动性管理、信令处理等功能,S-GW 负责媒体流处理及转发等功能P-GW 则仍承担GGSN 的职能。LTE 无线系统中取消了RNC 网元,将其功能分别移至基站eNodeB 和核心网网元,eNodeB 将直接通过S1 接口与MMES-GW 互通,简化了无线系统的结构。

    34G网络架构的变化

    1)实现了控制与承载的分离,MME负责移动性管理、信令处理等功能,S-GW负责媒体流处理及转发等功能。

    2)核心网取消了CS(电路域),全IPEPCEvolved Packet Core,移动核心网演进)支持各类技术统一接入,实现固网和移动融合(FMC),灵活支持VoIP及基于IMS多媒体业务,实现了网络全IP化。

    3)取消了RNC,原来RNC功能被分散到了eNodeB和网关(GW)中,eNodeB直接接入EPCLTE网络结构更加扁平化,降低了用户可感知的时延,大幅提升用户的移动通信体验。

    4)接口连接方面,引入S1-FlexX2接口,移动承载需实现多点到多点的连接,X2是相邻eNB间的分布式接口,主要用于用户移动性管理;S1-Flex是从eNBEPC的动态接口,主要用于提高网络冗余性以及实现负载均衡。

     

    5)传输带宽方面:较3G基站的传输带宽需求增加10倍,初期200-300Mb/s,后期将达到1Gb/s

    43G4G系统参数的比较

     

     

     

    展开全文
  • 软件架构模式之分层架构

    万次阅读 2015-04-19 23:53:59
    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个...

    本章内容出自《软件架构模式》第一章,该书由 开发技术前线 项目组成员翻译,更多内容请访问 《软件架构模式》中文版pdf

    简介

    对程序员来说很常见一种情况是在没有合理的程序架构时就开始编程,没有一个清晰的和定义好的架构的时候,大多数开发者和架构师通常会使用标准式的传统分层架构模式(也被称为多层架构)——通过将源码模块分割为几个不同的层到不同的包中。不幸的是,这种编码方式会导致一系列没有组织性的代码模块,这些模块缺乏明确的规则、职责和同其他模块之间的关联。这通常被称为架构大泥球。

    应用程序缺乏合理的架构一般会导致程序过度耦合、容易被破坏、难以应对变化,同时很难有一个清晰的版本或者方向性。这样的结果是,如果你没有充分理解程序系统里每个组件和模块,就很难定义这个程序的结构特征。有关于程序的部署和维护的基本问题都难以回答,比如:程序架构是什么规模?应用程序有什么性能特点?应用程序有多容易应对变化?应用程序的部署特点是什么?架构是如何反应的?

    架构模式帮助你定义应用程序的基本特征和行为。例如,一些架构模式会让程序自己自然而然地朝着具有良好伸缩性的方向发展,而其他架构模式会让程序朝着高度灵活的方向发展。知道了这些特点,了解架构模式的优点和缺点是非常必要的,它帮助我们选择一个适合自己特定的业务需求和目标的的程序。

    作为一个架构师,你必须证明你的架构模式的决策是正确的,特别是当需要选择一个特定的体系结构模式或方法的时候。这本迷你书的目的就是给你足够的信息让你去做出正确的架构决策。

    第一章 分层架构

    分层架构是一种很常见的架构模式,它也叫N层架构。这种架构是大多数Jave EE应用的实际标准,因此很多的架构师,设计师,还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。

    模式分析

    分层架构模式里的组件被分成几个平行的层次,每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种,大多数的结构都分成四个层次:展示层,业务层,持久层,和数据库层。如表1-1,有时候,业务层和持久层会合并成单独的一个业务层,尤其是持久层的逻辑绑定在业务层的组件当中。因此,有一些小的应用可能只有3层,一些有着更复杂的业务的大应用可能有5层或者更多的分层。

    分层架构中的每一层都着特定的角色和职能。举个例子,展示层负责处理所有的界面展示以及交互逻辑,业务层负责处理请求对应的业务。架构里的层次是具体工作的高度抽象,它们都是为了实现某种特定的业务请求。比如说展示层并不需要关心怎样得到用户数据,它只需在屏幕上以特定的格式展示信息。业务层并不关心要展示在屏幕上的用户数据格式,也不关心这些用户数据从哪里来。它只需要从持久层得到数据,执行与数据有关的相应业务逻辑,然后把这些信息传递给展示层。

    这里写图片描述

    分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说,展示层的组件只会处理展示逻辑,业务层中的组件只会去处理业务逻辑。多亏了组件分离,让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发,测试,管理和维护。

    关键概念

    注意表1-2中每一层都是封闭的。这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子,从展示层传递来的请求首先会传递到业务层,然后传递到持久层,最后才传递到数据层。

    这里写图片描述

    那么为什么不允许展示层直接访问数据层呢。如果只是获得以及读取数据,展示层直接访问数据层,比穿过一层一层来得到数据来的快多了。这涉及到一个概念:层隔离。

    层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了,假如持久层中的SQL变化了,这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合,组件之间互相依赖。这种架构会非常的难以维护。

    从另外一个方面来说,分层隔离使得层与层之间都是相互独立的,架构中的每一层的互相了解都很少。为了说明这个概念的牛逼之处,想象一个超级重构,把展示层从JSP换成JSF。假设展示层和业务层的之间的联系保持一致,业务层不会受到重构的影响,它和展示层所使用的界面架构完全独立。

    然而封闭的架构层次也有不便之处,有时候也应该开放某一层。如果想往包含了一些由业务层的组件调用的普通服务组件的架构中添加一个分享服务层。在这个例子里,新建一个服务层通常是一个好主意,因为从架构上来说,它限制了分享服务访问业务层(也不允许访问展示层)。如果没有隔离层,就没有任何架构来限制展示层访问普通服务,难以进行权限管理。

    在这个例子中,新的服务层是处于业务层之下的,展示层不能直接访问这个服务层中的组件。但是现在业务层还要通过服务层才能访问到持久层,这一点也不合理。这是分层架构中的老问题了,解决的办法是开放某些层。如表1-3所示,服务层现在是开放的了。请求可以绕过这一层,直接访问这一层下面的层。既然服务层是开放的,业务层可以绕过服务层,直接访问数据持久层。这样就非常合理。

    1-3

    开放和封闭层的概念确定了架构层和请求流之间的关系,并且给设计师和开发人员提供了必要的信息理解架构里各种层之间的访问限制。如果随意的开放或者封闭架构里的层,整个项目可能都是紧耦合,一团糟的。以后也难以测试,维护和部署。

    示例

    为了演示分层架构是如何工作的,想象一个场景,如表1-4,用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流,红色箭头显示用户数据的返回流的方向。在这个例子中,用户信息由客户数据和订单数组组成(客户下的订单)。

    用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的,或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求,它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息,调用order dao来得到订单信息。这些模块会执行SQL语句,然后返回相应的数据给业务层。当 customer object收到数据以后,它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。

    这里写图片描述

    从技术的角度来说,有很多的方式能够实现这些模块。比如说在Java平台中,customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects),或者可以用MyBatis,还可以用JDBC或者Hibernate 查询。Microsoft平台上,customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块,用ADO来实现用户和订单数据的访问模块。

    注意事项

    分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构,分层架构是再好不过的了。然后,从架构的角度上来说,选择这个模式还要考虑很多的东西。

    第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
    在这个模式中,请求流只是简单的穿过层次,不留一点云彩,或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层,业务层也只是传递了这个请求到持久层,持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回,不会有任何的二次处理,返回到界面上。

    每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越,百分之八十的请求会做一些业务逻辑操作。然而,如果这个比例反过来,大部分的请求都是仅仅穿过层,不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离,项目会变得难以控制。

    模式分析

    下面的的表里分析了分层架构的各个方面。

    整体灵活性

    评级:低
    分析:总体灵活性是响应环境变化的能力。尽管分层模式中的变化可以隔绝起来,想在这种架构中做一些也改变也是并且费时费力的。分层模式的笨重以及经常出现的组件之间的紧耦合是导致灵活性降低的原因。

    易于部署

    评级:低
    分析:这取决于你怎么发布这种模式,发布程序可能比较麻烦,尤其是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划,在非工作时间或者周末进行发布。因此。分层模式导致应用发布一点也不流畅,在发布上降低了灵活性。

    可测试性

    评级:高
    分析:因为组件都处于各自的层次中,可以模拟其他的层,或者说直接去掉层,所以分层模式很容易测试。开发者可以单独模拟一个展示组件,对业务组件进行隔绝测试。还可以模拟业务层来测试某个展示功能。

    性能

    评级:低
    分析:尽管某些分层架构的性能表现的确不错,但是这个模式的特点导致它无法带来高性能。因为一次业务请求要穿越所有的架构层,做了很多不必要的工作。

    伸缩性

    评级:低
    分析:由于这种模式以紧密耦合的趋势在发展,规模也比较大,用分层架构构建的程序都比较难以扩展。你可以把各个层分成单独的物理模块或者干脆把整个程序分成多个节点来扩展分层架构,但是总体的关系过于紧密,这样很难扩展。

    易开发性

    评级:容易
    分析:在开发难度上面,分层架构得到了比较高的分数。因为这种架构对大家来说很熟悉,不难实现。大部分公司在开发项目的都是通过层来区分技术的,这种模式对于大多数的商业项目开发来说都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你可以Google一下查查这个有趣的联系。

    展开全文
  • 软件架构的10个常见模式

    万次阅读 多人点赞 2019-04-03 12:18:00
    企业规模的软件系统该如何...根据维基百科:架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式,但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。 分...
        

    640?wx_fmt=png

    企业规模的软件系统该如何设计呢?在开始写代码之前,我们需要选择一个合适的架构,这个架构将决定软件实施过程中的功能属性和质量属性。因此,了解软件设计中的不同架构模式对我们的软件设计会有较大的帮助。


    什么是架构模式?根据维基百科:架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式,但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。

    1. 分层模式(Layered pattern)

    2. 客户端-服务器模式(Client-server pattern)

    3. 主从模式(Master-slave pattern)

    4. 管道-过滤器模式(Pipe-filter pattern)

    5. 代理模式(Broker pattern)

    6. 点对点模式(Peer-to-peer pattern)

    7. 事件-总线模式(Event-bus pattern)

    8. 模型-视图-控制器模式(Model-view-controller pattern)

    9. 黑板模式(Blackboard pattern)

    10. 解释器模式(Interpreter pattern)


    1. 分层模式

    此模式用于可分解为子任务的结构化程序,每个子任务都位于特定的抽象层级,每一层都为上一层提供服务。一般信息系统最常见的4个层次如下。

    • 表示层(也称为UI层)

    • 应用层(也称为服务层)

    • 业务逻辑层(也称为领域层)

    • 数据访问层(也称为持久层)


    应用场景:

    • 一般的桌面应用程序

    • 电子商务web应用程序

    • 一般的移动App

    640?wx_fmt=jpeg

    分层模式


    2. 客户端-服务器模式

    这种模式由两部分组成:服务器和多个客户端。服务器将向多个客户端提供服务。客户端从服务器请求服务,服务器向这些客户端提供相关服务。此外,服务器继续侦听客户端请求。


    应用场景:

    • 电子邮件、文档共享和银行等在线应用程序。

    • 基于IPC的应用程序

    640?wx_fmt=png

    客户端-服务器模式


    3.主从模式

    这种模式由两部分组成:主节点和从节点。主节点将工作分配给相同的从节点,并根据从节点返回的结果计算最终结果。


    应用场景:

    • 在数据库复制中,主数据库被视为权威源数据库,从数据库与之同步。

    • 通过总线连接到计算机系统(主驱动器和从驱动器)的外围设备。

    • 进程内的多线程应用。

    640?wx_fmt=jpeg

    主-从模式


    4.管道-过滤器模式

    这种模式可用于构造生成和处理数据流的系统。每个处理步骤都包含一个过滤器组件。要处理的数据通过管道传递。这些管道可用于缓冲或同步目的。


    应用场景:

    • 编译器。连续过滤器执行词法分析、词法解析、语义分析和代码生成。

    • 生物信息学的工作流

    • 工具链式的应用程序

    640?wx_fmt=jpeg

    管道-过滤器模式


    5. 代理模式

    这种模式通过解耦组件来构造分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责协调组件之间的通信。服务器向代理发布功能(服务和特征)。客户端向代理请求服务,然后代理将客户端重定向到合适的服务。需要注意broker,agent,proxy以及delegate的区别。


    应用场景:

    • 消息代理软件,例如:Apache ActiveMQ、Apache Kafka、RabbitMQ和JBoss消息传递。

    • 网络传输中的代理软件。

    640?wx_fmt=jpeg

    代理模式


    6. P2P模式

    在这种模式中,每个组件都称为对等节点。对等节点既可以作为客户机(从其他对等节点请求服务),也可以作为服务器(向其他对等节点提供服务)。对等节点可以充当单个客户机或服务器,也可以同时充当客户机和服务器,并且可以随着时间变化动态地更改角色。


    使用场景:

    • 文件共享网络,例如Gnutella和G2等。

    • 多媒体协议,如P2PTV和PDTP。


    640?wx_fmt=jpeg

    P2P模式


    7. 事件-总线模式

    这种模式也被称为订阅发布模式,主要处理事件,有4个主要组件:事件源、事件监听者、通道和事件总线。事件源将消息发布到事件总线上的特定通道,监听者订阅特定的通道。消息发布到监听者之前订阅的通道,监听者将收到消息的通知。


    使用场景:

    • 安卓开发

    • 通知服务

    • 注册中心

    640?wx_fmt=jpeg

    事件-总线模式


    8. 模型-视图-控制器模式

    这种模式,也称为MVC模式,将一个交互应用程序分为三个部分:

    • 模型-包含核心功能和数据

    • 视图——向用户显示信息(可以定义多个视图)

    • 控制器——处理来自用户的输入

    这样做是为了将信息的内部表示、信息呈现给用户的方式、接受用户输入的方式分离开来。这种模式解耦组件并允许有效的代码重用。


    应用场景:

    • 一般的web应用程序架构

    • Django和Rails等Web框架

    • 一般的GUI 应用程序

    640?wx_fmt=png

    模型-视图-控制器模式


    9. 黑板模式

    这种模式对于没有确定解决方案策略的问题非常有用。黑板图案由三个主要部分组成:

    • 黑板:一个结构化的全局内存,包含来自解决方案空间的对象

    • 知识源:具有自己表示形式的专门化模块

    • 控制组件:选择、配置和执行模块

    所有的组件都可以到达黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据,并通过与现有的知识源进行模式匹配找到这些数据。


    应用场景:

    • 语音识别

    • 车辆识别及追踪

    • 蛋白质结构识别

    • 声纳信号的解释

    640?wx_fmt=jpeg

    黑板模式


    10. 解释器模式

    这种模式用于设计一个解释专用语言编写的程序组件。它主要指定如何评估每一行程序,即用特定语言编写的句子或表达式。其基本思想是语言的每个符号都有一个类。


    应用场景:

    • 数据库查询语言,如SQL。

    • 用于描述通信协议的语言。

    640?wx_fmt=jpeg

    解释器模式


    下面的表格总结了每种架构模式的优缺点。

    640?wx_fmt=png

    希望觉得这篇文章有用,我们也很想听听你的想法。

    展开全文
  • 软件架构师求职:我2017年10月6号入职,这4个月,仍有4个邀请,都拒绝了。 如何成为软件架构师:理论联系实践。 软件架构师培训:不需要! 何志丹  2014年过了软考的软件架构师,2016年4月25号到极点3维...
  • PHP深入理解-PHP架构布局

    千次阅读 2018-12-16 15:40:10
    本文基于《PHP 内核剖析》与 《PHP7底层设计与源码实现》所记笔记。 对PHP内核的深入理解有助于我们对PHP的整体认识,对于业务层初期发展我们... 执行流程 解析为Token将语法转换为抽象语法树将语法树转换OpcodesS...
  • java架构师学习路线图

    千次阅读 2019-04-04 14:22:22
    一个Java程序员不想要成为一个Java “old”程序员,唯一的出路就是学习Java技术的脚步永不停滞,让自己成为一个Java架构师,成为一个公司真正的技术大咖,平时上班泡泡茶、喝喝咖啡,度过了愉快潇洒的一天,每当所有...
  • 软件架构——架构师的职责

    万次阅读 2009-10-11 10:27:00
    软件架构——架构师的职责 一、架构师定义架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。架构师的主要责任是提供开发人员...
  • 软件架构设计---软件架构概述

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

    万次阅读 热门讨论 2010-11-04 22:29:00
    在这个过程当中,架构师的水平和软件体系架构本身的灵活性,就会处于一个很核心的位置。太多的软件,因为架构的问题,造成产品发布日期延迟,或者项目交付工期延迟,给测试、实施、售后等工作等造成一系列的问题。
  • Saas系统架构的思考,多租户Saas架构设计分析

    万次阅读 多人点赞 2019-06-14 13:39:35
    毕竟Saas相对传统软件的优势非常明显。 最近一年,有幸架构一个Crm saas 系统,上线了几个月来,各方面都比满意。整个系统创建过程,踩了很多坑,收获也比较多。总结一下Saas系统架构一些特点: Saas系统分...
  • 软件架构的历程

    千次阅读 2009-04-29 08:32:00
    软件架构的历程 计算机科学的发展历程可以追溯到第一代电子管计算机(1945年~1956年)。1946年2月15日世界上第一台重达30顿的计算机ENIAC(Electronic Numerical Integrator and Computer)正式在费城公布于世,它...
  • 软件架构对于复杂实时系统的开发已日益变得更加重要。在这个新的系列中,了解为什么以及应该如何编写软件架构文档说明。您将了解为任何中大型软件开发项目编写文档说明的五个不同视图或方面。这是本系列中的第一篇...
  • 软件架构设计---软件架构视图

    万次阅读 2018-09-18 07:38:21
    软件架构视图  从软件架构本身的特点出发讨论了架构建模及与特定应用领域密切相关的架构风格。本节将从对架构编档的角度对软件架构视图及其风格进行讨论。 1 软件视图的分类   现代软件系统非常复杂,通常在...
  • 软件架构设计---软件架构风格

    千次阅读 2018-09-17 21:33:52
    软件架构风格  软件架构设计的一个核心问题是能否使用重复的软件架构模式,即能否达到架构级别的软件重用。也就是说,能否在不同的软件系统中,使用同一架构。基于这个目的,学者们开始研究和实践软件架构的风格和...
  • 软件架构设计---软件架构评估

    千次阅读 2018-09-18 07:29:30
    软件架构评估  软件架构评估是在对架构分析、评估的基础上,对架构策略的选取进行决策。它也可以灵活地运用于对软件架构进行评审等工作中。 1 软件架构评估的方法  业界已开发出多种软件架构评估的方法,按...
  • 软件架构之架构定义

    千次阅读 2017-02-23 15:46:48
    软件架构软件架构定义
  • 软件架构之架构视图

    千次阅读 2015-03-26 16:56:42
    软件架构设计运用RUP4+1视图方法进行设计。 4+1架构视图模型是1995年Philippe kruchen在《IEEE software》上发表的题为《The 4+1 View Model of Architecture》文。 主要包括的架构视图如下: 场景视图:也...
  • 软件架构设计之七:软件架构设计

    千次阅读 2013-08-27 20:28:13
    包括软件架构的概念、软件架构的风格、特定领域软件架构、基于架构的软件开发方法、软件架构评估、软件产品线;设计模式的概念、设计模式的组成、模式和软件架构、设计模式分类、设计模式的实现。 2)系统架构设计...
  • 软件架构设计---软件架构文档化

    万次阅读 2018-09-18 07:14:38
    软件架构文档化   记录软件架构的活动就是架构编档过程,也就是架构的文档化。它包含两个方面:一是过程,编档过程能促使架构设计师进一步思考,使得架构更加完善;二是结果,描述架构的文档将作为架构开发的成果...
  • 系统架构与软件架构是一层含义吗

    千次阅读 2009-04-28 15:06:00
    系统架构与软件架构 再深一层分析,无论是建筑工程领域,还是其他工程领域(包括计算机科学),从它们的演化历史来看,直觉上我们似乎能够发现其共同点:即从哲学的角度上来说,它们都是人类为了克服与生俱来的恐惧...
  • 软件架构学习小结

    万次阅读 热门讨论 2010-03-04 22:27:00
    软件架构设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单。本文从架构师职责、软件架构定义、设计架构、评估架构、架构管理等方面来描述...
  • 在不同的架构设计方法中出现的软件架构视图种类很多,本文介绍最常用的两种架构视图——逻辑架构视图和物理架构视图,并通过具体案例的分析说明如何运用它们进行架构设计。当观察和描述事物大局的时候,逻辑架构和...
  • 软件架构介绍

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

    万次阅读 多人点赞 2015-09-06 22:28:18
    1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...
  • 高级嵌入式软件架构设计

    千次阅读 2015-05-13 10:05:38
    • 了解嵌入式架构的常见问题和解决策略 • 了解嵌入式架构设计过程 • 了解嵌入式架构质量评估方法 • 了解常见的嵌入式设计问题的解决方法: o 嵌入式子系统设计 o 嵌入式层次框架设计 o 嵌入式系统...
  • 软件架构发展历程分享

    千次阅读 2018-03-02 00:00:00
    本文来自作者 kimmking 在 GitChat 上分享 「软件架构发展历程分享」,「阅读原文」查看交流实录。编辑 | 哈比什么是架构计算机科学和程序设计的飞速发展,使得软件设计应用到从航空航天到日...
  • 软件架构设计 软件架构是软件抽象发展到一定阶段的产物,从编程的角度,可以清晰地看到软件抽象层次和表达工具的发展历史。 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的...
  • 软件架构的评价准则

    千次阅读 2010-10-13 22:01:00
    对于一个软件系统架构优劣的分析,总要有一些准则,以下是一些粗略的标准: 1. 系统性能 2. 可靠性(容错/健壮性) 3. 可用性 4. 安全性 5. 可修改性(可维护性,可扩展性,结构重组,可...
  • 如果一个软件开发人员,不了解软件架构的演进,会制约技术的选型和开发人员的生存、晋升空间。这里我列举了目前主要的四种软件架构以及他们的优缺点,希望能够帮助软件开发人员拓展知识面。 一、单体架构 单体...

空空如也

1 2 3 4 5 ... 20
收藏数 699,446
精华内容 279,778
关键字:

软件架构