架构_架构图 - CSDN
架构 订阅
架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。架构描述语言(ADL)用于描述软件的体系架构。现在已有多种架构描述语言,如Wright(由卡内基梅隆大学开发),Acme(由卡内基梅隆大学开发),C2(由UCI开发),Darwin(由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 [1] 展开全文
架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。架构描述语言(ADL)用于描述软件的体系架构。现在已有多种架构描述语言,如Wright(由卡内基梅隆大学开发),Acme(由卡内基梅隆大学开发),C2(由UCI开发),Darwin(由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。 [1]
信息
中文名
架构
外文名
Software architecture
别    称
软件架构
架构特性
架构是对存储在Active Directory中的对象类别和属性的描述。对于每一个对象类别来说,该架构定义了对象类必须具有的属性,它也可以有附加的属性,并且该对象可以是它的父对象。可以动态更新的Active Directory 架构。应用程序可以使用新的属性和类扩展该架构,并能立刻使用该扩展。通过在Active Directory 中创建或修改存储在 Active Directory 中的架构对象来完成架构的更新。与Active Directory 中的所有对象一样,架构对象能访问控制列表,因此只有授权的用户才可以更改架构。
收起全文
  • 软件架构(software architecture) 软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。...


    软件架构(software architecture)

    软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口_(计算机科学)来实现。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。



    架构是在组件,彼此间和与环境间的关系,引导设计发展原则中体现的系统的基本结构。

    软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标,作为绘图员画图的基础一样,一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

    软件构架是一个容易理解的概念,多数工程师(尤其是经验不多的工程师)会从直觉上来认识它,但要给出精确的定义很困难。特别是,很难明确地区分设计和构架:构架属于设计的一方面,它集中于某些具体的特征。

    软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统的各个组件,组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

    在“软件构架简介”中,David GArlan和 Mary Shaw认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”

    但构架不仅是结构;IEEEWorking Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在 Rational Unified ProcESs 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    从和目的、主题、材料和结构的联系上来说,软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来实施和管理软件产品的高级设计。软件架构师定义和设计软件的模块化,模块之间的交互,用户界面风格,对外接口方法,创新的设计特性,以及高层事物的对象操作、逻辑和流程。

    一般而言,软件系统的架构(ArchitECture)有两个要素:

    1.它是一个软件系统从整体到部分的最高层次的划分。

    2.一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。

    详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(TASk-flow)。所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。

    建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。

    在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。

     


    根据我们关注的角度不同,可以将架构分成三种:

    1.逻辑架构

    软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等。

    从上面这张图中可以看出,此系统被划分成三个逻辑层次,即表象层次,商业层次和数据持久层次。每一个层次都含有多个逻辑元件。比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。

    2.物理架构

    软件元件是怎样放到硬件上的。

    比如下面这张物理架构图,图中所有的元件都是物理设备,包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等。

    3.系统架构

    系统的非功能性特征,如可扩展性、可靠性、强壮性、灵活性、性能等。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这一工作无疑是架构设计工作中最为困难的工作。

    此外,从每一个角度上看,都可以看到架构的两要素:元件划分和设计决定。

    首先,一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上,以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献,是非常重要的信息。

    其次,进行软件设计需要做出的决定中,必然会包括逻辑结构、物理结构,以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出,就很难更改的。

    根据作者的经验,一个基于数据库的系统架构,有多少个数据表,就会有多少页的架构设计文档。比如一个中等的数据库应用系统通常含有一百个左右的数据表,这样的一个系统设计通常需要有一百页左右的架构设计文档。

     

    我们决定以多种构架视图来表示软件构架。每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。

    构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。这些设计决策必须基于需求以及功能、补充和其他方面的约束。而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。

    构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。它包括:

    1.用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。它是用例模型的子集。

    2.逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。它还包括一些用例实现。它是设计模型的子集。

    3.实施视图:包括实施模型及其从模块到包和层的组织形式的概览。 同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。它是实施模型的子集。

    4.进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。只有在系统具有很高程度的并行时,才需要该视图。在 Rational Unified Process 中,它是设计模型的子集。

    5.部署视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。只有在分布式系统中才需要该视图。它是部署模型的一个子集。构架视图记录在软件构架文档中。您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。对于简单系统,可以省略 4+1 视图模型中的一些视图。

     

    早在1960年代,诸如E·W·戴克斯特拉就已经涉及软件架构这个概念了。自1990年代以来,部分由于在 Rational Software Corporation 和Microsoft内部的相关活动,软件架构这个概念开始越来越流行起来。

    卡内基梅隆大学和加州大学埃尔文分校在这个领域作了很多研究。卡内基·梅隆大学的Mary Shaw和David Garlan于1996年写了一本叫做 Software Architecture perspective on an emerging DIscipline的书,提出了软件架构中的很多概念,例如软件组件、连接器、风格等等。加州大学埃尔文分校的软件研究院所做的工作则主要集中于架构风格、架构描述语言以及动态架构。

    计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。建筑设计基本上包含两点,一是建筑风格,二是建筑模式。独特的建筑风格和恰当选择的建筑模式,可以使得一个建筑独一无二。

    软件与人类的关系是架构师必须面对的核心问题,也是自从软件进入历史舞台之后就出现的问题。与此类似地,自从有了建筑以来,建筑与人类的关系就一直是建筑设计师必须面对的核心问题。英国首相丘吉尔说,我们构造建筑物,然后建筑物构造我们(We shape our buildings, and afterwaRDS our buildings shape us)。英国下议院的会议厅较狭窄,无法使所有的下议院议员面向同一个方向入座,而必须分成两侧入座。丘吉尔认为,议员们入座的时候自然会选择与自己政见相同的人同时入座,而这就是英国政党制的起源。Party这个词的原意就是"方"、"面"。政党起源的关键就是建筑物对人的影响。

    在软件设计界曾经有很多人认为功能是最为重要的,形式必须服从功能。与此类似地,在建筑学界,现代主义建筑流派的开创人之一Louis Sullivan也认为形式应当服从于功能(FORMs follows function)。

    几乎所有的软件设计理念都可以在浩如烟海的建筑学历史中找到更为遥远的历史回响。最为著名的,当然就是模式理论和XP理论。

    正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:

    1.可靠性(Reliable)。软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。

    2.安全性(Secure)。软件系统所承担的交易的商业价值极高,系统的安全性非常重要。

    3.可扩展性(SCAlable)。软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。只有这样,才能适应用户的市场扩展得可能性。

    4.可定制化(CuSTomizable)。同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。

    5.可扩展性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展。

    6.可维护性(MAIntainable)。软件系统的维护包括两方面,一是排除现有的错误,二是将新的软件需求反映到现有系统中去。一个易于维护系统可以有效地降低技术支持的花费。

    7.客户体验(Customer Experience)。软件系统必须易于使用。

    8.市场时机(Time to Market)。软件用户要面临同业竞争,软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

     



    虽然以上视图可以表示系统的整体设计,但构架只同以下几个具体方面相关:

    模型的结构,即组织模式,例如分层。基本元素,即关键用例、主类、常用机制等,它们与模型中的各元素相对。几个关键场景,它们表示了整个系统的主要控制流程。记录模块度、可选特征、产品线状况的服务。

    构架视图在本质上是整体设计的抽象或简化,它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时,这些特征非常重要。

    系统演进,即进入下一个开发周期。在产品线环境下复用构架或构架的一部分。评估补充质量,例如性能、可用性、可移植性和安全性。向团队或分包商分配开发工作。决定是否包括市售构件。插入范围更广的系统。

     


    构架模式是解决复杂构架问题的现成形式。构架框架或构架基础设施(中间件)是可以在其上构建某种构架的构件集。许多主要的构架困难应在框架或基础设施中进行解决,而且通常针对于特定的领域:命令和控制、MIS、控制系统等等。

    构架模式示例

    [BUS96] 根据构架模式最适用的系统的特征将其分类,其中一个类别处理更普遍的结构问题。下表显示了 [BUS96] 中所提供的类别和这些类别所包含的模式。

    类别 模式结构 层管道和过滤器黑板分布式系统代理交互系统 模型-视图-控制器表示-抽象-控制自适应系统反射微核

    在“软件构架简介”中,David Garlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次:“在计算的算法和数据结构之外,设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构;通信、同步和数据访问的协议;设计元素的功能分配;物理分布;设计元素的组成;定标与性能;备选设计的选择。”[GS93]

    但构架不仅是结构;IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”[IEEE98]。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑,而且还在系统的用户环境和开发环境中对系统进行整体考虑,即同时注重对外部的考虑。

    在Rational Unified Process 中,软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。

    为阐明其含义,下面将详述其中的两个;完整说明请参见 [BUS96]。模式以下列广泛使用的形式来表示:

    模式名环境问题影响,描述应考虑的不同问题方面解决方案基本原理结果环境示例模式名层

    环境需要进行结构分解的大系统。

    问题必须处理不同抽象层次的问题的系统。例如:硬件控制问题、常见服务问题和针对于不同领域的问题。最好不要编写垂直构件来处理所有抽象层次的问题。否则要在不同的构件中多次处理相同的问题(可能会不一致)。

    影响

    系统的某些部分应当是可替换的构件中的变化不应波动相似的责任应归为一组构件大小 -- 复杂构件可能要进行分解解决办法将系统分成构件组,并使构件组形成层叠结构。使上层只使用下层(决不使用上层)提供的服务。尽量不使用非紧邻下层提供的服务(不跳层使用服务,除非中间层只添加通过构件)。

    示例:

    1. 通用层

    严格的分层构架规定设计元素(类、构件、包、子系统)只能使用下层提供的服务, 服务可以包括事件处理、错误处理、数据库访问等等。 相对于记录在底层的原始操作系统级调用,它包括更明显的机制。

    2. 业务系统层

    上图显示了另一个分层示例,其中有垂直特定应用层、水平层和基础设施层。注意:此处的目标是采用非常短的业务“烟囱”并实现各种应用程序间的通用性。 否则,就可能有多个人解决同一问题,从而导致潜在的分歧。

    有关该模式的深入讨论,请参见指南:分层。

    模式名黑板

    环境没有解决问题的确定方法(算法)或方法不可行的领域。例如 AI 系统、语音识别和监视系统。

    问题多个问题解决顾问(知识顾问)必须通过协作来解决他们无法单独解决的问题。各顾问的工作结果必须可以供所有其他顾问访问,使他们可以评估自己是否可以参与解决方案的查找并发布其工作结果。

    影响

    知识顾问参与解决问题的顺序不是确定的,这可能取决于问题解决策略

    不同顾问的输入(结果或部分解决方案)可能有不同的表示方式

    各顾问并不直接知道对方的存在,但可以评估对方发布的工作

    解决办法多名知识顾问都可访问一个称为“黑板”的共享数据库。黑板提供监测和更新其内容的接口。控制模块/对象激活遵循某种策略的顾问。激活后,顾问查看黑板,以确定它是否能参与解决问题。如果顾问决定它可以参与,控制对象就可以允许顾问将其部分(或最终)解决方案放置于黑板上。

    示例:

    以上显示了使用 UML 建模的结构或静态视图。 它将成为参数化协作的一部分,然后会绑定到实参上对模式进行实例化。

    构架风格软件构架(或仅是构架视图)可以具有名为构架风格的属性,该属性减少了可选的形式,并使构架具有一定程度的一致性。样式可以通过一组模式或通过选择特定构件或连接器作为基本构件来定义。对给定系统,某些样式可作为构架描述的一部分记录在构架风格指南(Rational Unified Process 中设计指南文档的一部分)中。样式在构架的可理解性与完整性方面起着主要的作用。

    逻辑视图:类图、状态机和对象图。进程视图:类图与对象图(包括任务 - 进程与线程)。实施视图:构件图。部署视图:配置图。

     

    架构描述语言(ADL)用于描述软件的体系架构。已有多种架构描述语言,如Wright (由卡内基梅隆大学开发),Acme (由卡内基梅隆大学开发),C2 (由UCI开发), Darwin (由伦敦帝国学院开发)。ADL的基本构成包括组件、连接器和配置。

     


    构架

    构架视图的图形描述称为构架设计图。对于以上描述的各种视图,设计图由以下统一建模语言图组成 [UML99]:

    1.逻辑视图:类图、状态机和对象图。

    2.进程视图:类图与对象图(包括任务 - 进程与线程)。

    3.实施视图:构件图。

    4.部署视图:配置图。

    5.用例视图:用例图描述用例、主角和普通设计类;顺序图描述设计对象及其协作关系。

    构架设计流程

    在 Rational Unified Process 中,构架主要是分析设计工作流程的结果。当项目再次进行此工作流程时,构架将在一次又一次迭代中不断演化、改进、精炼。由于每次迭代都包括集成和测试,所以在交付产品时,构架就相当强壮了。构架是精化阶段各次迭代的重点,构架的基线通常会在此阶段结束时确定。

    架构师

    软件设计师中有一些技术水平较高、经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分、元件之间如何发生相互作用,以及系统中逻辑的、物理的、系统的重要决定的作出。

    这样的人就是所谓的架构师(Architect)。在很多公司中,架构师不是一个专门的和正式的职务。通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作。在一个部门中,最有经验的项目经理会负责一些架构方面的工作。

    但是,越来越多的公司体会到架构工作的重要性,并且在不同的组织层次上设置专门的架构师位置,由他们负责不同层次上的逻辑架构、物理架构、系统架构的设计、配置、维护等工作。

     


    软件架构是对软件系统运行时元素的抽象,软件系统可能有很多层抽象,或由多重业务流程所组成,每层抽象或每个业务流程都有自己的软件架构。

    软件架构是平衡的艺术。

    参考:

    http://www.uml.org.cn/zjjs/zjjs-bk.asp

    展开全文
  • 课程主体部分从软件架构体系结构、架构设计、技术体系等角度出发,详细介绍了架构师区别于一般开发人员所需要掌握的架构设计方法论与相关实践,包括架构风格与模式、领域驱动设计、类与框架设计、分布式系统架构设计...
  • 通过剖析和展示一个端到端的简化微服务应用案例MovieApp,帮助学员学习理解现代微服务应用和云原生架构实践,内容包括: 微服务应用架构 前后分离应用架构 基于Spring Security + JWT的...
  • (1)软件功能架构(2)逻辑架构(3)技术架构(4)部署架构,四个维度切中架构设计的在项目中的实际应用。让大家把理论与实践结合起来,力求做到通俗易懂,进而灵活应用。 【★】课程大纲:
  • 本门课程围绕电商项目大觅网的业务场景,基于微服务原则设计电商项目,使用多种诸如Eureka、Feign、...本次课程以实战为基础,让同学们在实战过程中,独立完成网站的架构搭建和项目开发,掌握其中的实现方式与思路。
  • 软件各种架构图收集

    2018-07-25 11:14:10
    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。  简单说明: 1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境  2.企业集成平台是以...

     

     

    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。

     简单说明:

    1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境                            

    2.企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台         

    3.数据中心是企业公共数据的集中管理比如用户数据、企业编码,可以通过数据集成平台或服务集成平台分发给其他应用     

     

    项目做了不少,都没画过架构图,这次被要求画图,画的很丑,请大家看图本身包含的系统架构信息

    一、架构整体图

      

       1、核心是两库一线

      1.1 接口总线

        所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的

      1.2 代码库

        代码库包含现接口总线中接口的各种实现

      1.3 应用库

        提供用户的界面或者提供给外部的服务

        是通过容器配置调用算法库中的代码来实现的各种应用          

     

    二、应用关系图

           1、应用通过配置从应用库中组装出自己的应用系统

           2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等)

           3、使用消息队列做高并发应用支撑(秒杀类似应用)

           4、使用分布式任务系统做周期作业、数据维护、数据计算等

     

     

    ENode架构图

     

    什么是ENode

    ENode是一个.NET平台下,纯C#开发的,基于DDD,CQRS,ES,EDA,In-Memory架构风格的,可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。

    • 开源项目地址:https://github.com/tangxuehua/enode
    • 作者博客地址:http://www.cnblogs.com/netfocus/category/496012.html
    • QQ交流群号:185916873
    • 微信公众号:ENode

    ENode框架特色

    1. 一个DDD开发框架,完美支持基于六边形架构思想的开发
    2. 实现CQRS架构思想,并且框架提供C端命令的处理结果的返回,支持同步返回和异步返回
    3. 内置Event Sourcing(ES)架构模式,让C端的数据持久化变得通用化
    4. 聚合根常驻内存,in-memory domain model
    5. 聚合根的处理基于Command Mailbox, Event Mailbox的思想,类似Actor Model, Actor Mailbox
    6. 严格遵守聚合内强一致性、聚合之间最终一致性的原则
    7. Group Commit Domain event
    8. 基于聚合根ID+事件版本号的唯一索引,实现聚合根的乐观并发控制
    9. 框架保证Command的幂等处理
    10. 通过聚合根ID对命令或事件进行路由,做到最小的并发冲突、最大的并行处理
    11. 消息发送和接收基于分布式消息队列EQueue,支持分布式部署
    12. 基于事件驱动架构范式(EDA,Event-Driven Architecture)
    13. 基于队列的动态扩容/缩容
    14. EventDB中因为存放的都是不可变的事件,所以水平扩展非常容易,框架可内置支持
    15. 支持Process Manager(Saga),以支持一个用户操作跨多个聚合根的业务场景,如订单处理,从而避免分布式事务的使用
    16. ENode实现了CQRS架构面临的大部分技术问题,让开发者可以专注于业务逻辑和业务流程的开发,而无需关心纯技术问题

    晚上把公司应用的架构结合之前研究的东西梳理了下,整理了一张架构规划图,贴在这里备份

    下面是个人理解的做架构的几个要点:

    1、系统安全

    这是首要考虑的,以这张图为例,网络划分为3个区:

    a) DMZ区可以直接公网访问,也可以 与App Core区互通,但不能直接与DB Core区互通 (通常这里放置 反向代理Web服务器)

    b) App Core区能与DMZ区、DB Core区互通,但是无法直接从公网访问 (通常这里放置 应用服务器、中间件服务器之类)

    c) DB Core区仅与App Core区互通 (通常这里放置 核心数据库)

    2、尽量消除单点故障

    上图中,除了“硬件负载均衡”节点外,其它节点都可以部署成集群(DB有点特殊,传统RDBMS要实现分布式/集群还是比较困难的,要看具体采用的数据库产品,并非所有数据库都能方便的做Sharding),Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBM MQ本身就支持集群、FTP Server配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说

    3、成本

    尽量采用开源成熟产品,jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的选择。硬件负载均衡通常成本不低,但是效果明显,如果实在没钱,域名解析采用DNS轮询策略,也能达到类似效果,只不过可靠性略差。

    4、Database问题

    常规企业应用中,传统关系型数据仍然是主流,但是no-sql经过这几年发展,技术也日渐成熟了,一些非关键数据可以适当采用no-sql数据库,比如:系统日志、报文历史记录这类相对比较独立,而且增长迅速的数据,可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。

    如果系统数据量级达到单机RDBMS的上限,尽早考虑Sharding方案,目前mysql在这方面比较成熟,其它数据库就不好说了。

    5、性能

    web server、app server这些一般都可以通过集群实现横向扩张,满足性能日常增长的需求。最大的障碍还是DB,如果规模真达到了DB的上限,还是考虑换分布式DB或者迁移到“云”上吧。

     

    HBase 系统架构图

      

      组成部件说明   Client:      使用HBase RPC机制与HMaster和HRegionServer进行通信      Client与HMaster进行通信进行管理类操作      Client与HRegionServer进行数据读写类操作      Zookeeper:      Zookeeper Quorum存储-ROOT-表地址、HMaster地址      HRegionServer把自己以Ephedral方式注册到Zookeeper中,HMaster随时感知各个HRegionServer的健康状况      Zookeeper避免HMaster单点问题      HMaster:      HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master在运行      主要负责Table和Region的管理工作:      1 管理用户对表的增删改查操作      2 管理HRegionServer的负载均衡,调整Region分布      3 Region Split后,负责新Region的分布      4 在HRegionServer停机后,负责失效HRegionServer上Region迁移      HRegionServer:      HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据

      

      HRegionServer管理一些列HRegion对象;     每个HRegion对应Table中一个Region,HRegion由多个HStore组成;    每个HStore对应Table中一个Column Family的存储;      Column Family就是一个集中的存储单元,故将具有相同IO特性的Column放在一个Column Family会更高效

      HStore:      HBase存储的核心。由MemStore和StoreFile组成。      MemStore是Sorted Memory Buffer。用户写入数据的流程:

      

      Client写入 -> 存入MemStore,一直到MemStore满 -> Flush成一个StoreFile,直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除 -> 当StoreFiles Compact后,逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上。 由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能。

      HLog      引入HLog原因:      在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况      工作机制:      每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入Memstore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。

      HBase存储格式      HBase中的所有数据文件都存储在Hadoop HDFS文件系统上,格式主要有两种:      1 HFile HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile      2 HLog File,HBase中WAL(Write Ahead Log) 的存储格式,物理上是Hadoop的Sequence File

      HFile

      

      图片解释:     HFile文件不定长,长度固定的块只有两个:Trailer和FileInfo      Trailer中指针指向其他数据块的起始点      File Info中记录了文件的一些Meta信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等      Data Index和Meta Index块记录了每个Data块和Meta块的起始点      Data Block是HBase I/O的基本单元,为了提高效率,HRegionServer中有基于LRU的Block Cache机制      每个Data块的大小可以在创建一个Table的时候通过参数指定,大号的Block有利于顺序Scan,小号Block利于随机查询      每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字,目的是防止数据损坏

      HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项,并且有固定的结构。

      

      KeyLength和ValueLength:两个固定的长度,分别代表Key和Value的长度     Key部分:Row Length是固定长度的数值,表示RowKey的长度,Row 就是RowKey      Column Family Length是固定长度的数值,表示Family的长度      接着就是Column Family,再接着是Qualifier,然后是两个固定长度的数值,表示Time Stamp和Key Type(Put/Delete)      Value部分没有这么复杂的结构,就是纯粹的二进制数据

      HLog File

      

      HLog文件就是一个普通的Hadoop Sequence File,Sequence File 的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括 sequence number和timestamp,timestamp是“写入时间”,sequence number的起始值为0,或者是最近一次存入文件系统中sequence number。     HLog Sequece File的Value是HBase的KeyValue对象,即对应HFile中的KeyValue

      

      结束语:这篇文章是我专门在网上弄下来的,算是hbase部分的终极篇吧,我的服务端的源码系列也要基于这个顺序来开展。

     

     

    一.三层架构图

     

    二.系统各层次职责
    1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。
    2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。
    (1)Business Function 子层负责基本业务功能的实现。
    (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。(Transaction只能在Business Flow 子层开启。)
    3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。
    (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。
    (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。
    DB Adapter子层负责屏蔽数据库类型的差异。
    ORM子层负责提供对象-关系映射的功能。
    Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。
    (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。
    注: Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service     Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。
    (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。
    4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

     
    三.Aspect
     Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。
    1.Securtiy Aspect:用于对整个系统的Security提供支持。
    2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。
    3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

    四.规则
    1.系统各层次及层内部子层次之间都不得跨层调用。
    2.Entity object 在各个层之间传递数据。
    3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。
    4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。
    5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。
    6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。
    7.UI层和BL层禁止出现任何SQL语句。

    五.错误与异常
            异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。
    1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。
    2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。
    3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
    4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

    六.项目组织目结构
     以BAS系统为例。
    1.主目录结构:
     
    2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
    3.包含众多子项目的庞大项目的物理组织:
     
    核心子项目Core的位置:

     
    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    七.发布服务与服务回调
    以EAS系统为例。
     
    1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。
    2. 如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。
    3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。
    4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

        从上图中可以看出,Android系统架构为四层结构,从上层到下层分别是应用程序层、应用程序框架层、系统运行库层以及Linux内核层,分别介绍如下:

        1)应用程序层

             Android平台不仅仅是操作系统,也包含了许多应用程序,诸如SMS短信客户端程序、电话拨号程序、图片浏览器、Web浏览器等应用程序。这些应用程序都是       用Java语言编写的,并且这些应用程序都是可以被开发人员开发的其他应用程序所替换,这点不同于其他手机操作系统固化在系统内部的系统软件,更加灵活和个    性化。

        2)应用程序框架层

             应用程序框架层是我们从事Android开发的基础,很多核心应用程序也是通过这一层来实现其核心功能的,该层简化了组件的重用,开发人员可以直接使用其提    供的组件来进行快速的应用程序开发,也可以通过继承而实现个性化的拓展。

             a) Activity Manager(活动管理器)

                  管理各个应用程序生命周期以及通常的导航回退功能

             b) Window Manager(窗口管理器)

                  管理所有的窗口程序

             c)  Content Provider(内容提供器)

                  使得不同应用程序之间存取或者分享数据

            d) View System(视图系统)

                  构建应用程序的基本组件

             e) Notification Manager(通告管理器)

                  使得应用程序可以在状态栏中显示自定义的提示信息

             f) Package Manager(包管理器) 

                  Android系统内的程序管理

             g)Telephony Manager(电话管理器)

                  管理所有的移动设备功能

             h)Resource Manager(资源管理器)

                  提供应用程序使用的各种非代码资源,如本地化字符串、图片、布局文件、颜色文件等

             i)Location Manager(位置管理器)

                 提供位置服务

             j)XMPP Service(XMPP服务)

                 提供Google Talk服务 

        3)系统运行库层

             从图中可以看出,系统运行库层可以分成两部分,分别是系统库和Android运行时,分别介绍如下:

             a)系统库

                  系统库是应用程序框架的支撑,是连接应用程序框架层与Linux内核层的重要纽带。其主要分为如下几个:

                  Ø  Surface Manager:

                      执行多个应用程序时候,负责管理显示与存取操作间的互动,另外也负责2D绘图与3D绘图进行显示合成。 

         Ø  Media Framework: 

                      多媒体库,基于PacketVideo OpenCore;支持多种常用的音频、视频格式录制和回放,编码格式包括MPEG4、MP3、H.264、AAC、ARM。

                  Ø  SQLite:

                      小型的关系型数据库引擎 

                  Ø  OpenGL|ES:

                     根据OpenGL ES 1.0API标准实现的3D绘图函数库 

                  Ø  FreeType:

                      提供点阵字与向量字的描绘与显示 

                  Ø  WebKit:

                      一套网页浏览器的软件引擎

                  Ø  SGL:

                      底层的2D图形渲染引擎 

                  Ø  SSL:

                      在Andorid上通信过程中实现握手 

                  Ø  Libc:

                 从BSD继承来的标准C系统函数库,专门为基于embedded linux的设备定制

             b)Android运行时

                 Android应用程序时采用Java语言编写,程序在Android运行时中执行,其运行时分为核心库和Dalvik虚拟机两部分。

                 Ø  核心库

                     核心库提供了Java语言API中的大多数功能,同时也包含了Android的一些核心API,如android.os、android.net、android.media等等。

                 Ø  Dalvik虚拟机

                     Android程序不同于J2me程序,每个Android应用程序都有一个专有的进程,并且不是多个程序运行在一个虚拟机中,而是每个Android程序都有一                个Dalivik虚拟机的实例,并在该实例中执行。Dalvik虚拟机是一种基于寄存器的Java虚拟机,而不是传统的基于栈的虚拟机,并进行了内存资源使用的优化          以及支持多个虚拟机的特点。需要注意的是,不同于J2me,Android程序在虚拟机中执行的并非编译后的字节码,而是通过转换工具dx将Java字节码转成dex格          式的中间码。

        4)Linux内核层 

            Android是基于Linux2.6内核,其核心系统服务如安全性、内存管理、进程管理、网路协议以及驱动模型都依赖于Linux内核。

     

     

    Entity Framework的全称是ADO.NET Entity Framework,是微软开发的基于ADO.NET的ORM(Object/Relational Mapping)框架。

    Entity Framework的主要特点:

    1. 支持多种数据库(Microsoft SQL Server, Oracle, and DB2);

    2. 强劲的映射引擎,能很好地支持存储过程;

    3. 提供Visual Studio集成工具,进行可视化操作;

    4. 能够与ASP.NET, WPF, WCF, WCF Data Services进行很好的集成。

    架构图一

    架构图2

     

     

     

      刚刚来到一家新公司,首先会对项目进行一个大致了解,研究了两天了,有了个总体的把握了,下面就是我这个小菜鸟画的简单系统架构图!  

      有的时候架构庞大的吓人,有的时候架构一眼看穿,但里面却暗藏杀机,真的需要我们去认真学习,揣摩!

      不久前在园子里面看过一篇文章其中说道,设计架构无非就是一个字 → “”,当时看到这个字,想起来还真的是这么一回事,不过这里面去包含了很多的东西,我们现在就是不知道怎么拆,这个也不是一时半会能够了解的,需要我们认认真真的做,慢慢的积累,到时候就知道怎么拆了,而且还拆的很到位,所以加油!

      对于这个拆字园友们也给出了很多的理解,这是只是个人看法!

     

     

     

    Struts2 架构图

    Struts2架构图 


            请求首先通过Filter chain,Filter主要包括ActionContextCleanUp,它主要清理当前线程的ActionContext和Dispatcher;FilterDispatcher主要通过AcionMapper来决定需要调用哪个Action。 
            ActionMapper取得了ActionMapping后,在Dispatcher的serviceAction方法里创建ActionProxy,ActionProxy创建ActionInvocation,然后ActionInvocation调用Interceptors,执行Action本身,创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。 


    Struts2部分类介绍 
    这部分从Struts2参考文档中翻译就可以了。 
    ActionMapper 
            ActionMapper其实是HttpServletRequest和Action调用请求的一个映射,它屏蔽了Action对于Request等java Servlet类的依赖。Struts2中它的默认实现类是DefaultActionMapper,ActionMapper很大的用处可以根据自己的需要来设计url格式,它自己也有Restful的实现,具体可以参考文档的docs\actionmapper.html。 
    ActionProxy&ActionInvocation 
            Action的一个代理,由ActionProxyFactory创建,它本身不包括Action实例,默认实现DefaultActionProxy是由ActionInvocation持有Action实例。ActionProxy作用是如何取得Action,无论是本地还是远程。而ActionInvocation的作用是如何执行Action,拦截器的功能就是在ActionInvocation中实现的。 
    ConfigurationProvider&Configuration 
            ConfigurationProvider就是Struts2中配置文件的解析器,Struts2中的配置文件主要是尤其实现类XmlConfigurationProvider及其子类StrutsXmlConfigurationProvider来解析, 


    Struts2请求流程 
    1、客户端发送请求 
    2、请求先通过ActionContextCleanUp-->FilterDispatcher 
    3、FilterDispatcher通过ActionMapper来决定这个Request需要调用哪个Action 
    4、如果ActionMapper决定调用某个Action,FilterDispatcher把请求的处理交给ActionProxy,这儿已经转到它的Delegate--Dispatcher来执行 
    5、ActionProxy根据ActionMapping和ConfigurationManager找到需要调用的Action类 
    6、ActionProxy创建一个ActionInvocation的实例 
    7、ActionInvocation调用真正的Action,当然这涉及到相关拦截器的调用 
    8、Action执行完毕,ActionInvocation创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。添加PreResultListener可以在Interceptor中实现,不知道其它还有什么方式? 

     

    短连接聊天服务 ,每半分钟刷新一次..

    客户端可切换3种渲染模式,全位图blit传输:sprite区块和MC

     

     

    架构图:

    模块与模块之间的通信也通过sendNotifcation发送消息。

     

    神仙道寻路方法:

    1. 2点是否可以直接到达,可以,则不走寻路,直接行进 2. 2点不能直接到达,进行寻路,找不到结果,寻找替代点 3. 正常寻路

    关于flash共享库:

    如果a的库里的资源设置了共享资源并设置了一个url 把a发布的swf放到设置的url的位置 b引入a的库里共享的资源..再发布b..这时b会自动从那个设置的url加载a

    浏览器缓存地址:C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files

    网页游戏的swf都加载到这里了。

    <深度排序>

    那就不停的 遍历 更具显示对象的Y 设置它们再容器里面的深度  不知道把同屏显示对象的Y再数组里面排序好 再设置深度 速度快  还是变排序边设置深度快 并且在数组里面排序好 这种方法要速度很好

    把图层封装成一个类。 和NPC和玩家都共同继承一个接口 iworldObject 加一个属性 depth. 创建的时候设置 这个属性。然后sortOn("depth");

    Array.Numberic 啊 默认都是 从小到大排序的 depth 是他的一个属性 npc 也统一有这个属性 然后就不用y轴排序了,看你的 y+height 挺纠结的 统一用 depth 这个属性排序

    这里判断这个 玩家的深度如果已经符合,就不要排序。 setChildIndex 消耗挺大的

     

     

    详解三层架构图

     PS: 在看三层架构的时候,找的了一个我感觉不错的材料,里面有如下一张图,打算详细的解释一下这张图,也总结一下三层的知识

      

    一、系统各层次职责

         1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。

        2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。

        (1)Business Function 子层负责基本业务功能的实现。

        (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流(Transaction只能在Business Flow 子层开启。)

        3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。

      (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

      (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

        DB Adapter子层负责屏蔽数据库类型的差异。

        ORM子层负责提供对象-关系映射的功能。

        Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。

      (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。

             注:Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service      Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。

      (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。

        4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

      

    二、Aspect

        Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。

        1.Securtiy Aspect:用于对整个系统的Security提供支持。

        2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。

        3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

     

    三、规则

        1.系统各层次及层内部子层次之间都不得跨层调用。

        2.Entity object 在各个层之间传递数据。

        3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。

        4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。

        5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。

        6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。

        7.UI层和BL层禁止出现任何SQL语句。

     

    四、错误与异常

             异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。

        1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。

        2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证 结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。

        3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

        4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

     

    五、项目组织目结构

        以BAS系统为例。

         1.主目录结构:

     

         2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的 分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

        3.包含众多子项目的庞大项目的物理组织:

     

    核心子项目Core的位置:

     

     

    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    六、发布服务与服务回调

    以EAS系统为例。

     

         1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。

         2.如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。

         3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。

         4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型 的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

     

      之前用一张图分析了Google给出的MVP架构,但是在Google给出的所有案例里面除了基本的MVP架构还有其它几种架构,今天就来分析其中的Clean架构。同样的,网上介绍Clean架构的文章很多,我也就不用文字过多叙述了,还是用一张类图来分析一下Clean架构的这个案例吧。好了,先直接上图!

     

      

     

      上完图,再说一说我对Clean架构的一个理解吧。对比前一篇文章的MVP架构图可以看出,clean在一定程度上继承了mvp的设计思想,但是其抽象程度比mvp更高。初次看这个demo的时候,确实被震撼了一下——原来用Java可以这样写代码!!!跟之前用的一些项目框架和我自己平时写的一些代码对比一下,只能感叹clean的这种设计思想真不是一般的程序员可以想出来的。它对接口、抽象类和实现类之间的实现、继承、调用关系发挥到了一个比较高的层次,它并不是像我们平时写代码那样很直白地写下来,而是充分利用了面向对象的封装性、继承性和多态性,是对面向对象思想的一个高度理解。其实,要说clean复杂,它确实有些难理解,可是如果你真的理解了面向对象思想,那么又会觉得这样的设计完全在情理之中。

     

     

          最近几个月都没有整理Blog,都忙着整理总结之前一段时间做的项目和学习的内容,然后想到把这些东西融合在一起,设计一个开发框架。

    这个框架用到了一些.NET社区比较前沿的技术,比如ORM, IOC容器, AOP拦截等,在.NET 2.0的基础上构建了一个.NET Remoting的分布式开发框架。

    项目开发最关注的就是开发效率,其次是项目的可管理可控性,最后是架构的可扩展性。我希望在我的框架设计中能够将这三者很好的整合在一起。

    大致的思路是:

    1、可扩展性:通过IOC容器的使用降低项目中各个模块之间的依赖性;用领域模式来设计业务核心层,降低业务层对数据层和界面层的耦合度;分布式选择Remoting为主,可以再包装为WebService或者直接发布为WebService。

    2、将敏捷的项目管理思路引入到框架中,框架充分支持TDD测试驱动和运行日志驱动,为敏捷管理提供技术支持。

    3、初步通过AOP技术减少和核心业务无关的系统级代码:如事务处理、异常处理、日志记录等;并在将来为架构提供可视化的代码配置生成工具,以最快的速度构建项目的主体结构,并尽可能大的增大灵活性。

          目前框架的主体已经完成,也重新整理VSS上的项目结构,并重新命名为LightningFramework。正在做细节调整,接下来的时间会逐步完成相关文档和演示程序。下面是主架构图:

    Framework整体架构设计图.jpg

     

     

    展开全文
  • 软件架构图集锦

    2019-04-30 17:00:15
    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。 简单说明: 1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境 2.企业集成平台是以基础...

     

    该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。

     简单说明:

    1.中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境                            

    2.企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台         

    3.数据中心是企业公共数据的集中管理比如用户数据、企业编码,可以通过数据集成平台或服务集成平台分发给其他应用     

     

    项目做了不少,都没画过架构图,这次被要求画图,画的很丑,请大家看图本身包含的系统架构信息

    一、架构整体图

      

       1、核心是两库一线

      1.1 接口总线

        所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的

      1.2 代码库

        代码库包含现接口总线中接口的各种实现

      1.3 应用库

        提供用户的界面或者提供给外部的服务

        是通过容器配置调用算法库中的代码来实现的各种应用          

     

    二、应用关系图

           1、应用通过配置从应用库中组装出自己的应用系统

           2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等)

           3、使用消息队列做高并发应用支撑(秒杀类似应用)

           4、使用分布式任务系统做周期作业、数据维护、数据计算等

     

     

    ENode架构图

     

    什么是ENode

    ENode是一个.NET平台下,纯C#开发的,基于DDD,CQRS,ES,EDA,In-Memory架构风格的,可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。

    • 开源项目地址:https://github.com/tangxuehua/enode
    • 作者博客地址:http://www.cnblogs.com/netfocus/category/496012.html
    • QQ交流群号:185916873
    • 微信公众号:ENode

    ENode框架特色

    1. 一个DDD开发框架,完美支持基于六边形架构思想的开发
    2. 实现CQRS架构思想,并且框架提供C端命令的处理结果的返回,支持同步返回和异步返回
    3. 内置Event Sourcing(ES)架构模式,让C端的数据持久化变得通用化
    4. 聚合根常驻内存,in-memory domain model
    5. 聚合根的处理基于Command Mailbox, Event Mailbox的思想,类似Actor Model, Actor Mailbox
    6. 严格遵守聚合内强一致性、聚合之间最终一致性的原则
    7. Group Commit Domain event
    8. 基于聚合根ID+事件版本号的唯一索引,实现聚合根的乐观并发控制
    9. 框架保证Command的幂等处理
    10. 通过聚合根ID对命令或事件进行路由,做到最小的并发冲突、最大的并行处理
    11. 消息发送和接收基于分布式消息队列EQueue,支持分布式部署
    12. 基于事件驱动架构范式(EDA,Event-Driven Architecture)
    13. 基于队列的动态扩容/缩容
    14. EventDB中因为存放的都是不可变的事件,所以水平扩展非常容易,框架可内置支持
    15. 支持Process Manager(Saga),以支持一个用户操作跨多个聚合根的业务场景,如订单处理,从而避免分布式事务的使用
    16. ENode实现了CQRS架构面临的大部分技术问题,让开发者可以专注于业务逻辑和业务流程的开发,而无需关心纯技术问题

    晚上把公司应用的架构结合之前研究的东西梳理了下,整理了一张架构规划图,贴在这里备份

    下面是个人理解的做架构的几个要点:

    1、系统安全

    这是首要考虑的,以这张图为例,网络划分为3个区:

    a) DMZ区可以直接公网访问,也可以 与App Core区互通,但不能直接与DB Core区互通 (通常这里放置 反向代理Web服务器)

    b) App Core区能与DMZ区、DB Core区互通,但是无法直接从公网访问 (通常这里放置 应用服务器、中间件服务器之类)

    c) DB Core区仅与App Core区互通 (通常这里放置 核心数据库)

    2、尽量消除单点故障

    上图中,除了“硬件负载均衡”节点外,其它节点都可以部署成集群(DB有点特殊,传统RDBMS要实现分布式/集群还是比较困难的,要看具体采用的数据库产品,并非所有数据库都能方便的做Sharding),Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBM MQ本身就支持集群、FTP Server配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说

    3、成本

    尽量采用开源成熟产品,jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的选择。硬件负载均衡通常成本不低,但是效果明显,如果实在没钱,域名解析采用DNS轮询策略,也能达到类似效果,只不过可靠性略差。

    4、Database问题

    常规企业应用中,传统关系型数据仍然是主流,但是no-sql经过这几年发展,技术也日渐成熟了,一些非关键数据可以适当采用no-sql数据库,比如:系统日志、报文历史记录这类相对比较独立,而且增长迅速的数据,可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。

    如果系统数据量级达到单机RDBMS的上限,尽早考虑Sharding方案,目前mysql在这方面比较成熟,其它数据库就不好说了。

    5、性能

    web server、app server这些一般都可以通过集群实现横向扩张,满足性能日常增长的需求。最大的障碍还是DB,如果规模真达到了DB的上限,还是考虑换分布式DB或者迁移到“云”上吧。

     

    HBase 系统架构图

      

      组成部件说明   Client:      使用HBase RPC机制与HMaster和HRegionServer进行通信      Client与HMaster进行通信进行管理类操作      Client与HRegionServer进行数据读写类操作      Zookeeper:      Zookeeper Quorum存储-ROOT-表地址、HMaster地址      HRegionServer把自己以Ephedral方式注册到Zookeeper中,HMaster随时感知各个HRegionServer的健康状况      Zookeeper避免HMaster单点问题      HMaster:      HMaster没有单点问题,HBase中可以启动多个HMaster,通过Zookeeper的Master Election机制保证总有一个Master在运行      主要负责Table和Region的管理工作:      1 管理用户对表的增删改查操作      2 管理HRegionServer的负载均衡,调整Region分布      3 Region Split后,负责新Region的分布      4 在HRegionServer停机后,负责失效HRegionServer上Region迁移      HRegionServer:      HBase中最核心的模块,主要负责响应用户I/O请求,向HDFS文件系统中读写数据

      

      HRegionServer管理一些列HRegion对象;     每个HRegion对应Table中一个Region,HRegion由多个HStore组成;    每个HStore对应Table中一个Column Family的存储;      Column Family就是一个集中的存储单元,故将具有相同IO特性的Column放在一个Column Family会更高效

      HStore:      HBase存储的核心。由MemStore和StoreFile组成。      MemStore是Sorted Memory Buffer。用户写入数据的流程:

      

      Client写入 -> 存入MemStore,一直到MemStore满 -> Flush成一个StoreFile,直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile,同时进行版本合并和数据删除 -> 当StoreFiles Compact后,逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后,触发Split操作,把当前Region Split成2个Region,Region会下线,新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上,使得原先1个Region的压力得以分流到2个Region上。 由此过程可知,HBase只是增加数据,有所得更新和删除操作,都是在Compact阶段做的,所以,用户写操作只需要进入到内存即可立即返回,从而保证I/O高性能。

      HLog      引入HLog原因:      在分布式系统环境中,无法避免系统出错或者宕机,一旦HRegionServer意外退出,MemStore中的内存数据就会丢失,引入HLog就是防止这种情况      工作机制:      每个HRegionServer中都会有一个HLog对象,HLog是一个实现Write Ahead Log的类,每次用户操作写入Memstore的同时,也会写一份数据到HLog文件,HLog文件定期会滚动出新,并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后,HMaster会通过Zookeeper感知,HMaster首先处理遗留的HLog文件,将不同region的log数据拆分,分别放到相应region目录下,然后再将失效的region重新分配,领取到这些region的HRegionServer在Load Region的过程中,会发现有历史HLog需要处理,因此会Replay HLog中的数据到MemStore中,然后flush到StoreFiles,完成数据恢复。

      HBase存储格式      HBase中的所有数据文件都存储在Hadoop HDFS文件系统上,格式主要有两种:      1 HFile HBase中KeyValue数据的存储格式,HFile是Hadoop的二进制格式文件,实际上StoreFile就是对HFile做了轻量级包装,即StoreFile底层就是HFile      2 HLog File,HBase中WAL(Write Ahead Log) 的存储格式,物理上是Hadoop的Sequence File

      HFile

      

      图片解释:     HFile文件不定长,长度固定的块只有两个:Trailer和FileInfo      Trailer中指针指向其他数据块的起始点      File Info中记录了文件的一些Meta信息,例如:AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等      Data Index和Meta Index块记录了每个Data块和Meta块的起始点      Data Block是HBase I/O的基本单元,为了提高效率,HRegionServer中有基于LRU的Block Cache机制      每个Data块的大小可以在创建一个Table的时候通过参数指定,大号的Block有利于顺序Scan,小号Block利于随机查询      每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字,目的是防止数据损坏

      HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项,并且有固定的结构。

      

      KeyLength和ValueLength:两个固定的长度,分别代表Key和Value的长度     Key部分:Row Length是固定长度的数值,表示RowKey的长度,Row 就是RowKey      Column Family Length是固定长度的数值,表示Family的长度      接着就是Column Family,再接着是Qualifier,然后是两个固定长度的数值,表示Time Stamp和Key Type(Put/Delete)      Value部分没有这么复杂的结构,就是纯粹的二进制数据

      HLog File

      

      HLog文件就是一个普通的Hadoop Sequence File,Sequence File 的Key是HLogKey对象,HLogKey中记录了写入数据的归属信息,除了table和region名字外,同时还包括 sequence number和timestamp,timestamp是“写入时间”,sequence number的起始值为0,或者是最近一次存入文件系统中sequence number。     HLog Sequece File的Value是HBase的KeyValue对象,即对应HFile中的KeyValue

      

      结束语:这篇文章是我专门在网上弄下来的,算是hbase部分的终极篇吧,我的服务端的源码系列也要基于这个顺序来开展。

     

     

    一.三层架构图

     

    二.系统各层次职责
    1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。
    2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。
    (1)Business Function 子层负责基本业务功能的实现。
    (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。(Transaction只能在Business Flow 子层开启。)
    3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。
    (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。
    (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。
    DB Adapter子层负责屏蔽数据库类型的差异。
    ORM子层负责提供对象-关系映射的功能。
    Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。
    (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。
    注: Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service     Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。
    (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。
    4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

     
    三.Aspect
     Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。
    1.Securtiy Aspect:用于对整个系统的Security提供支持。
    2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。
    3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

    四.规则
    1.系统各层次及层内部子层次之间都不得跨层调用。
    2.Entity object 在各个层之间传递数据。
    3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。
    4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。
    5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。
    6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。
    7.UI层和BL层禁止出现任何SQL语句。

    五.错误与异常
            异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。
    1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。
    2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。
    3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
    4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

    六.项目组织目结构
     以BAS系统为例。
    1.主目录结构:
     
    2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
    3.包含众多子项目的庞大项目的物理组织:
     
    核心子项目Core的位置:

     
    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    七.发布服务与服务回调
    以EAS系统为例。
     
    1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。
    2. 如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。
    3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。
    4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

        从上图中可以看出,Android系统架构为四层结构,从上层到下层分别是应用程序层、应用程序框架层、系统运行库层以及Linux内核层,分别介绍如下:

        1)应用程序层

             Android平台不仅仅是操作系统,也包含了许多应用程序,诸如SMS短信客户端程序、电话拨号程序、图片浏览器、Web浏览器等应用程序。这些应用程序都是       用Java语言编写的,并且这些应用程序都是可以被开发人员开发的其他应用程序所替换,这点不同于其他手机操作系统固化在系统内部的系统软件,更加灵活和个    性化。

        2)应用程序框架层

             应用程序框架层是我们从事Android开发的基础,很多核心应用程序也是通过这一层来实现其核心功能的,该层简化了组件的重用,开发人员可以直接使用其提    供的组件来进行快速的应用程序开发,也可以通过继承而实现个性化的拓展。

             a) Activity Manager(活动管理器)

                  管理各个应用程序生命周期以及通常的导航回退功能

             b) Window Manager(窗口管理器)

                  管理所有的窗口程序

             c)  Content Provider(内容提供器)

                  使得不同应用程序之间存取或者分享数据

            d) View System(视图系统)

                  构建应用程序的基本组件

             e) Notification Manager(通告管理器)

                  使得应用程序可以在状态栏中显示自定义的提示信息

             f) Package Manager(包管理器) 

                  Android系统内的程序管理

             g)Telephony Manager(电话管理器)

                  管理所有的移动设备功能

             h)Resource Manager(资源管理器)

                  提供应用程序使用的各种非代码资源,如本地化字符串、图片、布局文件、颜色文件等

             i)Location Manager(位置管理器)

                 提供位置服务

             j)XMPP Service(XMPP服务)

                 提供Google Talk服务 

        3)系统运行库层

             从图中可以看出,系统运行库层可以分成两部分,分别是系统库和Android运行时,分别介绍如下:

             a)系统库

                  系统库是应用程序框架的支撑,是连接应用程序框架层与Linux内核层的重要纽带。其主要分为如下几个:

                  Ø  Surface Manager:

                      执行多个应用程序时候,负责管理显示与存取操作间的互动,另外也负责2D绘图与3D绘图进行显示合成。 

         Ø  Media Framework: 

                      多媒体库,基于PacketVideo OpenCore;支持多种常用的音频、视频格式录制和回放,编码格式包括MPEG4、MP3、H.264、AAC、ARM。

                  Ø  SQLite:

                      小型的关系型数据库引擎 

                  Ø  OpenGL|ES:

                     根据OpenGL ES 1.0API标准实现的3D绘图函数库 

                  Ø  FreeType:

                      提供点阵字与向量字的描绘与显示 

                  Ø  WebKit:

                      一套网页浏览器的软件引擎

                  Ø  SGL:

                      底层的2D图形渲染引擎 

                  Ø  SSL:

                      在Andorid上通信过程中实现握手 

                  Ø  Libc:

                 从BSD继承来的标准C系统函数库,专门为基于embedded linux的设备定制

             b)Android运行时

                 Android应用程序时采用Java语言编写,程序在Android运行时中执行,其运行时分为核心库和Dalvik虚拟机两部分。

                 Ø  核心库

                     核心库提供了Java语言API中的大多数功能,同时也包含了Android的一些核心API,如android.os、android.net、android.media等等。

                 Ø  Dalvik虚拟机

                     Android程序不同于J2me程序,每个Android应用程序都有一个专有的进程,并且不是多个程序运行在一个虚拟机中,而是每个Android程序都有一                个Dalivik虚拟机的实例,并在该实例中执行。Dalvik虚拟机是一种基于寄存器的Java虚拟机,而不是传统的基于栈的虚拟机,并进行了内存资源使用的优化          以及支持多个虚拟机的特点。需要注意的是,不同于J2me,Android程序在虚拟机中执行的并非编译后的字节码,而是通过转换工具dx将Java字节码转成dex格          式的中间码。

        4)Linux内核层 

            Android是基于Linux2.6内核,其核心系统服务如安全性、内存管理、进程管理、网路协议以及驱动模型都依赖于Linux内核。

     

     

    Entity Framework的全称是ADO.NET Entity Framework,是微软开发的基于ADO.NET的ORM(Object/Relational Mapping)框架。

    Entity Framework的主要特点:

    1. 支持多种数据库(Microsoft SQL Server, Oracle, and DB2);

    2. 强劲的映射引擎,能很好地支持存储过程;

    3. 提供Visual Studio集成工具,进行可视化操作;

    4. 能够与ASP.NET, WPF, WCF, WCF Data Services进行很好的集成。

    架构图一

    架构图2

     

     

     

      刚刚来到一家新公司,首先会对项目进行一个大致了解,研究了两天了,有了个总体的把握了,下面就是我这个小菜鸟画的简单系统架构图!  

      有的时候架构庞大的吓人,有的时候架构一眼看穿,但里面却暗藏杀机,真的需要我们去认真学习,揣摩!

      不久前在园子里面看过一篇文章其中说道,设计架构无非就是一个字 → “”,当时看到这个字,想起来还真的是这么一回事,不过这里面去包含了很多的东西,我们现在就是不知道怎么拆,这个也不是一时半会能够了解的,需要我们认认真真的做,慢慢的积累,到时候就知道怎么拆了,而且还拆的很到位,所以加油!

      对于这个拆字园友们也给出了很多的理解,这是只是个人看法!

     

     

     

    Struts2 架构图

    Struts2架构图 


            请求首先通过Filter chain,Filter主要包括ActionContextCleanUp,它主要清理当前线程的ActionContext和Dispatcher;FilterDispatcher主要通过AcionMapper来决定需要调用哪个Action。 
            ActionMapper取得了ActionMapping后,在Dispatcher的serviceAction方法里创建ActionProxy,ActionProxy创建ActionInvocation,然后ActionInvocation调用Interceptors,执行Action本身,创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。 


    Struts2部分类介绍 
    这部分从Struts2参考文档中翻译就可以了。 
    ActionMapper 
            ActionMapper其实是HttpServletRequest和Action调用请求的一个映射,它屏蔽了Action对于Request等java Servlet类的依赖。Struts2中它的默认实现类是DefaultActionMapper,ActionMapper很大的用处可以根据自己的需要来设计url格式,它自己也有Restful的实现,具体可以参考文档的docs\actionmapper.html。 
    ActionProxy&amp;ActionInvocation 
            Action的一个代理,由ActionProxyFactory创建,它本身不包括Action实例,默认实现DefaultActionProxy是由ActionInvocation持有Action实例。ActionProxy作用是如何取得Action,无论是本地还是远程。而ActionInvocation的作用是如何执行Action,拦截器的功能就是在ActionInvocation中实现的。 
    ConfigurationProvider&amp;Configuration 
            ConfigurationProvider就是Struts2中配置文件的解析器,Struts2中的配置文件主要是尤其实现类XmlConfigurationProvider及其子类StrutsXmlConfigurationProvider来解析, 


    Struts2请求流程 
    1、客户端发送请求 
    2、请求先通过ActionContextCleanUp--&gt;FilterDispatcher 
    3、FilterDispatcher通过ActionMapper来决定这个Request需要调用哪个Action 
    4、如果ActionMapper决定调用某个Action,FilterDispatcher把请求的处理交给ActionProxy,这儿已经转到它的Delegate--Dispatcher来执行 
    5、ActionProxy根据ActionMapping和ConfigurationManager找到需要调用的Action类 
    6、ActionProxy创建一个ActionInvocation的实例 
    7、ActionInvocation调用真正的Action,当然这涉及到相关拦截器的调用 
    8、Action执行完毕,ActionInvocation创建Result并返回,当然,如果要在返回之前做些什么,可以实现PreResultListener。添加PreResultListener可以在Interceptor中实现,不知道其它还有什么方式? 

     

    短连接聊天服务 ,每半分钟刷新一次..

    客户端可切换3种渲染模式,全位图blit传输:sprite区块和MC

     

     

    架构图:

    模块与模块之间的通信也通过sendNotifcation发送消息。

     

    神仙道寻路方法:

    1. 2点是否可以直接到达,可以,则不走寻路,直接行进 2. 2点不能直接到达,进行寻路,找不到结果,寻找替代点 3. 正常寻路

    关于flash共享库:

    如果a的库里的资源设置了共享资源并设置了一个url 把a发布的swf放到设置的url的位置 b引入a的库里共享的资源..再发布b..这时b会自动从那个设置的url加载a

    浏览器缓存地址:C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files

    网页游戏的swf都加载到这里了。

    <深度排序>

    那就不停的 遍历 更具显示对象的Y 设置它们再容器里面的深度  不知道把同屏显示对象的Y再数组里面排序好 再设置深度 速度快  还是变排序边设置深度快 并且在数组里面排序好 这种方法要速度很好

    把图层封装成一个类。 和NPC和玩家都共同继承一个接口 iworldObject 加一个属性 depth. 创建的时候设置 这个属性。然后sortOn("depth");

    Array.Numberic 啊 默认都是 从小到大排序的 depth 是他的一个属性 npc 也统一有这个属性 然后就不用y轴排序了,看你的 y+height 挺纠结的 统一用 depth 这个属性排序

    这里判断这个 玩家的深度如果已经符合,就不要排序。 setChildIndex 消耗挺大的

     

     

    详解三层架构图

     PS: 在看三层架构的时候,找的了一个我感觉不错的材料,里面有如下一张图,打算详细的解释一下这张图,也总结一下三层的知识

      

    一、系统各层次职责

         1.UI(User Interface)层的职责是数据的展现和采集,数据采集的结果通常以Entity object提交给BL层处理Service Interface侧层用于将业务或数据资源发布为服务(如WebServices)。

        2.BL(Business Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。

        (1)Business Function 子层负责基本业务功能的实现。

        (2)Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流(Transaction只能在Business Flow 子层开启。)

        3.ResourceAccess层的职责是提供全面的资源访问功能支持,并向上层屏蔽资源的来源。

      (1)BEM(Business Entity Manager)子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

      (2)DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

        DB Adapter子层负责屏蔽数据库类型的差异。

        ORM子层负责提供对象-关系映射的功能。

        Relation子层提供ORM无法完成的基于关系(Relation)的数据访问功能。

      (3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。

             注:Service Entrance用于简化对Service的访问,它相当于Service的代理,客户直接使用Service Entrance就可以访问系统发布的服务。Service      Entrance为特定的平台(如Java、.Net)提供强类型的接口,内部可能隐藏了复杂的参数类型转换。

      (4)ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。

        4.Entity侧层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity侧层中包含三类Entity,如下图所示:

      

    二、Aspect

        Aspect贯穿于系统各层,是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。

        1.Securtiy Aspect:用于对整个系统的Security提供支持。

        2.ErrorHandling Aspect:整个系统采用一致的错误/异常处理方式。

        3.Log Aspect:用于系统异常、日志记录、业务操作记录等。

     

    三、规则

        1.系统各层次及层内部子层次之间都不得跨层调用。

        2.Entity object 在各个层之间传递数据。

        3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。

        4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entity class都会有一个BEM Class与之对应。

        5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。

        6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。

        7.UI层和BL层禁止出现任何SQL语句。

     

    四、错误与异常

             异常可以分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务执行的结果。

        1.DataAccess层不得向上层隐藏任何异常(该层抛出的异常几乎都是系统异常)。

        2.要明确区分业务执行的结果和系统异常。比如验证用户的合法性,如果对应的用户ID不存在,不应该抛出异常,而是返回(或通过out参数)一个表示验证 结果的枚举值,这属于业务执行的结果。但是,如果在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。

        3.在有些情况下,BL层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

        4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

     

    五、项目组织目结构

        以BAS系统为例。

         1.主目录结构:

     

         2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的 分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

        3.包含众多子项目的庞大项目的物理组织:

     

    核心子项目Core的位置:

     

     

    Core子项目中包含一些公共的基础设施,如错误处理、权限控制方面等。

    六、发布服务与服务回调

    以EAS系统为例。

     

         1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。

         2.如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。

         3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。

         4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型 的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

     

     

      之前用一张图分析了Google给出的MVP架构,但是在Google给出的所有案例里面除了基本的MVP架构还有其它几种架构,今天就来分析其中的Clean架构。同样的,网上介绍Clean架构的文章很多,我也就不用文字过多叙述了,还是用一张类图来分析一下Clean架构的这个案例吧。好了,先直接上图!

     

      

     

      上完图,再说一说我对Clean架构的一个理解吧。对比前一篇文章的MVP架构图可以看出,clean在一定程度上继承了mvp的设计思想,但是其抽象程度比mvp更高。初次看这个demo的时候,确实被震撼了一下——原来用Java可以这样写代码!!!跟之前用的一些项目框架和我自己平时写的一些代码对比一下,只能感叹clean的这种设计思想真不是一般的程序员可以想出来的。它对接口、抽象类和实现类之间的实现、继承、调用关系发挥到了一个比较高的层次,它并不是像我们平时写代码那样很直白地写下来,而是充分利用了面向对象的封装性、继承性和多态性,是对面向对象思想的一个高度理解。其实,要说clean复杂,它确实有些难理解,可是如果你真的理解了面向对象思想,那么又会觉得这样的设计完全在情理之中。

     

     

          最近几个月都没有整理Blog,都忙着整理总结之前一段时间做的项目和学习的内容,然后想到把这些东西融合在一起,设计一个开发框架。

    这个框架用到了一些.NET社区比较前沿的技术,比如ORM, IOC容器, AOP拦截等,在.NET 2.0的基础上构建了一个.NET Remoting的分布式开发框架。

    项目开发最关注的就是开发效率,其次是项目的可管理可控性,最后是架构的可扩展性。我希望在我的框架设计中能够将这三者很好的整合在一起。

    大致的思路是:

    1、可扩展性:通过IOC容器的使用降低项目中各个模块之间的依赖性;用领域模式来设计业务核心层,降低业务层对数据层和界面层的耦合度;分布式选择Remoting为主,可以再包装为WebService或者直接发布为WebService。

    2、将敏捷的项目管理思路引入到框架中,框架充分支持TDD测试驱动和运行日志驱动,为敏捷管理提供技术支持。

    3、初步通过AOP技术减少和核心业务无关的系统级代码:如事务处理、异常处理、日志记录等;并在将来为架构提供可视化的代码配置生成工具,以最快的速度构建项目的主体结构,并尽可能大的增大灵活性。

          目前框架的主体已经完成,也重新整理VSS上的项目结构,并重新命名为LightningFramework。正在做细节调整,接下来的时间会逐步完成相关文档和演示程序。下面是主架构图:

    Framework整体架构设计图.jpg

    展开全文
  • 架构设计——架构知识体系   1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 我们主要针对互联网服server系统...

    架构设计——架构知识体系

     

    1、什么是架构和架构本质


    在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。

    我们主要针对互联网服server系统(类似网站)来定义架构:架构是系统的骨架,支撑和链接各个部分,包括组件、连接件、约束规范,以及指导这些内容设计与演化的原理。

    组件:类似应用服务,独立模块、数据库、nginx等等、

    连接件:分布式调用、进程间调用、调用使用http协议还是tcp协议、组件之间的交互关系、

    约束规范: 定规则做限制:例如设计原则、编码规范等等。

    是系统性地思考,权衡利弊之后在现有资源约束下的“最合理决策”,并由它来指导团队中的每个人思想层面上的一致。

    即架构=组件+交互。

    这类似建筑设计规划,城市总体规划等,其实就是架构,只是应用的场景不同。盖一座小房子,可以拍脑袋干起来,但是当你要盖一座大楼,如果没有一个建筑设计规划,可以想象搭理最后是什么样?

    架构的本质就是对系统进行有序化地重构以致符合当前业务的发展,并可以快速扩展。

    那什么样的系统要考虑做架构设计?

    1. 需求相对复杂.

    2. 非功能性需求在整个系统占据重要位置.

    3. 系统生命周期长,有扩展性需求.

    4.系统基于组件或者集成的需要.

    5.业务流程再造的需要.

     

    2、架构分类


    架构可细分为业务架构、应用架构、技术架构, 代码架构, 部署架构,.

    架构设计——架构知识体系

     

    业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。

    熟悉业务,形成业务架构,根据业务架构,做出相应的应用架构,最后技术架构落地实施。

    如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。

    一、业务架构(俯视架构):

    包括业务规划,业务模块、业务流程,对整个系统的业务进行拆分,对领域模型进行设计,把现实的业务转化成抽象对象。

    没有最优的架构,只有最合适的架构,一切系统设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑,任何不基于业务做异想天开的架构都是耍流氓。

    所有问题的前提要搞清楚我们今天面临的业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

    看看京东业务架构(网上分享图):

    架构设计——架构知识体系

     

    二、应用架构(剖面架构,也叫逻辑架构图):

    硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构的每一部分都有应用架构。

    类似:

    架构设计——架构知识体系

     

    应用架构:应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面. 应用架构定义系统有哪些应用、以及应用之间如何分工和合作。这里所谓应用就是各个逻辑模块或者子系统。

    应用架构图关键有2点:

    1、职责划分: 明确应用(各个逻辑模块或者子系统)边界

    1)逻辑分层

    2)子系统、模块定义。

    3)关键类。

    2、职责之间的协作:

    1)接口协议:应用对外输出的接口。

    2)协作关系:应用之间的调用关系。

    应用分层有两种方式:

    一种是水平分(横向),按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。

    另一种是垂直分(纵向),按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。

    应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。

    应用的分偏向于业务,反映业务架构,应用的合偏向于技术,影响技术架构。分降低了业务复杂度,系统更有序,合增加了技术复杂度,系统更无序。

    应用架构的本质是通过系统拆分,平衡业务和技术复杂性,保证系统形散神不散。

    系统采用什么样的应用架构,受业务复杂性影响,包括企业发展阶段和业务特点;同时受技术复杂性影响,包括IT技术发展阶段和内部技术人员水平。业务复杂性(包括业务量大)必然带来技术复杂性,应用架构目标是解决业务复杂性的同时,避免技术太复杂,确保业务架构落地。

    三、代码架构(也叫开发架构):

    子系统代码架构主要为开发人员提供切实可行的指导,如果代码架构设计不足,就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件,结果公司整体架构设计就会失控。

    代码架构主要定义:

    一、代码单元:

    1、配置设计

    2、框架、类库。

    二、代码单元组织:

    1、编码规范,编码的惯例。

    2、项目模块划分

    3、顶层文件结构设计,比如mvc设计。

    4、依赖关系

    四、技术架构,也可以叫系统架构

    技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

    技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

    系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

    架构设计——架构知识体系

     

    五、部署拓扑架构图(实际物理架构图):

    拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。

    架构设计——架构知识体系

     

    3、应用架构


    架构演进路程:

    ->初始阶段:LAMP,部署在一台服务器

    ->应用服务器和数据服务器分离

    ->使用缓存改善性能

    ->使用集群改善并发

    ->数据库地读写分离

    ->使用反向代理和cdn加速

    ->使用分布式文件和分布式数据库

    ->业务拆分

    ->分布式服务

    架构设计——架构知识体系

     

    业务架构是生产力,应用架构是生产关系,技术架构是生产工具。业务架构决定应用架构,应用架构需要适配业务架构,并随着业务架构不断进化,同时应用架构依托技术架构最终落地。

    企业一开始业务比较简单,比如进销存,此时面向内部用户,提供简单的信息管理系统(MIS),支持数据增删改查即可,单体应用可以满足要求。

    随着业务深入,进销存每块业务都变复杂,同时新增客户关系管理,以更好支持营销,业务的深度和广度都增加,这时需要对系统按照业务拆分,变成一个分布式系统。

    更进一步,企业转向互联网+战略,拓展在线交易,线上系统和内部系统业务类似,没必要重做一套,此时把内部系统的逻辑做服务化改造,同时供线上线下系统使用,变成一个简单的SOA架构。

    紧接着业务模式越来越复杂,订单、商品、库存、价格每块玩法都很深入,比如价格区分会员等级,访问渠道(无线还是PC),销售方式(团购还是普通)等,还有大量的价格促销,这些规则很复杂,容易相互冲突,需要把分散到各个业务的价格逻辑进行统一管理,以基础价格服务的方式透明地提供给上层应用,变成一个微内核的SOA架构。

    同时不管是企业内部用户,还是外部顾客所需要的功能,都由很多细分的应用提供支持,需要提供portal,集成相关应用,为不同用户提供统一视图,顶层变成一个AOA的架构(application orientated architecture)。

    4、衡量架构的合理性


    架构为业务服务,没有最优的架构,只有最合适的架构, 架构始终以高效,稳定,安全为目标来衡量其合理性。

    一、稳定性。指标:

    1. 高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

    二、高效指标:

    1. 文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

    2. 可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

    3. 高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

    三、安全指标

    1. 安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

    5、常见架构误区


    误区1——架构专门由架构师来做,业务开发人员无需关注:架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

    误区2——架构师确定了架构蓝图之后任务就结束了:架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

    误区3——不做出完美的架构设计不开工:世上没有最好架构,只有最合适的架构。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

    6、架构知识体系


    架构演进

    • 初始阶段:LAMP,部署在一台服务器
    • 应用服务器和数据服务器分离
    • 使用缓存改善性能
    • 使用集群改善并发
    • 数据库地读写分离
    • 使用反向代理和cdn加速
    • 使用分布式文件和分布式数据库
    • 业务拆分
    • 分布式服务

    架构模式

    • 分层:横向分层:应用层,服务层,数据层
    • 分割:纵向分割:拆分功能和服务
    • 分布式
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 集群:提高并发和可用性
    • 缓存:优化系统性能
    • cdn
    • 方向代理访问资源
    • 本地缓存
    • 分布式缓存
    • 异步:降低系统的耦合性
    • 提供系统的可用性
    • 加快响应速度
    • 冗余:冷备和热备,保证系统的可用性
    • 自动化:发布,测试,部署,监控,报警,失效转移,故障恢复
    • 安全:

    架构核心要素

    • 高性能:网站的灵魂
    • 性能测试
    • 前端优化
    • 应用优化
    • 数据库优化
    • 可用性:保证服务器不宕机,一般通过冗余部署备份服务器来完成
    • 负载均衡
    • 数据备份
    • 自动发布
    • 灰度发布
    • 监控报警
    • 伸缩性:建集群,是否快速应对大规模增长的流量,容易添加新的机器
    • 集群
    • 负载均衡
    • 缓存负载均衡
    • 可扩展性:主要关注功能需求,应对业务的扩展,快速响应业务的变化。是否做法开闭原则,系统耦合依赖
    • 分布式消息
    • 服务化
    • 安全性:网站的各种攻击,各种漏洞是否堵住,架构是否可以做到限流作用,防止ddos攻击。
    • xss攻击
    • sql注入
    • csr攻击
    • web防火墙漏洞
    • 安全漏洞
    • ssl

    7、架构书籍推荐


    1. 《大型网站技术架构:核心原理与案例分析》

    这是比较早,比较系统介绍大型网站技术架构的书,通俗易懂又充满智慧,即便你之前完全没接触过网站开发,通读前几章,也能快速获取到常见的网站技术架构及其应用场景。非常赞。

    2. 《亿级流量网站架构核心技术》

    相比《大型网站技术架构》的高屋建瓴,开涛的这本《亿级流量网站架构核心技术》则落实到细节,网站架构中常见的各种技术,比如缓存、队列、线程池、代理……,统统都讲到了,而且配有核心代码。甚至连 Nginx 的配置都有!

    如果你想在实现大流量网站时找参考技术和代码,这本书最合适啦。

    3. 《架构即未来》

    这是一本“神书”啦,超越具体技术层面,着重剖析架构问题的根源,帮助我们弄清楚应该以何种方式管理、领导、组织和配置团队。

    4. 《分布式服务架构:原理、设计与实战》

    这本书全面介绍了分布式服务架构的原理与设计,并结合作者在实施微服务架构过程中的实践经验,总结了保障线上服务健康、可靠的最佳方案,是一本架构级、实战型的重量级著作。

    5. 《聊聊架构》

    这算是架构方面的一本神书了,从架构的原初谈起,从业务的拆分谈起,谈到架构的目的,架构师的角色,架构师如何将架构落地……强烈推荐。

    不过,对于没有架构实践经验的小伙伴来讲,可能会觉得这本书比较虚,概念多,实战少。但如果你有过一两个项目的架构经验,就会深深认同书中追本溯源探讨的架构理念。

    6. 《软件架构师的12项修炼》

    大多数时候所谓的“技术之玻璃天花板”其实只是缺乏软技能而已。这些技能可以学到,缺乏的知识可以通过决定改变的努力来弥补。

    展开全文
  • 像学写文章一样,在学会字、词、句之后,就应上升到段落...软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。  软件设计人员学习软件架构知识旨在站在...

         像学写文章一样,在学会字、词、句之后,就应上升到段落,就应追求文章的“布局谋篇”,这就是架构。通俗地讲,软件架构设计就是软件系统的“布局谋篇”。

        人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。

        软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

       1 软件架构概述 

        软件架构是软件抽象发展到一定阶段的产物,从编程的角度,可以清晰地看到软件抽象层次和表达工具的发展历史。

    • 20 世纪 60 年代是子程序的年代:出现了原始的软件架构,即子程序,并以程序间的调用为连接关系。

    • 20 世纪 70 年代是模块化的年代:出现了数据流分析、实体—关系图(E-R 图)、信息隐藏等工具和方法,软件的抽象层次发展到了模块级。

    • 20 世纪 80 年代是面向对象的年代:基于模块化的编程语言进一步发展成面向对象的语言,继承性地增加了一种新元素之间的连接关系。

    • 20 世纪 90 年代是框架的年代:标准的基于对象的架构以框架的形式出现了。如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象,可以相互嵌入。

    • 当前(最近 10 年来):中间件和 IT 架构作为标准平台出现,用可购买可复用的元素来构建系统,同时,基于架构的开发方法和理论不断成熟。

    1  软件架构的定义 

        软件架构仍在不断发展中,还没有形成一个统一的、公认的定义,这里仅举出几个较权威的定义。

        定义 1:软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

        定义 2:软件架构为软件系统提供了一个结构、行为和属性的高级抽象,由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

        定义 3:软件架构是指一个系统的基础组织,它具体体现在:系统的构件,构件之间、构件与环境之间的关系,以及指导其设计和演化的原则上。(IEEE1471- 2000)

       前两个定义都是按“元素—结构—架构”这一抽象层次来描述的,它们的基本意义相同,其中定义 1 较通俗,因此,本章采用这一定义。该定义中的“软件元素”是指比“构件”更一般的抽象,元素的“外部可见属性”是指其他元素对该元素所做的假设,如它所提供的服务、性能特征等。

        为了更好地理解软件架构的定义,特作如下说明:

        (1)架构是对系统的抽象,它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此,仅与内部具体实现有关的细节是不属于架构的,即定义强调元素的“外部可见”属性。

        (2)架构由多个结构组成,结构是从功能角度来描述元素之间的关系的,具体的结构传达了架构某方面的信息,但是个别结构一般不能代表大型软件架构。

        (3)任何软件都存在架构,但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时,则该文档不能反映架构。

        (4)元素及其行为的集合构成架构的内容。体现系统由哪些元素组成,这些元素各有哪些功能(外部可见),以及这些元素间如何连接与互动。即在两个方面进行抽象:在静态方面,关注系统的大粒度(宏观)总体结构(如分层);在动态方面,关注系统内关键行为的共同特征。

        (5)架构具有“基础”性:它通常涉及解决各类关键的重复问题的通用方案(复用性),以及系统设计中影响深远(架构敏感)的各项重要决策(一旦贯彻,更改的代价昂贵)。

        (6)架构隐含有“决策”,即架构是由架构设计师根据关键的功能和非功能性需求(质量属性及项目相关的约束)进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的,为避免架构设计师考虑不周,重大决策应经过评审。特别是架构设计师自身的水平是一种约束,不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。

        在设计软件架构时也必须考虑硬件特性和网络特性,因此,软件架构与系统架构二者间的区别其实不大。但是,在大多情况下,架构设计师在软件方面的选择性较之硬件方面,其自由度大得多。因此,使用“软件架构”这一术语,也表明了一个观点:架构设计师通常将架构的重点放在软件部分。

        将软件架构置于商业背景中进行观察,可以发现软件架构对企业非常重要。

        (1)影响架构的因素。软件系统的项目干系人(客户、用户、项目经理、程序员、测试人员、市场人员等)对软件系统有不同的要求开发组织(项目组)有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。

    这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求,影响架构设计师的决策,从而影响架构。

        (2)架构对上述诸因素具有反作用,例如,影响开发组织的结构。架构描述了系统的大粒度(宏观)总体结构,因此可以按架构进行分工,将项目组为几个工作组,从而使开发有序;影响开发组织的目标,即成功的架构为开发组织提供了新的商机,这归功于:系统的示范性、架构的可复用性及团队开发经验的提升,同时,成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

    2 软件架构的重要性 

        从技术角度看,软件架构的重要性表现为如下几方面。

        (1)项目关系人之间交流的平台。软件系统的项目关系人分别关注系统的不同特性,而这些特性都由架构所决定,因此,架构提供了一个共同语言(公共的参考点),项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。

        (2)早期设计决策。从软件生命周期来看,软件架构是所开发系统的最早设计决策的体现,主要表现为:

    • 架构明确了对系统实现的约束条件:架构是架构设计师对系统实现的各方面进行权衡的结果,是总体设计的体现,因此,在具体实现时必须按架构的设计进行。

    • 架构影响着系统的质量属性:要保证系统的高质量,具有完美的架构是必要的(虽然不充分)。

    • 架构可以用来预测系统的质量,例如,可以根据经验对该架构的质量(如性能)作定性的判断。

    • 架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构,应该是在最有可能更改的地方有所考虑(架构的柔性),使其在此点最容易进行更改。

    • 架构有助于原型开发。可以按架构构造一个骨架系统(原型),例如,在早期实现一个可执行的特例,确定潜在的性能问题。

    • 借助于架构进行成本与进度的估计。

        (3)在较高层面上实现软件复用。软件架构作为系统的抽象模型,可以在多个系统间传递(复用),特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通常共享一个架构。产品线的架构是开发组织的核心资产之一,利用架构及其范例进行多系统的开发,在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使用其他组织开发的元素,例如购买商业构件。

        (4)架构对开发的指导与规范意义不容忽略。架构作为系统的总体设计,它指导后续的详细设计和编码。架构使基于模板的开发成为可能,有利于开发的规范化和一致性,减少开发与维护成本。架构可以作为培训的基础,有利于培养开发团队和培训相关人员。

       从软件开发过程来看,如果采用传统的软件开发模型(生命周期模型),则软件架构的建立应位于概要设计之前,需求分析之后。

        基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评审(评估)、实现、演化等 6 个子过程。本章各节将分别对这些子过程进行讨论。

    3 架构的模型

        软件架构作为一个有机的整体,可以分解成多个侧面来认识,每个侧面强调它的不同方面的特征,从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模型:结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型。

        (1)结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构,并力图通过结构来反映系统的重要语义内容,包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。

        (2)框架模型。框架模型与结构模型类似,但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

        (3)动态模型。动态模型是对结构或框架模型的补充,研究系统“大颗粒”的行为性质。例如,描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。

        (4)过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

        (5)功能模型。该模型认为架构由一组功能构件按层次组成,且下层向上层提供服务。它可以看作是一种特殊的框架模型。

        这 5 种模型各有所长,也许将 5 种模型有机地统一在一起,形成一个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统一体,通过这些模型的表述(文档)来完整反映软件架构。例如,Kruchten 在 1995 年提出了一个“4+1”的视图模型。“4+1” 视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面,5 个视图结合在一起才能反映系统的软件架构的全部内容。“4+1”视图模型如图 9-1 所示。

        (1)逻辑视图:主要支持系统的功能需求,即系统提供给最终用户的服务。在逻辑视图中,系统分解成一系列的功能抽象,这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析,而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中,通过抽象、封装和继承,可以用对象模型来代表逻辑视图,用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格,逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

        (2)开发视图:也称为模块视图,主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织,这样,对于一个软件系统,就可以由不同的人进行开发。开发视图要考虑软件内部的需求,如软件开发的容易性、软件的重用和软件的通用性,要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度,也可以在确定每个元素之前,列出开发视图原则。

        (3)进程视图:侧重于系统的运行特性,主要关注一些非功能性的需求,例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力,以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象,每个级别分别关注不同的方面。

        (4)物理视图:主要考虑如何把软件映射到硬件上,它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时,各视图中的构件都直接或间接地对应于系统的不同节点上。因此,从软件到节点的映射要有较高的灵活性,当环境改变时,对系统其他视图的影响最小。

        (5)场景:可以看作是那些重要系统活动的抽象,它使四个视图有机地联系起来,从某种意义上说,场景是最重要的需求抽象。在开发架构时,它可以帮助设计者找到架构的构件和它们之间的作用关系。同时,也可以用场景来分析一个特定的视图,或描述不同视图构件间是如何相互作用的。场景可以用文本表示,也可以用图形表示。

        希赛教育专家提示:逻辑视图和开发视图描述系统的静态结构,而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说,侧重的角度也有所不同。例如,对于管理信息系统来说,比较侧重于从逻辑视图和开发视图来描述系统,而对于实时控制系统来说,则比较注重于从进程视图和物理视图来描述系统。

    展开全文
  • 软件架构架构风格

    2018-09-01 16:44:20
    今天给大家分享一下架构方面的东西。都是一些相对基础的东西,有错误的话请指正。 首先我们来介绍一下什么是架构架构一词来源于建筑,代表系统高层次的一些设计角色。比如建筑领域的一栋大楼的架构,指的就是大楼...
  • 甚至于很多架构师一说架构,就开始谈论什么应用架构、硬件架构、数据架构等等。......本文是漫谈架构专栏的第一篇,作者将会通过类比的方式来介绍什么是架构以及为什么会产生架构。一直以来,在软件行业,对于什么是...
  • 软件各种系统架构

    2017-12-08 10:53:44
    发布一企业技术架构图,供大家参考。     该技术架构图是本人根据多年企业技术架构经验而制定,是企业技术的总架构图,希望对CTO们有所借鉴。  简单说明: 1.中间件基础运行环境是经过统一...
  • 愿景已经确定架构愿景和目标。 需求分析明确架构要解决当前什么问题。 那接下来就是如何着手开始做架构设计。 一、如何开始设计一个架构:方式方法 架构不是像平常写代码一样,对就是对,错就是错,它并无对错...
  • 一、微服务架构实施的前提 二、微服务实施的三大模式 三、实施微服务架构的优势 (一)、六大技术优势 (二)、业务与组织优势 四、实施微服务面临的挑战 (一)、技术架构的挑战 (二)、研发过程的挑战 ...
  • 1.SOA架构和微服务架构的区别首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。 1.SOA(Service Oriented Architecture)“面向...
  • 系统架构设计师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。 系统架构设计师考试合格人员能够根据系统需求规格说明书,结合应用领域和技术...
  • 共享平台逻辑架构设计 如上图所示为本次共享资源平台逻辑架构图,上图整体展现说明包括以下几个方面: 1 应用系统建设 本次项目的一项重点就是实现原有应用系统的全面升级以及新的应用系统的开发,从而建立...
  • 应用架构 应用架构(Application Architecture)是描述了IT系统功能和技术实现的内容。应用架构分为以下两个不同的层次: 企业级的应用架构:企业层面的应用架构起到了统一规划、承上启下的作用,向上承接了企业...
  • 1、什么是架构架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这...
  • 1. 软件架构设计的What & Why ● 啥是软件架构(Software Architecture)? 软件架构是指在一定的设计原则基础上,从不同角度对组成系统的各部分进行搭配和安排,形成系统的多个结构而组成架构,它包括该系统...
1 2 3 4 5 ... 20
收藏数 1,758,088
精华内容 703,235
关键字:

架构