软件架构的相关概念和实践

1.1. 什么是企业应用

很难给出一个精确定义，不过企业应用一般都有这些特点：

持久化数据

大量的数据

很多人同时访问数据

大量操作数据的用户界面

通常要与散布在企业周围的其他企业应用集成

所以，企业应用一般都比较复杂，架构设计大多都是针对企业应用的。

1.2. 什么是系统架构

“架构”用很多种不同的定义，这些定义很难统一，但基本上有两点都能统一：1）架构是最高层次的分解 2）架构是系统中不易改变的决定。

而通过这次架构培训，我这么定义架构：从核心概念上讲，架构是一套构建系统的规则；从表象上看，软件架构是一套模板，以文档、代码、工具程序等方式表现。

软件架构的成果是一套模板，这套模板会通过一种方式去组织，这个组织形式也很重要，应该从不同视角去表现，以适合不同人去理解和应用。

1.3. 系统架构设计师干什么

根据系统架构的定义，系统架构师的职责当然是制定软件系统构建规则，不过一般认为，系统架构师的主要职责有：

1） 负责领导和协调整个项目中的技术活动

2） 在个人综合素养方面，系统构架师应该具有领导才能，能够在压力下作出关键性的决策并善始善终；

3） 能够赢得项目经理、客户、用户群体以及管理团队的认同和尊敬，尤其要善于和项目经理紧密协作；

4） 在各个方面都能展现出面向目标的实干作风。在专业技能方面，与其他角色相比，系统构架师通常具有全方位的技能，其见解重在广度，而不是深度。

5） 系统构架师不仅需要具备设计师的各项技能，而且应该具有问题领域和软件工程领域的实践经验，从而有能力在无法获得完整信息的情况下迅速领会问题并根据经验作出审慎的判断。

6） 如果项目较大，系统构架师将是一个团队，上述的关键素质要求可由团队成员来分担，但其中要有一名系统构架师具有足够的权威。

架构师与设计师的职责有所不同，最重要的是架构师工作的关注点是软件系统的全局问题，他是制定软件系统的规则和原则的，对整个软件系统进行规划；设计师相对来说是关注软件系统的局部和具体问题，把架构师的架构设计进行细化。

架构师是由国外引进的一个概念，国外软件开发的几个职位是技术官、架构师、设计师、开发、测试，对应我们公司应该是技术总监、架构师、系统分析员、程序员、测试人员。

1.4. 常用架构设计模式

很多OO设计原则和设计模式同样适用与架构设计，架构中使用这些原则的主要目的是为了使架构具有更好的可维护性和可复用性，并使架构具有稳定性，这些目的也是一个架构的核心价值所在。

模式的定义也不统一，一般是这样的解释，每个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。（在古代流传至今的“三十六计”就是 三十六个模式，对中国人来说，这可能是让人最容易理解模式概念的一个类比。）使用模式能够减少设计的难度，更能加快设计人员之间交流和沟通。

以下是几个常用的顶层架构设计的模式

1） 分层模式

2） MVC模式

3） 客户/服务器模式

4） 流程处理模式

1.5. AOP

AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向方面编程。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可 以说也是这种目标的一种实现。AOP是近两年比较热门的技术，给我们带来了一个新的视角和软件架构方法。

通过使用AOP技术，可以把分散在多个模块中共同的行为分离出来统一编程，减少重复代码。

AOP和OO、SOA一样，都是架构设计中的重要视角。

1） 基本原理

AOP机制一般都需要开发语言和编译器支持，Java和。C#都支持。实现AOP有不同的方法，常见的方法是利用代理机制，其基本原理是为“其他对象提供一种代理，以控制对这个对象的访问”。

2） 常见使用AOP技术的地方

Authentication 权限验证

Caching 缓存

Context passing 内容传递

Error handling 错误处理

Lazy loading　懒加载

Debugging　　调试

logging, tracing, profiling and monitoring　记录跟踪　优化　校准

Performance optimization　性能优化

Persistence　　持久化

Resource pooling　资源池

Synchronization　同步

 

Transactions 事务

 

3） AOP也可以用于封装业务逻辑

 

比如，进销存软件中，更多模块的功能操作都需要重新计算库存，所以可以把库存计算分离出来，用AOP技术偶合到那些功能模块中。

 

在业务功能模块中用AOP技术很多情况下都不是很经济，因为业务逻辑复杂多变，可能经过仔细分析抽取出共性代码会因为一个需求变化而变得不再适用，不如用普通方法实现需求变化来得方便和简单。因此，AOP技术在做基础框架平台、组件容器时用得比较多。

 

1.6. SOA

 

1） 什么是SOA

 

关于SOA，可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。

 

Service-architecture.com将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个
或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

 

Looselycoupled.com将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。”

 

Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”

从概念的角度，SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。

2） SOA架构有哪些基本的要求：

SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用；

服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关；

灵活的架构 －－服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明；

3） 架构设计中的SOA视角

在架构设计中，SOA是一个非常重要的视角。SOA以一种粗粒度的角度去分解系统的不同功能，去分析不同功能服务之间的关系和接口，不同功能服务之间是松散偶合的。SOA也是解决不同系统功能集成和异构系统之间功能互用的一个比较不错的解决办法。

一般提到SOA时，都会把它和Web Service联系到一起，因为目前Web Service是最能表达SOA架构的技术。

4） SOA的引申

SOA的出现应该说是一个必然的过程，是软件行业发展中必然会出现的一个概念。软件一开始是一些代码行，代码行多了之后就成了代码块或者叫子程序，然后就 继续发展出了函数，随着OO的出现，为了便于管理函数出现了类和类库，类库多到难以管理的时候出现了组件的概念，当软件复杂到组件这个概念仍现粒度太细的 时候，就出现了服务这个概念，系统架构就对应出现了SOA概念。由此可以推论，不久以后，软件业一定还会出现粒度更大的软件概念，它由多个服务组成。

现在是SOA发展的初级阶段，SOA为在线服务的商业模式提供了很好的技术手段，随着可用的服务越来越多，服务越来越方便和可靠，一定会出现很多以服务 （狭义的概念，指软件的某项功能）进行盈利的组织，一大类是专业的在线服务提供商，提供各种类型的软件功能，提供服务租赁；当可用服务爆炸式增长后，寻找 到合适的服务会越来越难，这时就会出现另一类公司――在线服务集成商，他们对无数的在线服务进行评测和筛选，然后按照客户的需求或行业的需求提供服务包解 决方案。

1.7. ESB

1） 什么是ESB

ESB（Enterprise Service Bug，企业服务总线）是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：

面向服务的架构：分布式的应用由可重用的服务组成

面向消息的架构：应用之间通过ESB发送和接受消息

事件驱动的架构：应用之间异步地产生和接收消息

通俗地说，ESB就是在SOA架构中实现服务间智能化集成与管理的中介。它与SOA的关系是：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。ESB实现了SOA三个基本要求中的第三个。

ESB是特定环境下（SOA架构中）实施EAI的方式，应为被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台。

ESB明确强调消息（Message）处理在集成过程中的作用。

事件驱动成为ESB的重要特征

2） ESB适用场景

ESB应该构筑在完善的SOA架构上，它应该做的事是服务集成。它的常见应用模式是协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情形。

消息广播模式，用于事件驱动多个动作或者消息广播的情形。

服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容，或负载情况，或服务级别约定（SLA），来为服务请求者选择合适的服务。

1.8. 区分出非功能性需求

1） 什么是非功能性需求

非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。

2） 重要吗？

在设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。

很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。

3） 非功能性需求要考虑那些方面

非功能性的特性一般有这些：

可靠性

只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。

有一些问题应该自问一下：

* 即使硬件出现故障，系统也可以可靠运行吗？

* 复制和故障转移方案是什么？

* 需要手动干预，还是系统可以自动进行故障转移？

* 实现可靠性会对性能造成负面影响吗？

* 实现可靠性的成本有多高？

可靠性需要考虑的一些具体方面是：

安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。

事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（SOA 就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 （two phase commit）。

可用性

如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是：

* 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？

* 系统是否根据模型-视图-控制器 （Model-View-Controller） 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？

* 是否界面本来就有状态而功能无状态（反之亦然）？

有效性

如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：

性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗

可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）

可维护性

这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承 担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的 部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？

可移植性

虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 （mousetrap） 您就必须重写整个应用程序，则没有人会问津。

2. 公司的软件架构

2.1. 技术战略

2.1.1. 定位

公司长期的战略重点在于为电力行业提供解决方案和各种技术服务，因此公司软件技术要长期地为电力行业服务。所以，公司的技术体系架构的定位是面向电力行业的企业级应用技术架构。

出于电力行业市场目前情况和发展趋势的综合考虑，公司同时发展JavaEE和。Net技术，其中JavaEE技术定位在高端企业级解决方案，当中的。Net技术重点在于提供低成本的企业级应用解决方案。

2.1.2. 技术依赖性

公司在战略上提倡拥有自己的核心技术，同时也提倡快速集成应用第三方技术，因此公司的技术体系架构尽量减少对第三方技术的依赖性，应该使公司的技术体系架构符合各种国际标准，能够容易的集成和替换第三方技术。

2.1.3. 技术体系的功能复用

公司同时发展。Net、JavaEE、嵌入式三条技术路线，为了避免同样的功能在不同技术体系下重复实现，浪费开发资源，公司的技术体系架构必须充分考虑多个技术体系功能的复用能力，努力使不同技术体系下应用系统能够使用其他技术体系下的功能，也能为其他技术体系下的应用系统提供服务。

另外，在设计时，也更多地体现一些与平台无关性的设计，以方便不同技术体系架构设计的成果公用。

2.1.4. 技术更新的应对策略

公司在电力行业市场上将会长期发展，这个战略重点会保持10年以上的时间，而技术的发展更新换代比较快，尤其是Microsoft的技术。对此，公司的技术体系架构的应对策略是要做到“设计起点高，发展前景广”。设计起点高是指在架构设计起始就尽量采用已达到实用化的最先进的技术，保证这些技术有更长的生命周期；发展前景广是指设计时多考虑架构的可持续发展能力，使技术架构能够方便地集成新技术，替换老技术。公司的技术体系架构设计的生命周期应在5－10年。

2.2. 最佳实践

说明：分成三个层次，

最底层是基础框架层，主要提供对象的管理、数据的存取和转换、日志、事务处理等的基础服务功能，通过封装成企业服务接口对上层提供服务。

中间层次是业务领域层次，在这层内部可以分成业务基础领域层和电力领域层，业务基础层提供了通用领域的业务管理服务，比如文档处理服务、工作流处理、报表 处理等；电力领域层则提供了电力行业相关的特殊领域模型和服务，比如基于61970的电网领域，资产和物资管理领域等，这一层通过封装成业务功能服务接口 对上层提供服务。

最上层是展现层，展现层内部也分为两个层次，底层是UI处理层，主要作用是管理一些固定化的UI逻辑，根据各种状态选择前端的用户界面视图。向上是界面层，按照表现形式分成B/S、C/S、移动终端三种。

按照这个架构，根据使用技术的不同，可以分为。Net和J2EE两 个实现版本。不过，为了避免重复开发又兼顾技术体系的特殊性，这三个层次中的基础架构层应该用两种技术分别实现出一套框架程序并提供企业服务接口，其他两 层的功能可以使用任意的技术实现，并且每种功能尽量只实现一次，通过集成技术把不同技术体系的功能组合成业务系统。企业服务总线主要解决的问题是提供异构 系统的功能集成。