下牙龈根部发红:软件架构的相关概念和实践

刘爱军 序言 2006年8月底，我有幸参加了一个架构师培训，通过这个培训，清晰了很多概念，结合自己的知识和经验，对公司软件应用系统的架构设计有了很多想法，特撰写本文档，把自己学得的系统架构知识和自己的思考与大家共享，希望对公司设计人员进行设计工作时有所帮助。本文中很多内容都是我个人的观点，我个人技术的深度和广度也不够，肯定会有不少不太严谨的地方。 1. 系统架构知识 1.1. 什么是企业应用 很难给出一个精确定义，不过企业应用一般都有这些特点： l 持久化数据 l 大量的数据 l 很多人同时访问数据 l 大量操作数据的用户界面 l 通常要与散布在企业周围的其他企业应用集成 所以，企业应用一般都比较复杂，架构设计大多都是针对企业应用的。 1.2. 什么是系统架构 “架构”用很多种不同的定义，这些定义很难统一，但基本上有两点都能统一：1）架构是最高层次的分解 2）架构是系统中不易改变的决定。 而通过这次架构培训，我这么定义架构：从核心概念上讲，架构是一套构建系统的规则；从表象上看，软件架构是一套模板，以文档、代码、工具程序等方式表现。（其他更多的软件架构的概念描述，请查看8月24日发的邮件――《软件架构基础知识.doc》） 软件架构的成果是一套模板，这套模板会通过一种方式去组织，这个组织形式也很重要，应该从不同视角去表现，以适合不同人去理解和应用。 1.3. 系统架构设计师干什么 根据系统架构的定义，系统架构师的职责当然是制定软件系统构建规则，不过一般认为，系统架构师的主要职责有： 1） 负责领导和协调整个项目中的技术活动 2） 在个人综合素养方面，系统构架师应该具有领导才能，能够在压力下作出关键性的决策并善始善终； 3） 能够赢得项目经理、客户、用户群体以及管理团队的认同和尊敬，尤其要善于和项目经理紧密协作； 4） 在各个方面都能展现出面向目标的实干作风。在专业技能方面，与其他角色相比，系统构架师通常具有全方位的技能，其见解重在广度，而不是深度。 5） 系统构架师不仅需要具备设计师的各项技能，而且应该具有问题领域和软件工程领域的实践经验，从而有能力在无法获得完整信息的情况下迅速领会问题并根据经验作出审慎的判断。 6） 如果项目较大，系统构架师将是一个团队，上述的关键素质要求可由团队成员来分担，但其中要有一名系统构架师具有足够的权威。 架构师与设计师的职责有所不同，最重要的是架构师工作的关注点是软件系统的全局问题，他是制定软件系统的规则和原则的，对整个软件系统进行规划；设计师相对来说是关注软件系统的局部和具体问题，把架构师的架构设计进行细化。 架构师是由国外引进的一个概念，国外软件开发的几个职位是技术官、架构师、设计师、开发、测试，对应我们公司应该是技术总监、架构师、系统分析员、程序员、测试人员。 1.4. 常用架构设计模式 很多OO设计原则和设计模式同样适用与架构设计，架构中使用这些原则的主要目的是为了使架构具有更好的可维护性和可复用性，并使架构具有稳定性，这些目的也是一个架构的核心价值所在。 模式的定义也不统一，一般是这样的解释，每个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的核心。（在古代流传至今的“三十六计”就是三十六个模式，对中国人来说，这可能是让人最容易理解模式概念的一个类比。）使用模式能够减少设计的难度，更能加快设计人员之间交流和沟通。 以下是几个常用的顶层架构设计的模式 1) 分层模式 2) MVC模式 3) 客户/服务器模式 4) 流程处理模式 这些模式的介绍在8月24日发的邮件――《软件架构基础知识.doc》中都有清晰的解释，这里不在赘述。 1.5. AOP AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向方面编程。AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。AOP是近两年比较热门的技术，给我们带来了一个新的视角和软件架构方法。 通过使用AOP技术，可以把分散在多个模块中共同的行为分离出来统一编程，减少重复代码。 AOP和OO、SOA一样，都是架构设计中的重要视角。 1) 基本原理 AOP机制一般都需要开发语言和编译器支持，Java和.C#都支持。实现AOP有不同的方法，常见的方法是利用代理机制，其基本原理是为“其他对象提供一种代理，以控制对这个对象的访问”。 2) 常见使用AOP技术的地方 n Authentication 权限验证 n Caching 缓存 n Context passing 内容传递 n Error handling 错误处理 n Lazy loading　懒加载 n Debugging　　调试 n logging, tracing, profiling and monitoring　记录跟踪　优化　校准 n Performance optimization　性能优化 n Persistence　　持久化 n Resource pooling　资源池 n Synchronization　同步 n 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架构有哪些基本的要求： n SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用； n 服务间保持松散耦合，基于开放的标准， 服务的接口描述与具体实现无关； n 灵活的架构 －－服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明； 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的方式，应为 n 被集成的对象被明确定义为服务，而不是传统EAI中各种各样的中间件平台 n ESB明确强调消息(Message)处理在集成过程中的作用 n 事件驱动成为ESB的重要特征 2) ESB适用场景 ESB应该构筑在完善的SOA架构上，它应该做的事是服务集成。它的常见应用模式是 n 协议转换模型，用于当服务的请求者与服务提供者基于不同协议时的消息转换情形 n 消息广播模式，用于事件驱动多个动作或者消息广播的情形 n 服务匹配模式，用于需要动态选择服务提供者的情形，例如可以根据消息的内容，或负载情况，或服务级别约定(SLA)，来为服务请求者选择合适的服务 参考资料：http://www-128.ibm.com/developerworks/cn/webservices/ws-esb1/ 1.8. 区分出非功能性需求 举例： 1) 什么是非功能性需求 非功能性需求是这样一种需求，它解决“如何使这个系统能在实际环境中运行”。 2) 重要吗？ 在设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，那么这个解决方案则很难取得实效，因为用户可能难以甚至无法使用系统的功能。 很多非功能需求一般会在底层的基础技术平台去仔细设计和实现。 3) 非功能性需求要考虑那些方面 非功能性的特性一般有这些： n 可靠性 只显示系统可以做某些事情是不够的。如果一个系统不能可靠地运行（例如，在加载时，或者在系统故障时，等等），则它就不能满足客户的需要。 有一些问题应该自问一下： * 即使硬件出现故障，系统也可以可靠运行吗？ * 复制和故障转移方案是什么？ * 需要手动干预，还是系统可以自动进行故障转移？ * 实现可靠性会对性能造成负面影响吗？ * 实现可靠性的成本有多高？ 可靠性需要考虑的一些具体方面是： 安全性：假设攻击者就在外面。如何知道系统用户就是他们所声称的，并只让他们访问经过授权的功能？如何保护我的系统不受攻击？考虑到网络攻击、机器攻击，甚至从您自己的系统内部发起的攻击。 事务性：如何设计系统来保存工作单元的 ACID 属性？如果在设计中涉及多个独立的子系统（Web 服务和 SOA 就是这种情况），则这一点就显得特别重要。不要假设始终可以进行两阶段提交 (two phase commit)。 n 可用性 如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是： * 您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？ * 系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？ * 是否界面本来就有状态而功能无状态（反之亦然）？ n 有效性 如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑： 性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗？ 可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）？ n 可维护性 这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承 担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的 部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？ n 可移植性 虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 (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两个实现版本。不过，为了避免重复开发又兼顾技术体系的特殊性，这三个层次中的基础架构层应该用两种技术分别实现出一套框架程序并提供企业服务接口，其他两层的功能可以使用任意的技术实现，并且每种功能尽量只实现一次，通过集成技术把不同技术体系的功能组合成业务系统。企业服务总线主要解决的问题是提供异构系统的功能集成。 －－－刘爱军 2006年9月。9:48:34 | 添加评论 | 固定链接 | 引用通告 (0) | 写入日志 | 软件设计&架构软件开发公司技术管理办法的一个设想 （转贴请注明出自xsfox.spaces.live.com） 1. 目的为了规范公司软件技术的研发、使用及升级维护流程，加强公司对公共软件技术的管理，对公司公用软件技术生命周期进行有效的控制，提高公司软件产品的开发效率和质量。 2. 范围1． 公司级公共软件技术的研发和升级维护过程。 2． 公司级公共软件技术应用过程。 3． 公共软件技术包括：Delphi、.Net、Java、嵌入式开发4条技术线的软件应用框架、外购控件包、公共基类、通用技术解决方案、通用工具软件。 3. 职责技术委员会： 1） 发布公共软件技术的某个版本。 2） 甄选和招募技术委员会成员。 3） 收集技术提议，做出技术规划。 4） 组织软件技术人员进行公司公共软件技术的研发。 公共软件技术研发项目组： 1） 负责公共软件技术的技术论证、开发。 2） 对应用人员进行培训。 3） 跟踪技术的发展，解决技术应用中的问题。 应用系统软件项目组： 负责实施和应用公共软件技术，对应用情况进行反馈。 4. 控制流程1． 技术规划 1） 技术委员会平时负责收集整理公司范围内的软件技术的自主研发、技术升级扩展或技术外购的提议。 2） 每年定期（经理会期间），技术委员会组织人员对收集整理的提议进行评估筛选，确定下阶段软件技术研发的重点，并制定研发任务。 3） 对于急需技术的提议，技术委员会随时组织人员进行评估筛选，安排研发任务。 2． 技术论证 1） 确立研发任务后，技术委员会甄选合适人员作为某项技术的技术研究员，对确定的研发任务进行技术论证和试验。 2） 技术研究员收集和验证某项技术的技术资料，撰写技术可行性研究报告，明确技术自主研发或采购要求，人力和时间投入估算，预期收益等内容。 3） 技术委员会组织人员对技术可行性研究报告进行评审，确定技术研发的策略，策略包括取消、继续论证、暂时挂起、进行开发。 4） 对继续论证的技术重复1）-3），直到次技术的研发策略变化。 5） 如果是由于目前公司资源不足或是目前形势尚不足以做出判断，可以让技术研发进入暂时挂起状态，等待重新提议和评审。 3． 技术开发 1） 对于技术可研报告评审评定为进行开发的技术，技术委员会组织人员进行下一步开发工作。 2） 技术委员会甄选人员组成公共软件技术研发项目组，确定研发项目任务目标和工期要求，确定项目组负责人。技术研发项目组可以并入应用系统项目组进行管理。 3） 研发项目的负责人指定详细的开发计划，并按计划进行开发工作，开发工作包括设计、编码、测试和撰写开发文档。 4） 开发完成后，项目负责人组织相关人员对开发成果进行评审，一般情况下，技术总监、技术委员会主席以及技术应用的相关人员要参与评审。 5） 评审不通过时，需要根据评审意见进行修改，然后重新评审。 4． 技术应用 1） 评审通过后，研发项目组负责撰写培训材料，对应用此项技术的开发人员进行技术应用培训。 2） 如果需要，研发项目组成员进入应用系统项目组进行有关开发工作。 3） 项目组指定一个此项技术的负责人，项目组解散。 5． 技术维护 1） 技术负责人跟踪此项技术发展，收集此技术的应用反馈意见，处理Bug。 2） 技术应用的项目组把技术的改进要求和建议统一提交到技术负责人，技术负责人根据收集的反馈和对此项技术的跟踪情况，不定期向技术委员会提交技术升级提议。 3） 技术委员会进行合并提议进行下一轮技术规划。