架和类库等概念的出现都是源于人们对复用的渴望。“不要重复发明轮子”，成了软件界的一句经典名言。从最初的单个函数源代码的复用，到面向对象中类的复用（通常以类库的形式体现），再到基于组件编程中二进制组件（.NET中是以IL程序集形式存在的）的复用，人们复用软件的抽象层次越来越高。现在，框架复用是抽象层次的又一提升，框架的复用不仅仅是功能的复用，更是设计的复用。
1．1&框架与类库的区别
&&&我们先来简单说说什么是类库（Class Library）？望文生义，类库就是一些类的集合，只要我们将一些可以复用的类集中放到一个Library中，我们就可以称其为一个类库。类库中的许多元素（如类、结构、接口、枚举、委托等）之间可能有一些关联，但这些关联通常用于支持一个类概念或接口概念的完整表达。如果我们从一个更高的视角来审视类库，可以发现类库中的一个个“完整的概念”之间是无关的或是关系松散的。
&&&再来说框架，框架的第一含义是一个骨架，它封装了某领域内处理流程的控制逻辑，所以我们经常说框架是一个半成品的应用。由于领域的种类是如此众多，所以框架必须具有针对性，比如，专门用于解决底层通信的框架，或专门用于医疗领域的框架。框架中也包含了很多元素，但是这些元素之间关系的紧密程度要远远大于类库中元素之间的关系。框架中的所有元素都为了实现一个共同的目标而相互协作。
&&&没有一个万能的框架可以应用于所有种类的领域和应用，框架的目标性非常强，它专注于解决某一特定领域的问题，并致力于为这一特定领域提供通用的解决方案。
&&&框架与类库的区别主要表现在以下几个方面：
（1）从结构上说，框架内部是高内聚的，而类库内部则是相对松散的。
（2）框架封装了处理流程的控制逻辑，而类库几乎不涉及任何处理流程和控制逻辑。
&&&正是由于框架对处理流程的控制逻辑进行了封装，才使得框架成为一个应用的骨架。框架中的处理流程和控制逻辑需要经过精心的设计，因为所有使用了该框架的应用程序都会复用该设计。
（3）框架具有IOC（控制反转）能力，而类库没有。&&&
&&&IOC，即俗称的好莱坞模式（Don’t call us, we will call you）。对于类库中的元素来说，通常都是由我们的应用来调用它；而框架具有这种能力――在适当的时候调用我们应用中的逻辑。这种能力是通过框架扩展点（或称为“插槽”）来做到的――具体的应用通过扩展点注入自己的逻辑，而在适当的时候，框架会调用这个扩展点中已注册的逻辑。实际上，.NET中的事件（event）发布、预定机制就是IOC的一个代表性例子。
（4）框架专注于特定领域，而类库却是更通用的。
&&&框架着力于一个特定领域的解决方案的完整表达，而类库几乎不针对任何特定领域。比如，本书中提到的通信框架只适用于需要在TCP/UDP基础上直接构建通信的应用程序，而像正则表达式这样的类库却可以使用在各种不同的应用中。
（5）框架通常建立在众多类库的基础之上，而类库一般不会依赖于某框架。
1．2&通用框架与应用框架
&&&&&&如果要对框架进行进一步分类，则可以根据框架针对的领域是否具有通用性而将它们分为通用框架（General Framework）和应用框架（Application Framework）。通用框架可以在不同类型的应用中使用，而应用框架只被使用于某一特定类型的应用中。
&&&&&&比如，ORM框架NHibernate就是一个通用框架，该框架可以用于所有需要解决O/R映射的各种类型的应用中。而某个金融框架则是一个应用框架，它仅仅被用于金融类型的应用中。
&&&&&&可以这么说，通用框架所解决的是所有类型的应用都关心的“普遍”问题，而应用框架解决的是某一特定类型的应用关心的问题。所以，如果我们需要将某种类型的应用的核心业务逻辑流程提升到一个框架中，所得到的这个框架就是一个应用框架。与通用框架相比，应用框架需要了解更多目标业务领域内的领域知识。
&&&&&&在实现具体的应用程序时，可以采用一个应用框架与多个通用框架相结合的方式，这样有利于快速、高质量的应用程序开发。比如，某个金融领域的一个应用，可以采用金融框架作为应用框架来解决与金融业务逻辑相关的问题，采用Nhibernate解决数据访问，采用ESFramework解决应用中各分布式系统之间的通信。&
&&&&&&下图描述了类库、框架和应用之间的层次关系。
&&&当然，一个应用也可以完全不采用任何框架，而是直接从最基础的底层API（如.NET Framework）开始构建。对于微型的系统，这种方式或许可行。但对于复杂大型的应用，困难度就可想而知了。
1．3&框架之于应用
&&&当一个应用系统选定了框架之后，我们需要做的就是在框架提供扩展点的地方添加应用的具体逻辑，也就是使用“血”和“肉”来填充这个骨架从而得到一个“有机体”。
&&&由于框架通常都是在实践中经过反复使用和检验的，所以质量有一定的保证，这使得我们用更少的时间、更少的编码来实现一个更稳定的系统成为可能。当然，框架也不是“银弹”，它不能解决软件复杂性的根本问题，但是我们却通过它向这个终极的理想目标又迈进了一步。
&&&有一点需要注意，框架使得我们的系统在有所支撑的同时，它也给出了限制。因为通常当我们确定采用了某一个框架之后，我们就必须在这个框架限制的“框框”之内来构建我们的应用。大多数时候，这不是一个问题，但是如果因为框架的限制而严重影响了我们系统目标的实现的时候，我们就需要考虑是否应该放弃这个框架，或者换一个其它的同类型的框架。
1．4&框架设计
&&&框架使得我们开发应用的速度更快、质量更高、成本更低，这些好处是不言而喻的。然而，面对万千变化日趋复杂的软件需求，设计和实现一个高度灵活可复用的框架又谈何容易！
&&&框架源于应用，却又高于应用。
&&&框架往往是这样产生的：我们拥有了开发某种类型应用的大量经验，我们总结这种类型的应用中共性的东西，将其提炼到一个高的层次中，以备复用。这个“高层次”的东西便是框架的原型。随着我们经验的不断积累，框架也会不断地完善、发展。
&&&框架是一个实践的产物，而不是在实验室中理论研究出来的。所以设计一个框架最好的方法就是从一个具体的应用开始，以提供同一类型应用的通用解决方案为目标，不断地从具体应用中提炼、萃取框架！然后在应用中使用这个框架，并在使用的过程中不断地修正和完善。
&&&有一点需要特别注意，正如所有的软件架构设计的要点在于权衡（在这方面有点像艺术），框架的设计也不例外，正如前面提到，框架在为应用提供了一个骨架的同时，也给我们的应用圈定了一个框框，我们只能在这个有限的天地内来发挥。所以，一个好的框架设计应当采用了一个非常恰当的权衡决策，以使框架在为我们应用提供强大支持的同时，而又对我们的应用作更少的限制。权衡，从来就不是一件简单的事情，但是有很多框架设计的经验可以供我们参考。
1.4.1&框架设计经验、原则
（1）框架不要为应用做过多的假设！&&&&&
&&&关于框架为应用做过多的假设，一个非常具体的现象就是，框架越俎代庖，把本来是应用要做的事情揽过来自己做。这是一种典型的吃力不讨好的做法。框架越俎代庖，也许会使得某一个具体应用的开发变得简单，却会给其它更多想使用该框架的应用增加了本没有必要的束缚和负担。
（2）使用接口，保证框架提供的所有重要实现都是可以被替换的。
框架终究不是应用，所以框架无法考虑所有应用的具体情况，保证所有重要的组件的实现都是可以被替换的，这一点非常重要，它使得应用可以根据当前的实际情况来替换掉框架提供的部分组件的默认实现。使用接口来定义框架中各个组件及组件间的联系，将提高框架的可复用性。
（3）框架应当简洁、一致、且目标集中。
框架应当简洁，不要包含那些对框架目标来说无关紧要的东西，保证框架中的每个组件的存在都是为了支持框架目标的实现。包含过多无谓的元素（类、接口、枚举等），会使框架变得难以理解，尝试将这些对于框架核心目标不太重要的元素转移到类库中，可以使得框架更清晰、目标更集中。
（4）提供一个常用的骨架，但是不要固定骨架的结构，使骨架也是可以组装的。
比如说，如果是针对某种业务处理的框架，那么框架不应该只提供一套不可变更的业务处理流程，而是应该将处理流程“单步”化，使得各个步骤是可以重新组装的，如此一来，应用便可以根据实际情况来改变框架默认的处理流程。这种框架的可定制化能力可以极大地提高框架的可复用性。
（5）不断地重构框架。
&&&如果说设计和实现一个高质量的框架有什么秘诀？答案只有一个，重构、不断地重构。重构框架的实现代码、甚至重构框架的设计。重构的驱动力源于几个方面，比如对要解决的本质问题有了更清晰准备的认识，在使用框架的时候发现某些组件职责不明确、难以使用，框架的层次结构不够清晰等。
1.4.2&如何称得上一个优秀的框架？
&&&&&&一个优秀框架的最主要的特点是：简单。这种简单性不是轻而易举就可以获得的，正如优秀的框架不是一蹴而就的，达到这种简单性需要对框架不断地抽丝、不断地提炼和完善。简单的真正原因在于它抓住了要解决的问题的本质。一个优秀的框架通常都具有如下特点：
（1）清晰的、简洁的、一致的。&&&&
&&&&&&“清晰”指的是框架的结构是清晰的、框架的层次是清晰明朗的、框架中各个类和组件的职责是清晰明确的。
“简洁”指的是框架中没有无关紧要多余的元素，而且各个类和组件的职责目标是非常集中的，这正是“高内聚、低耦合”设计原则的体现。
“一致”通常会带来这样的好处，框架的使用者在熟悉了框架的一部分后，会非常容易地理解框架的另一部分。“一致”通常体现在命名的规则一致、命名的含义一致、组件的装配方式和使用方式一致等。
（2）易于使用的
&&&&&&只有易于使用的框架才会走得更远。
&&&正是因为易于使用，框架使用者们才有可能试用这个框架，在试用满意后才有可能决定采用这个框架。一个框架功能即使再强大，如果难以使用，那么框架使用者们很可能根本就不会有试用这个框架的念头。
框架的生命力源于框架一直在不断地完善和发展，如果没有人使用这个框架，这个框架便没有了发展和完善的源动力。正如友好的用户界面是优秀应用程序不可或缺的重要部分，易于使用也是优秀框架的一个重要特性。
（3）高度可扩展的、灵活的
&&&&&&框架通过高度可扩展性来应对应用程序的万千变化。
&&&&&&没有任何一个框架可以预料所有应用的需求，万能的框架是不存在的。企图设计、实现一个万能框架的想法是荒诞的。框架必须具有“以不变应万变”的能力，框架可以通过为应用预留恰当的、足够的扩展点来做到这一点。
&&&&&&框架的灵活体现在框架可以根据不同的应用进行不同的组装和配置，就像框架是专门为当前的应用所订制的一样。
（4）轻量的
&&&&&&“轻量”，说的通俗点，就是只为自己需要使用的服务付费，而不需要为自己不需要的服务买单。一个重量级的框架有一个很明显的特征就是，如果你需要一套完整的套餐服务，那是没有问题的，框架可以很好的满足你；但是，如果你只需要这份套餐中的一小块点心，对不起，框架仍然会强加一个完整的套餐给你，你必须付一整份套餐的费用。
&&&优秀的框架应当支持使用者“按需所取”的原则，框架使用者可以随意“点菜”进行组装来满足自己的需求。
（5）弱侵入性的
&&&&&&所谓“弱侵入性”，采用了框架的应用程序可以尽可能的以普通的方式来编写应用逻辑，而不必为了适应框架不得不使用一些特殊的手法。
&&&这可能有点难以理解，我们可以举个例子来简单说明。在.NET中，实现AOP（面向方面编程）机制的两种主要方式是使用Proxy和动态代理。使用Proxy实现的AOP框架通常要求那些需要使用AOP截获功能的类必须继承自ContexBoundObject；而采用动态代理实现的AOP框架则没有任何如此侵入性的要求，我们仍可以以最普通的方式来编写应用逻辑类，这类框架会在运行时根据配置动态地生成目标对象的代理对象来实现AOP截获。所以我们可以说，采用动态代理方式实现的AOP框架相比采用Proxy实现的AOP框架，具有更弱的侵入性。
&&&弱侵入性意味着框架对应用逻辑的干扰更少，由于应用逻辑类都是普通的类，这非常方便应用逻辑在另外一个程序中复用，而另外的程序可能采用了一个完全不同的框架。
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1341次
排名：千里之外您的位置： >>
　　新浪微博在2014年3月公布的月活跃用户（MAU）已经达到1.43亿，2014年新年第一分钟发送的微博达808298条，如此巨大的用户规模和业务量，需要高可用（HA）、高并发访问、低延时的强大后台系统支撑。
　　微博平台第一代架构为LAMP架构，数据库使用的是MyIsam，后台用的是php，缓存为Memcache。
　　随着应用规模的增长，衍生出的第二代架构对业务功能进行了模块化、服务化和组件化，后台系统从php替换为Java，逐渐形成SOA架构，在很长一段时间支撑了微博平台的业务发展。
　　在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。
　　我们先看一张微博的核心业务图（如下），是不是非常复杂？但这已经是一个简化的不能再简化的业务图了，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠地发布新产品新功能。
　　第三代技术体系
　　微博平台的第三代技术体系，使用正交分解法建立模型：在水平方向，采用典型的三级分层模型，即接口层、服务层与资源层；在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台。下面是平台的整体架构图：
　　如上图所示，正交分解法将整个图分解为3*4=12个区域，每个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构。
　　下面详细介绍水平方向与垂直方向的设计原则，尤其会重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。
　　水平分层
　　水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现。这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：
接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务及通讯服务（单发私信、群发、群聊）。
服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，其定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类。图中使用泳道隔离，表示它们的独立性。另外一类为组合服务，通过各种原子服务和业务逻辑的组合来完成服务，比如Feed服务、通讯服务，它们除了本身的业务逻辑，还依赖短链、用户及发号器服务。
资源层主要是数据模型的存储，包含通用的缓存资源Redis和Memcached，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。
　　水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。
　　与分层模型相对应，微博系统中的服务器主要包括三种类型：前端机（提供 API 接口服务）、队列机（处理上行业务逻辑，主要是数据写入）和存储（mc、mysql、mcq、redis 、HBase等）。
　　垂直延伸技术架构
　　随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。
　　区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。
　　接口层Web V4框架
　　接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面（AOP）设计理念。接口框架基于Jersey 进行二次开发，基于annotation定义接口(url, 参数)，内置Auth、频次控制、访问日志、降级功能，支撑接口层监控平台与服务治理，同时还有自动化的Bean-json/xml序列化。
　　服务层框架
　　服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。
　　MCQ消息队列
　　消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。
　　微博平台内部大量使用的MCQ(SimpleQueue Service Over Memcache)消息队列服务，基于MemCache协议，消息数据持久化写入BerkeleyDB，只有get/set两个命令，同时也非常容易做监控（stats queue），有丰富的client library，线上运行多年，性能比通用的MQ高很多倍。
　　Motan RPC框架
　　微博的Motan RPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了High Availability与Load Balance策略（支持灵活的FailOver和FailFast HA策略，以及Round Robin、LRU、Consistent Hash等Load Balance策略），服务治理方面，生成完整的服务调用链数据，服务请求性能数据，响应时间（Response Time）、QPS以及标准化Error、Exception日志信息。
　　资源层框架
　　资源层的框架非常多，有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy，在这些方面业界有较多的经验分享，我在这里分享一下平台架构的对象库与SSD Cache组件。
　　对象库
　　对象库支持便捷的序列化与反序列化微博中的对象数据：序列化时，将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID，当需要访问该对象时，通过ObjectID读取，对象库支持任意类型的对象，支持PB、JSON、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，一共定义了几十种对象类型，并抽象出标准的对象元数据Schema，对象的内容上传到对象存储系统（Sina S3）中，对象元数据中保存Sina S3的下载地址。
　　SSDCache
　　随着SSD硬盘的普及，优越的IO性能使其被越来越多地用于替换传统的SATA和SAS磁盘，常见的应用场景有三种：1）替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升；2）替换Redis的硬盘，提升其性能；3）用在CDN中，加快静态资源加载速度。
　　微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为 Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。
　　垂直的监控与服务治理
　　随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确地描述服务之间的依赖关系，服务的管理运维变得越来难，在这个背景下，参考google的dapper和twitter的zipkin，平台实现了自己的大型分布式追踪系统WatchMan。
　　WatchMan大型分布式追踪系统
　　如其他大中型互联网应用一样，微博平台由众多的分布式组件构成，用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统组件，并留下足迹（footprint）。但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这样一种典型的跨进程/跨线程的场景，汇总收集并分析这类日志就显得尤为重要。另一方面，收集每一处足迹的性能数据，并根据策略对各子系统做流控或降级，也是确保微博平台高可用的重要因素。要能做到追踪每个请求的完整调用链路；收集调用链路上每个服务的性能数据；能追踪系统中所有的Error和Exception；通过计算性能数据和比对性能指标（SLA）再回馈到控制流程（control flow）中，基于这些目标就诞生了微博的Watchman系统。
　　该系统设计的一个核心原则就是低侵入性（non-invasivenss）：作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，可以大大减少开发人员的负担和接入门槛。基于此考虑，所有的日志采集点都分布在技术框架中间件中，包括接口框架、RPC框架以及其他资源中间件。
　　WatchMan由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容、服务降级、流量切换、服务发布与灰度。
　　现在，技术框架在平台发挥着越来越重要的作用，驱动着平台的技术升级、业务开发、系统运维服务，本文限于篇幅限制，没有展开介绍，后续会不断地介绍核心中间件的设计原则和系统架构。
软件设计热门文章
软件设计最新文章架构师之路（316）
解决方案（285）
区分什么是架构、框架、模式和平台，一直都感觉这几个词过于抽象和模糊，今天大家来说说到底什么是架构、框架、模式和平台？
收集了的一些来自网上各自的定义和区分如下：
来自&&概念：&
设计模式&框架&架构&平台，从复用角度讲，设计模式是代码级复用、框架是模块级复用、架构是系统级复用、平台是企业应用级复用。
1、设计模式
为什么要先说设计模式？因为设计模式在这些概念中是最基本的，而且也比较简单。那么什么是设计模式呢？说的直白点，设计模式就是告诉你针对特定问题如何组织类、对象和接口之间的关系，是前人总结的经验。比如我要在代码中实现一个全局唯一的配置类，那么就使用Singleton模式。设计模式在实际编码工作和设计框架时会被使用到，而更高层的架构和平台则不会太关注它。
做WEB开发接触到最多的框架可数ORM框架，ORM框架只是所有数据关系映射框架的统称，具体的如NHibernate、ActiveRecord等，框架是为了解决特定问题而存在的，其它诸如模板框架、缓存框架，框架不能直接使用，需要二次开发。
从大的层面来说，比如针对公司业务的B2C网站系统架构，里面可能会用到多种解决各方面问题的框架，关注的是技术整合、扩展、可维护性。换个角度，在框架中也会涉及到架构问题，比如开发NHibernate框架，也需要考虑如何进行设计。
平台的概念类似框架，但又结合的架构的考虑，它是更高层面上的“框架”，准确说是一种应用。它是针对企业用户，为解决企业业务需要而形成的产品。
网的定义：
什么是架构?
&& 软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解，以下是一些主流的标准观点。
　　ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。
　　Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。Garlan & Shaw模型[1]的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。
　　关于架构的定义还有很多其他观点，比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。
&&& 什么是模式?
&& 模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。
&&&&&&& 架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。模式的目标是，把共通问题中的不变部分和变化部分分离出来。不变的部分，就构成了模式，因此，模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导。根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式(Architectural
Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern).架构模式是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如，用户和文件系统安全策略模型，N-层结构，组件对象服务等，我们熟知的MVC结构也属于架构模式的层次。一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题。例如，[GOF95][2]总结的23个基本设计模式——Factory
Pattern, Observer Pattern等等。实现模式是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名，变量名，函数名的命名规则；异常处理的规则等等。
&& 由于[GOF95]是论述软件模式的著作的第一本，也是OO设计理论著作中最流行的一本，因此有些人常常使用设计模式（Design Pattern）一词来指所有直接处理软件的架构、设计、程序实现的任何种类的模式。另外一些人则强调要划分三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、成例(Idiom)。成例有时称为代码模式(Coding Pattern)。
　　这三者之间的区别在于三种不同的模式存在于它们各自的抽象层次和具体层次上。架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。
　　1、代码模式或成例(Coding Pattern 或 Idiom)
　　代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
　　较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等。
　　2、设计模式(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）模式等。
　　3、架构模式(Architectural Pattern)
　　一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。有些作者把这种架构模式叫做系统模式[STELTING02]。
　　一个架构模式常常可以分解成很多个设计模式的联合使用。显然，MVC模式就是属于这一种模式。MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。
　　此外，常见的架构模式还有：
　　·Layers（分层）模式，有时也称Tiers模式
　　·Blackboard（黑板）模式
　　·Broker（中介）模式
　　·Distributed Process（分散过程）模式
　　·Microkernel（微核）模式
　　架构模式常常划分成如下的几种：
　　一）、 From Mud to Structure型。帮助架构师将系统合理划分，避免形成一个对象的海洋（A sea of objects）。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。
　　二）、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。
　　三）、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。
　　四）、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。&
软件框架是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，不同领域的软件项目有着不同的框架类型。框架的作用在于：由于提取了特定领域软件的共性部分，因此在此领域内新项目的开发过程中代码不需要从头编写，只需要在框架的基础上进行一些开发和调整便可满足要求；对于开发过程而言，这样做会提高软件的质量，降低成本，缩短开发时间，使开发越做越轻松，效益越做越好，形成一种良性循环。
　　框架不是现成可用的应用系统。是一个半成品，需要后来的开发人员进行二次开发，实现具体功能的应用系统。框架不是“平台”，平台概念比较模糊可以是一种操作系统，一种应用服务器，一种数据库软件，一种通讯中间件等地那个，因此平台在应用平台主要指提供特定服务的系统软件，而框架更侧重了设计，开发过程，或者可以说，框架通过调用平台提供的服务而起的作用。
　　框架不是工具包或者类库，调用API并不就是在使用框架开发，紧紧使用API是，开发者完成系统的主题部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，二次开发人员只是像做填空一样，根据具体业务，完成特定应用系统中与众不同的特殊部分。
　　框架与架构之间的关系
　　框架不是构架（即软件体系机构）。体系结构确定了系统整体结构、层次划分，不同部分之间的协作等设计考虑。框架比架构更具体。更偏重于技术涉嫌。确定框架后，软件体系结构也随之确定，而对于同一软件体系结构（比如Web开发中的MVC），可以通过多种框架来实现。
　　框架与设计模式之间的关系
　　设计模式和框架在软件设计中是两个不同的研究领域。设计模式研究的是一个设计问题的解决方法，一个模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体虽然它们有所不同，但却共同致力于使人们的设计可以被重用，在思想上存在着统一性的特点，因而设计模式的思想可以在框架设计中进行应用。
　　框架和设计模式存在着显著的区别，主要表现在二者提供的内容和致力应用的领域。
　　1)、从应用领域上分，框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，并且这个方案可在不同的应用程序或者框架中进行应用。
　　2)、从内容上分，设计模式仅是一个单纯的设计，这个设计可被不同语言以不用方式来实现；而框架则是设计和代码的一个混合体，编程者可以用各种方式对框架进行扩展，进而形成完整的不同的应用。
　　3)、以第二条为基础，可以得出设计模式比框架更容易移植：框架一旦设计成形，虽然还没有构成完整的一个应用，但是以其为基础进行应用的开发显然要受制于框架的实现环境；而设计模式是与语言无关的，所以可以在更广泛的异构环境中进行应用。
　　总之，框架是软件，而设计模式是软件的知识体。
1．什么是模式？
模式，即pattern。其实就是解决某一类问题的方法论。你把解决某类问题的方法总结归纳到理论高度，那就是模式。
Alexander给出的经典定义是：每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心。通过这种方式，你可以无数次地使用那些已有的解决方案，无需在重复相同的工作。
模式有不同的领域，建筑领域有建筑模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现很多模式。
什么是框架？
框架，即framework。其实就是某种应用的半成品，就是一组组件，供你选用完成你自己的系统。简单说就是使用别人搭好的舞台，你来做表演。而且，框架一般是成熟的，不断升级的软件。
2．为什么要用模式？
因为模式是一种指导，在一个良好的指导下，有助于你完成任务，有助于你作出一个优良的设计方案，达到事半功倍的效果。而且会得到解决问题的最佳办法。
为什么要用框架？
因为软件系统发展到今天已经很复杂了，特别是服务器端软件，设计到的知识，内容，问题太多。在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，你只需要集中精力完成系统的业务逻辑设计。而且框架一般是成熟，稳健的，他可以处理系统很多细节问题，比如，事物处理，安全性，数据流控制等问题。还有框架一般都经过很多人使用，所以结构很好，所以扩展性也很好，而且它是不断升级的，你可以直接享受别人升级代码带来的好处。
框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。
到底有没有一个具体的定义了？你们又是如何理解和区分的？
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1263263次
积分：9182
积分：9182
排名：第1779名
原创：296篇
转载：308篇
评论：61条
阅读：3502
文章：13篇
阅读：12781
文章：14篇
阅读：10521
(2)(6)(1)(2)(3)(3)(2)(1)(1)(8)(3)(12)(22)(15)(14)(3)(1)(9)(3)(6)(2)(1)(1)(3)(7)(28)(19)(42)(32)(16)(20)(148)(169)