孤寂de心
什么是软件系统架构设计
“架构”一词最早来自建筑学，原意为建筑物设计和建造的艺术。
但是在软件工程领域，软件架构不是一个新名词，只是在早期的著作中人们将软件架构称为软件体系架构。
这就是架构的概念。
所谓架构，就是人们对一个结构内的元素及元素间关系的一种主观影射的产物。
系统架构的主要任务是界定系统级的功能与非功能要求、规划要设计的整体系统的特征、规划并设计实现系统级的各项要求的手段，同时利用各种学科技术完成子系统的结构构建。
在系统架构中，由于对软件越来越深入的依赖，软件架构的任务也体现出重要的作用。
而且系统架构与软件架构是紧密联系和相互依赖的。
1997年，Eberhadrt Rechtin 与MarkW Maier 在其论著中，为计算机科学总结了系统架构方面的实践成果，从而奠定了系统科学和系统架构在计算机科学中的基石：无论何种系统架构应用领域，目的都是一样的，即完整地、高一致性的、平衡各种利弊的、有技术和市场前瞻性的设计系统和实施系统。
什么是系统架构设计？
不同的架构方法论，会将架构分为不同视图，每个视图侧重某一个方面、领域的问题。
比如希赛推的ADMEMS架构体系，分为以下几种视图：1. 数据架构：描述数据的存储结构、格式等方面。
2. 物理架构：描述机器的物理部署、网络拓扑方面。
3. 运行架构：描述运行期线程、进程间的交互工作机制。
4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。
5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。
例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。
埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。
像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。
当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。
就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。
当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。
总的来说，一说到架构，如果懂软件，那么会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务……但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及如何链接在一起。
倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。
而采取分离式设计时，最容易的错误就是各自为政，集成困难。
那么以数据为中心的架构设计，会自然提供集成的基础。
提到过，企业最重要的资产是数据，甚至不是信息，是数据。
企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。
这有点象自然演进，考古那种，啥都
系统构架的架构分类
第一种是基础架构的设计规划，例如：OS，硬件，网络，各种应用服务器等等。
第二种是软件开发设计的架构师，他们负责规划程序的运行模式，层次结构，调用关系，规划具体的实现技术类型，甚至配合整个团队做好软件开发中的项目管理。
软件架构设计和企业架构模式之间的关系是什么？
一般而言，架构有两个要素：它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。
详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（Task-flow）。
所谓架构元素，也就是组成系统的核心＂砖瓦＂，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。
显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代，历史非常短暂，而相比之下建筑工程则从石器时代就开始了，人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点，一是建筑风格，二是建筑模式。
独特的建筑风格和恰当选择的建筑模式，可以使一个独一无二。
正如同软件本身有其要达到的目标一样，架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：·可靠性（Reliable）。
软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。
·安全行（Secure）。
软件系统所承担的交易的商业价值极高，系统的安全性非常重要。
·可扩展性（Scalable）。
软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。
只有这样，才能适应用户的市场扩展得可能性。
·可定制化（Customizable）。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性（Extensible）。
在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展
软件架构模式基本概念及三者区别
在做软件架构设计时，根据不同的抽象层次可分为三种不同层次的模式：架构模式（Architectural Pattern）、设计模式（Design Pattern）、代码模式（Coding Pattern）。
架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。
架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。
这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。
模式的好坏不会影响到系统的总体布局和总体框架。
设计模式定义出子系统或组件的微观结构。
代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。
代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
架构模式（Architectural Pattern）一个架构模式描述软件系统里的基本的结构组织或纲要。
架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
称之为系统模式。
?MVC模式，一个架构模式常常可以分解成很多个设计模式的联合使用。
MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
?Layers（分层）模式，有时也称Tiers模式?Blackboard（黑板）模式?Broker（中介）模式?Distributed Process（分散过程）模式?Microkernel（微核）模式架构模式常常划分成如下的几种：一、 模块结构（From Mud to Structure）型。
帮助架构师将系统合理划分，避免形成一个对象的海洋。
包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
二、分散系统（Distributed Systems）型。
为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。
如Reflection（反射）模式、Microkernel（微核）模式等。
设计模式（Design Pattern）一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。
设计模式在特定的编程语言中实现的时候，常常会用到代码模式。
比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。
代码模式（Coding Pattern）代码模式（或成例）是较低层次的模式，并与编程语言密切相关。
代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等
架构的种类
根据我们关注的角度不同，可以将架构分成三种：1.逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等。
如图是一个逻辑架构的例子 从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次。
每一个层次都含有多个逻辑元件。
比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等。
2.物理架构、软件元件是怎样放到硬件上的。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器。
主机等等。
如图是一个物理架构的例子3.系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作。
此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定。
首先，一个软件系统中的元件首先是逻辑元件。
这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息。
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。
这些决定中会有很多是一旦做出，就很难更改的。
为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式。
在 Rational Unified Process 中，软件构架文档记录有这种描述。
我们决定以多种构架视图来表示软件构架。
每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师、维护人员等）所关注的特定方面。
构架视图显示了软件构架如何分解为构件，以及构件如何由连接器连接来产生有用的形式 ，由此记录主要的结构设计决策。
这些设计决策必须基于需求以及功能、补充和其他方面的约束。
而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
构架由许多不同的构架视图来表示，这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。
在 Rational Unified Process 中，您将从一个典型的视图集开始，该视图集称为“4+1 视图模型”。
它包括：用例视图：包括用例和场景，这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。
它是用例模型的子集。
逻辑视图：包括最重要的设计类、从这些设计类到包和子系统的组织形式，以及从这些包和子系统到层的组织形式。
它还包括一些用例实现。
它是设计模型的子集。
实施视图：包括实施模型及其从模块到包和层的组织形式的概览。
同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。
它是实施模型的子集。
进程视图：包括所涉及任务（进程和线程）的描述，它们的交互和配置，以及将设计对象和类向任务的分配情况。
只有在系统具有很高程度的并行时，才需要该视图。
在 Rational Unified Process 中，它是设计模型的子集。
配置视图：包括对最典型的平台配置的各种物理节点的描述以及将任务（来自进程视图）向物理节点分配的情况。
只有在分布式系统中才需要该视图。
它是部署模型的一个子集。
构架视图记录在软件构架文档中。
您可以构建其他视图来表达需要特别关注的不同方面：用户界面视图、安全视图、数据视图等等。
对于简单系统，可以省略 4+1 视图模型中的一些视图。
虽然以上视图可以表示系统的整体设计，但构架只同以下几个具体方面相关： 模型的结构，即组织模式，例如分层。
基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。
几个关键场景，它们表示了整个系统的主要控制流程。
记录模块度、可选特征、产品线状况的服务。
构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。
在考虑以下方面时，这些特征非常重要：1.系统演进，即进入下一个开发周期。
2.在产品线环境下复用构架或构架的一部分。
3.评估补充质量，例如性能、可用性、可移植性和安全性。
4.向团队或分包商分配开发工作。
5.决定是否包括市售构件。
6.插入范围更广的系统。
无人机软件架构知多少
“架构可定义为组件的结构及它们之间的关系，以及规范其设计和后续进化的原则和指南。
简言之，架构是构造与集成软件密集型系统的深层次设计7“。
也可称其为如何实施解决 方案的一个策略性设计（例如基于组件的工程标准、安全）和解决方案做什么的功能性设计（如算法、设计模式、底层实现）。
1996 年 Garlan 和 Shaw 在《软件架构：一门新兴学科的展望》1 中写到架构问题包括：系统组件构成的组织、全局控制结构、通信协议、同步和数据访问等。
他们研究了软件开发者常用的系统组织模式，包括数据流系统、调用及返回系统、虚拟机、以数据为中心的系统（数据库）、分布式进程和特定领域的软件架构。
针对给定问题或领域，确定最优秀的架构是一个永恒的挑战。
Garlan 和 Shaw 展示了如何构造一个可变架构的设计空间，以及如何建立设计原则来根据功能需求选择应用系统。
Garlan 和 Shaw 列出了移动机器人的基本设计需求，如：（1）慎思规划和反应式行为；（2）容许不确定性；（3）考虑危险；（4）灵活性强。
针对这些要求，他们评估了四种 用于移动机器人的架构，包括控制回路（control loop）、分层（layers）、隐式调用（implicit invocation）、黑板（blackboard），如图 1 所示。
闭环控制解决方案推荐用于不处理复杂外部事件的简单机器人系统。
分层构架能很好实现构件的组织，但是在实时环境中处理外部事件时其反应过慢。
第三个 解决方案隐式调用围绕事件处理实现，用于任务控制架构（TCA）。
推荐 TCA 用于较复杂的机器人项目，并已在众多移动机器人上得到应用。
TCA 为性能、容 错、安全性和并发性提供了一套完整的任务协调机制和规定。
TCA 架构由位于同一层次的任务或任务树组成。
在运行过程中任务树会作很多动态调整以适应环境条件和机器人状态的改变。
第四种解决方案黑板构架由一个中心黑板或 数据库构成，负责接收和发送命令、共享数据和解决冲突。
它支持并发性且有异常处理程序来处理不确定性。
技术架构和架构设计有什么区别
目前国内对“架构”这个词的使用很混乱。
在很多方面、很多层次都可以用“架构”这个词。
你最好弄清楚，这个图是干什么的，用来表现什么意图的内容，在来说这个事。
从字面上解释，技术架构，就是实现某个信息系统所有使用技术的整体展现。
架构设计就是干这个的。
java架构有哪些
Java架构：软件架构作为一个概念，体现在技术和业务两个方面。
从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。
先说一些基本原则：分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。
从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。
其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则随着软件结构的进一步发展，层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。
依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。
这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。
但软件架构毕竟是建立在当前技术之上的。
而每一代技术都有架构模式。
过去的不再说了，让我们现在就来看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。
我们从三层次架构谈起：因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。
cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。
JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。
推荐作为持久层的首选在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。
而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。
在用户结构层，虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。
struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。
因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务（tool:jaas）、流程控制服务workflow、动态实现服务IOC，串行化消息服务（tool:jms）、负载平衡服务blance等。
如果我们不采用重量级应用服务器（如weblogic,websphere,jboss等）及重量级组件（EJB），我们必须自己实现其中一些服务。
虽然我们大多情况下，不需要所有这些服务，但实现起来却非易事。
幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。
随着xml作为结构化信息传输和存储地位日渐重要，一些xml文档操作工具（DOM,Digester,SAX等）的使用愈发重要，而随着xml schema的java binding工具（jaxb,xmlbean等）工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式，而这又进一步使数据中心向xml转移，使在中小数据量上，愈发倾向于以xquery为查询语言的xml数据库。
最近还有一个趋势，microsoft,ibm等纷纷大量开发中间软件如（microsoft office之infopath），可以直接从xml schema 生成 录入页面等非常实用的功能。
还有web service 的广泛应用，都将对软件的架构有非常重大的影响。
至于面向服务架构（SOA）前景如何，三层次架构什么时候走入历史，现在还很难定论。
aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。
也许作为一个很好的思想，它将在web service里大展身手。
rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。
但如果真如它所声称那样，广泛地改变着信息的结构。
那么对软件架构也会有深远影响。
有关架构设计的一些忠告：尽量建立完整的持久对象层.可获得高回报尽量将各功能分层，分块，每一模块均依赖假定的其它模块...
计算机系统有哪些层次结构？
展开全部 计算机系统层次结构，指的是计算机系统由硬件和软件两大部分所构成，而如果按功能再细分，可分为7层。
把计算机系统按功能分为多级层次结构，就是有利于正确理解计算机系统的工作过程，明确软件，硬件在计算机系统中的地位和作用。
第零级是硬联逻辑级，这是计算机的内核，由门，触发器等逻辑电路组成。
第一级是微程序级。
这级的机器语言是微指令集，程序员用微指令编写的微程序，一般是直接由硬件执行的。
第二级是传统机器级，这级的机器语言是该机的指令集，程序员用机器指令编写的程序可以由微程序进行解释。
第三级是操作系统级，从操作系统的基本功能来看，一方面它要直接管理传统机器中的软硬件资源，另一方面它又是传统机器的延伸。
第四级是汇编语言级，这级的机器语言是汇编语言，完成汇编语言翻译的程序叫做汇编程序。
第五级是高级语言级，这级的机器语言就是各种高级语言，通常用编译程序来完成高级语言翻译的工作第六级是应用语言级，这一级是为了使计算机满足某种用途而专门设计的，因此这一级语言就是各种面向问题的应用语言。
参考资料 考试资料网：http://www.ppkao.com/tiku/shiti/6695169.html...
