软件架构设计

标签: 软件架构 设计 | 发表时间:2014-10-31 12:31 | 作者:robin88129
出处:http://www.iteye.com

【一】-软件架构设计过程

软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:

1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题。

2.解决方案设计:根据业务战略,形成行业信息化解决方案。他是一个系统组,同时明确各系统间的支撑关系。

3.系统功能设计:明确信息化系统功能列表及功能层次(层次,例如经验决策层工,管理层功能,业务操作功能等),将功能散列在这些层次中,根据功能及应用特点形成一个或者多个子系统。可参考下图理解。

4.系统架构设计:针对某一系统明确系统IT支撑表达,层次化关系表达及功能、技术核心元素

5.技术体系设计:针对系统的接口、数据存储,技术路线、部署及实现抽象进行设计

总体过程如下图所示

【二】-系统总体架构设计

统总体架构非常重要,但在表达上都不尽相同,下面介绍几种常用的系统架构模式,供参考:

ASSF(access-service(biz)-standard-fundation)模式:访问-服务(业务功能)-标准-基础,对系统架构各个层次均有表达,但部署应用模式需要有单独说明,如下图方式组织系统总体架构:

Location模式:适合集团级应用,对于应用逻辑表达较为清晰,如下图所示:

3 management-level模式:表达从决策层-管理层-操作层各个层次使用的功能。对于系统功能表达较为清晰,对于与客户达成一致性理解有较好效果,如下图所示:

个人比较推荐ASSF模式做为主架构,同时制定Location模式与3management-level模式附加说明系统,从各个层次表达系统架构。

【三】-系统架构中的数据分布设计

在大型系统中,数据分布设计非常重要,整理数据分布设计的6中常见策略,仅供参考:

独立Schema:当一个大系统由相关的多个小系统组成,且不同小系统具有互不相同的数据库Schema定义。独立模式可管理性高,通信开销小。

集中:一个大系统必须支持来自不同地方的访问,或者该系统由多个不同的小系统组成,而数据进行集中化,统一格式存储。可管理性、数据一致性高。


 

分区:分为水平分析与垂直分区,当系统为“地域分布广泛的用户”提供“相同服务”时,常常使用水平分区策略。垂直分区为字段分隔,一般较少使用。采用分区方式,可伸缩性好。

复制:在整个分布式系统中,保存多个副本、并且以某种机制保持多个数据副本之间的数据一致性。复制方式可有效提升数据可靠性。

子集:“子集”是“复制”的特殊方式,就是某节点因功能或非功能考虑而保持全体数据的一个相对固定的子集。


 

重组:不同数据节点因要支持的功能不同,而以不同的schema保持数据---但本质上数据时同源的。重组以“重新组织”的格式进行传递和保持。


 

6中策略总结可以使用如下图表示:


 

在应用过程中,应当灵活使用各种策略,策略应用的一般化原则如下所示:


 

总结:在应用过程中,根据实际应用进行分析,选择合适的数据分布策略,也可以组合使用,合适的数据分布策略将使系统的稳定性及功能满足新大大提高,可以使用如下过程确定数据分布策略:

在表格中列出6种不同的数据分布策略,如下表所示:

名称 对吗 好吗 总分
独立 是/否 0~100分  
...    
 

根据系统应用特点,通过以上分析,去除不适用的策略,根据总分确定所采用的数据分布策略,在有些地方也可以使用组合策略。

【四】-系统架构中的数据集成设计

在系统架构设计中,经常面临多个业务系统数据集成共享的问题,以下主要分享数据集成设计的相关内容。

数据物理集中:将全部数据放在一起,由一个统一的数据库服务器管理,实现数据统一访问,访问效率高、适合大数据量查询的决策分析应用其缺点是实时性较差、风险大、时间长

逻辑集中:适用于业务系统分布在多个地方,由统一的整合平台实现各物理分布数据之间的数据共享,可实时访问分布在各处的数据,实施速度快,其缺点是受网络传输影响,不适合长事物。

例如在销售行业的客户信息集成,如果是逻辑集中,那就是客户数据依然存在于各个地方,但是可以通过统一的数据整合平台进行访问。如果是物理集中,则可以通过集中的数据库进行访问。

推荐结合逻辑集中与物理集中的优势,在实施初期采用逻辑集中,快速实现统一访问与数据共享,对访问量大、实时性要求不高的数据逐步实现物理集中,从而提高访问效率,类似于BI技术中的自顶向下与自底向上想结合的数据集成策略。

下面介绍数据集成设计的三种常用模式:

数据联邦模式(DataFederation):将分布的数据逻辑集中,应用通过访问整合平台的虚拟数据库进行数据访问,数据在不同数据库实例中,此时,数据整合平台做为数据访问通道。

数据复制模式(Data Replication):采用数据复制模式,通过数据一致性服务

实现多个数据源的数据一致性,各数据库均保留共享数据备份。

基于接口的数据集成模式(Interface Level):系统间通过接口适配器方式共享数据,比较适合实时性较高且数据量较小应用。接口模式适合分区及独立模式的数据集成。

在实际应用中,可以根据特点,灵活选用相应的策略。

【五】-应用集成设计

系统架构设计中,多个系统经常需要进行应用交互,这时就需要进行应用集成设计,介绍几种常用的应用集成概念:

EAI:EAI(EnterpriseApplication Integration),是企业应用集成EAI是将基于各种不同平台、用不同方案建立的异构应用集成的一种方法和技术。EAI通过建立底层结构,来联系横贯整个企业的异构系统、应用、数据源等,完成在企业内部的ERP、CRM、SCM、数据库、数据仓库,以及其他重要的内部系统之间无缝地共享和交换数据的需要。有了EAI,企业就可以将企业核心应用和新的Internet解决方案结合在一起。

MOM:MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。MOM交互策略如下图所示:

SOA:面向服务的体系结构(Service-OrientedArchitecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

常用的应用集成交互策略如下图所示:

在实际应用过程中,只有最适合的策略,没有最好的策略,需要综合考虑实施的复杂度,理论上来说,总线模式是比较优良的应用交互策略,可以实现完全的平台无关性与服务重用,但是相对来说改造及维护难度较大,无意中也增加了应用集成的复杂度。因此,在选择过程中需要谨慎评估集成规模及集成策略的适用性。如果企业中只有两个系统需要进行交互,采用硬编码的方式也有可能是非常适用的策略。

【六】-接口设计

接口设计是系统架构师的重要职责,首先明确几个概念

1.协作决定接口!

2.子系统或者实现决定接口是错误的!

给出接口设计的一般步骤如下:



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [软件架构 设计] 推荐:

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

软件架构设计(二)&mdash;&mdash;软件架构设计过程

- - BlogJava-首页技术区
      一般来讲,涉众包括客户(资方)代表、承接方(劳方)代表、用户代表.       对于要明确实现某种标准的软件系统,通常确定边界非常容易,直接按标准圈定的scope分析即可,比如像SIPServlet容器,是要求遵从JSR168规范的,那么软件系统的Scope就是JSR168规定的Scope,但是也有例外,比如客户或者劳方明确指定要复用一个现有的实现了部分功能的系统或组件,那么Scope就不同了.

论基于DSSA的软件架构设计与应用

- - CSDN博客推荐文章
去年三月份,我所在的公司启动国网电力用户用电信息采集系统项目,我被任命为项目负责人. 国网电力用户用电信息采集系统是国家电网公司坚强智能电网建设的一部分. 由于公司之前为南网(主要是广东省)开发过类似用电信息采集系统,且公司准备在电力行业做强做大,我提出了采用DSSA技术来研发国网用电信息采集系统,得到公司领导层的一致赞同.

企业架构思想在软件架构设计中的引入

- - 人月神话的BLOG
很多时候我们在谈企业架构的时候都是正对跨流程,跨业务和跨应用系统的总体规划和分析,企业架构核心好处就是真正体现业务驱动IT,将业务和IT能够真正的匹配起来思考整个企业层面的架构问题. 而很多时候我们谈软件架构的时候仅从软件实现层面来考虑问题,针对一个业务系统的开发,我们有业务建模和软件架构,但是这两个却进行了分离而缺少了系统性的思考,所以原来我们喜欢用系统分析师这个词来综合业务分析师和软件架构师两个岗位的工作.

软件架构

- - 研发管理 - ITeye博客
    对于外包业务类型的项目,软件架构设计的目的与产品类型的项目有所不同,在这里主要讨论外包类型项目的软件架构设计目的.     1、为大规模开发提供基础和规范,并提供可重用的资产,软件系统的大规模开发,必须要有一定的基础和遵循一定的规范,这既是软件工程本身的要求,也是客户的要求. 架构设计的过程中可以将一些公共部分抽象提取出来,形成公共类和工具类,以达到重用的目的.

软件架构风格 - welfear

- - 博客园_我所说的,都是错的
文档名称:软件架构风格(software architecture style). 文档维护:Xuefeng Chang(welfear@gmail.com). 文档创建:2013.07.27. 如果说设计模式是从代码角度为系统降低耦合度,那么架构风格便是从数据角度解耦. 架构是更加宏观和全面的视角,它不再是解决单一的技术问题,而是为系统提供更加.

软件架构师的沟通修炼

- - 博客 - 伯乐在线
在架构师的角色中,沟通是要求有效果的必备技能与工具. 换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段. 架构师通常没有对为其项目工作的他人的直接管理权. 他们的项目往往是跨部门的,也可能会跨好多个行业单位. 由于不能直接管理他人,所以架构师指示别人或群体完成特定行动的能力就受到限制.

软件架构师的职责

- - 研发管理 - ITeye博客
架构师需要参与项目开发的全部过程,包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段,负责在整个项目中对技术活动和技术说明进行指导和协调.     在项目开发过程中,架构师是在需求规格说明书完成后介入的,需求规格说明书必须得到架构师的认可. 架构师需要和分析人员反复交流,以保证自己完整并准确地理解用户需求.

软件架构师不等同于资深程序员

- - 研发管理 - ITeye博客
本文的作者Armel Nene是ETAPIX Global公司的首席架构师,他居住在伦敦,他参与过的开源项目包括 Apache Lucene,,Apache Nutch, Liferay 和 Pentaho等. 如今很多的公司的IT部门仍然认为招聘一个资深的程序员,他同样也能承担软件架构师的角色. 资深程序员对整个软件生命周期很了解,他们可以经过培训成为架构师,但他们不等同于架构师.

如何开展软件架构之需求分析

- - CSDN博客架构设计推荐文章
如何开展软件架构之需求分析.  在开始讨论如何开展软件架构之前,先让我们来看一张漫画. 相信大家看到这漫画的时候,总会不自主地会心一笑,客户希望得到礼物,我们却给了他一骨头. 一):未进行充分地需求分析. 解析:架构师未能初别用户群及使用环境约束因素,也许在接到项目时,他还在想着上一个为狗开发的项目,在这个项目中自然而然地认为用户是狗.