(2007.12.14日补充更新了部分内容，其中有关Web网站性能特点部分内容来自网络)
一、什么是架构
1. 和架构相关的几个问题域
架构需要解决的非业务问题域包括如下：
A 系统目标：系统性能，稳定性.
B.项目目标：开发成本，质量
C.项目过程：需求的不确定性和开发过程的团队协作性
不同的问题域，解决之道也不相同！而同一问题域的不同层次的要求，解决之道也不尽相同。
2. 什么是架构
架构到底是啥，愚以为下面的这段英文描述的很清楚。
That's like asking, what is culture? Culture is the way you do things in a group of people. Architecture is the way you do things in a software product. You could argue by analogy, then, that architecture is to a software product as culture is to a team. It is how that team has established and chosen its conventions，
Which leads us inevitably to the question of “goodness”? How do you know if an architecture is good? Consider an architecture that isn't built using a strong domain model, and instead relies heavily on stored procedures. That might be OK, or it might not be OK. You could have decided that part of your architecture is to use a really strong domain model and not use stored procedures, right? So an architecture is some reasonable regularity about the structure of the system, the way the team goes about building its software, and how the software responds and adapts to its own environment. How well the architecture responds and adapts, and how well it goes through that construction process, is a measure of whether that architecture is any good.
The system architecture determines how hard or easy it is to implement a given feature. Good architectures are those in which it is considered easy to create the features desired. In that the way to judge whether an architecture is good is whether the architecture is good for the purposes to which it is applied.
The definition of goodness has to be related to fitness for purpose. Is this glove good? I don't know. What are you doing with the glove? Are you throwing snowballs, cooking barbeques, or playing golf? There's a set of changes that are going to occur to a software system over time. Probably the utilitarian or most useful definition of goodness is the answer to this question: are the changes that will keep this system successful in this domain in this product line relatively easy? If they are, then it's probably a good architecture.
3. 架构的背后
为了实现架构的目标涉及到以下三个方面：技术，组织和过程。这里举例说明。
1) 技术对开发效率和运行性能，以及组织和过程的影响。
案例A．映射的问题。公司产品的一个重要需求是根据客户输入，映射到PDF文件上。技术上整体实现需要四个步骤：在PDF文件上画好所有的数据域，通过读入一个XML映射文件，获得运行数据并生成FDF，合并FDF和PDF生成目标文件。后两步工作都由代码自动化了，因而实现的主要工作在于前两步。
在第一个实现版本里，XML映射文件的DTD太简单，致使一个xml文件至少在4000行左右，同时xml文件太verbose了。这样的结果直接导致运行系统在峰值时，由于XML消耗了大量内存，1G的内存根本吃不消；同时对XML解析执行使用了CPU的大量时间；导致开发人员需要做大量的工作，开发效率降低了，通常需要尽一周才能完成一个xml文件，员工都不愿意做；也导致开发过程的漫长， 开发部门对于BA部门和ST部门的要求反应变的缓慢。
在第二个版本的实现中，重新实现了DTD，加入了大量的关键字同时也消除了verbose，大量的缩小了XML大小，从4000多行减低到900多行。不仅减低了内存使用，提高执行效率；也提高了开发效率，基本只要一天就可以完成一个映射文件。同时对BA部门和ST部门的反应也快了。
案例B：脚本的问题。产品在web层提供了脚本支持，出于方便开发的目的。但是没有对脚本的环境限制，脚本可以做系统程序的大部分工作。导致开发人员偷懒，在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。
2) 组织结构对技术，开发效率和应变能力的影响。
案例A.部门的分工问题。开发部门根据不同的职责，分成A，B和C等数个小组。大部分开发中互不相干。但也有时候，需要跨组的支持，比如B要实现某个需求，需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作，导致跨组沟通的困难。同时由于整个开发部采取任务绩效，有时间压力，加上只是一个小的要求。于是在A人员的同意下，B人员直接在A代码中写入业务逻辑。每次都是这样的小改动，不断的发展后，代码开发变凌乱。
案例B.开发的历史问题，当某个开发人员写下的代码，有是问题的，接手开发人员由于文档不全以及没有测试用例，不愿意承担变化的代价，选择小修小补，这个小修小补有可能和有问题的代码混杂，导致更大的代码。
3) 过程对开发效率和应变能力，以及组织的影响
案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量，导致ST为了完成任务，提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力，导致一些需求的实现本应在低一层的代码中实现的，却在高层用蹩足的方式实现。
案例B.帮助系统的问题。帮助系统一开始采用一个个单独分散的静态页面。出于性能的考虑和部门负责考虑。帮助系统不断改进中，过程缺乏组织性，文件的命名规则随意，存储位置随意，造成了管理的混乱。直接的后果是页面的入口混乱和各自引用关系混乱。
在帮助系统的第二版，从静态页面转成动态页面。采取统一分类和命名规则，并统一了入口。同时采取分级管理引用关系，适度冗余。虽然减低了运行性能。但提高了开发效率和可维护性。
二、架构的性能问题解决讨论
性能问题——嗯，一个非常神圣而高深的问题的。从我刚刚开始工作的时候，至今依然是。然而我相信，一定存在一个基本的思路和方法，我以为解决性能问题的工作还是在于分解,通过分解来确定问题域。
1. 性能调优的关键
性能调优的关键是：发现性能瓶颈所在，慢是相对概念，评价标准是符合不符合系统要求。调整同时需要考虑维护成本，因为维护成本通常是开发成本的3倍。
2. 性能调优的公式
先介绍三个公式性能问题的公式:
总处理单量 = 总处理时间/ 单笔请求处理时间 * 总并发数
这个公式另一个写法为:
总处理时间 = 单笔请求处理时间 * 总处理单量 / 总并发数
不同的写法代表不同的关注点，适合不同类型的业务类型, 一般说前一种写法代表在线请求的，后一种写法代表后台batch;即高并发或大数据量问题.
也有客户给明确要求系统要支持xxx并发，这个就需要了解客户的这个并发数是如何计算得来，需要通过分析客户的业务，而通常是根据总处理单量来确定客户实际的并发数。
但无论如如何，四个变量中，总处理单量和总处理时间是先被确定的，换句话说需要关注是单笔请求处理时间和并发数，也就是降低单笔请求处理时间或者增加并发数。
对于单笔请求处理时间，其公式为：
单笔请求处理时间 ＝ 数据计算时间 ＋ 数据读写时间＋其它技术导致时间消耗
很显然降低单笔请求处理时间就需要降低三个因素消耗的时间。
1.降低单笔请求处理时间
第一原则是, 只计算一次.缓存计算结果；
第二是，延迟部分计算（在不影响结果的情况下，将部分后续计算延后处理）
第三是，提前部分计算（例如对于年度的batch计算，可以在每个月都计算各自数据，年底汇总即可）
2.降低数据读取时间,分三种
2.1. Global的,系统启动时加载
2.2. Long Time, 可采用LRU方式cache
3.2. Per operation. 第一次访问加载,operation结束后丢弃.
3.降低数据写入时间
例如文件写入通过buffer一次flush；对于SQL采用batch提交（hibernate的做法）；对于同一张表数据只做一次更新；
4 .改进计算时间，针对不同技术结构采用不同手段。
4.1.让计算支持并发,提高性能,例如采用MapReduce的方式
4.2.改进算法.例如数据库中的SQL改进.
4.3.减少不必要计算时间.
5.减少其它技术原因导致的消耗
如JVM的GC导致性能消耗等
对于总并发数，其公式为：
总并发数 ＝ 单机服务器并发能力 * 总并发服务器数
3. 确定改进方案
那么如何确定那些因素需要调整呢，在于两个方面的分解：
A. 业务层面
业务层面只是指通过业务行为分析, 把性能问题分解为不同的部分,每个部分面临性能压力现状和目标,最终确定需要优化的问题域.
业务层面分解包括4个内容: 功能, 内容,时间和区域.最重要的是前三个.
以eBay为例, ebay对于前端功能划分划分为70多个功能,不同的服务器处理不同的功能.
内容是指内容热点,比如对于search来说,就按体育,数码,音乐等划分,不同内容有不同热点数据,以及不同搜索关键匹配.
时间, 时间是一个非常重要的因素,在一些特定时间段,性能的要求会非常高.比如下半夜的访问点击量和白天的就有不同.对于一些batch来说, 月末或者年末处理的单量就有明显的提高,比如分红险的记息,平时每天只有7000单,而年末会有12w单.
地点划分,不太常见,不过也有助于分配计算资源.
业务层面的分析不仅是确定问题所在,还是确定优化的策略.比如有一个batch计算,执行时间比较长,而通过业务分析,发现该计算只针对特定的业务, 系统全部有效单量是12w单,而符合计算要求的只有3000单,只要加上一个前置判断就可以免除无谓的计算,运行时间减少数个小时(大约0.2秒1单).
B. 技术层面
系统建立时技术结构,通常一个系统结构如下:接入网络,Web服务器,应用服务器,以及数据库服务器.
在这样结构下，要小心的分析和验证系统性能的瓶颈，需要优化Web服务器，或者提高数据库并发能力等等。这部分网上的资料非常多。
采用并发立刻面临一个问题,即负载均衡.负载均衡如果无法正常的工作,那么并发也就无法正确的工作.负载均衡可以静态分布,也要动态分布.这里面涉及的问题比较多.服务器自带的负载均衡有时不能满足业务上的需要,要自行开发.
互联网网站的特点是交易少,事务短和并发高.对于网站这一特点需要做一番分解.网站的计算可以分解为:静态内容和动态内容,动态内容又可以分为状态无关(stateless)和状态有关(stateful).
静态内容通过负载均衡或者CDN就可以简单做到.
动态内容特别是状态有关的就复杂一点.动态内容中涉及到两大技术:session和cache.
Session技术导致很多问题.负载均衡中导致session复制的难题.解决的方式是:1. 把所有的session数据存储到数据库中,这样通过增加数据库的IO读取,换取应用服务器没有任何session数据问题(另一种做法是把session数据放到cookie或者页面hidden值中);2. 负载均衡采用Hash法,固定的把同一个请求绑定到同一台服务器上,这样通过牺牲一定的负载,换取应用服务器的session数据.
应用session sticky,虽然避免了session的复制,但是依然面临failover的问题.如果应用程序在session中放入了domain object,在failover就容易出问题.一个解决方法是对session的set和get进行拦截,发现是domain object就只在session中记录ID+ClassName结构,而把对象放入cache中,failover时session中内容简单,就通过cache从数据库加载.(SpringSide对于jBPM的扩展采用相同策略)
Cache技术本事没有特别的要说的,但它处在负载均衡环境中就会带来问题:缓存数据失效(版本低).解决的问题有两种:1. 独立缓存+广播通知.一旦数据更新后立刻广播通知,这样引发的问题是通知的管理.2. 采用中央缓存,如memcached技术,代价是网络读写.
Center Cache和Cluster Cache的特性比较如下：
Center Cache没有同步问题，所以，remove/clear的时候，比较有优势，不需要把通知发送到好几个计算机上。但是，Center Cache的所有操作，get/put/remove/clear都是Remote操作。而Cluster Cache的get/put都是Local操作，所以，Cluster Cache在get/put操作上具有优势。
Local get/put在关联对象的组装和分拆方面，优势比较明显。 关联对象的分拆是这个意思, 比如，有一个Topic对象，下面有几个Post对象，每个Post对象都有一个User对象。 Topic对象存放到Cache中的时候，下面的关联对象都要拆开来，分成各自的Entity Region来存放。
Topic Region -> Topic ID -> Topic Object
Post Region -> Post ID -> Post Object
User Region -> User ID -> User Object
这个时候，put的动作可能发生多次。Remote Put的开销就比较大。 Get的过程类似，也需要get多次，才能拼装成一个完整的Topic对象。
三、架构的开发成本以及品质问题解决讨论
架构一个重要的关注点在于控制开发成本，这点很重要，因为通常讲维护成本是开发成本的3倍。降低开发成本核心，在于提高效率，这也意味着提高了开发对需求的响应时间，而时间对公司来说是重要的。
1. 问题域
问题域可分解为两种类型，业务上和技术上。（又见分解，分而治之真是老祖宗传下的灵丹妙药啊）
1. 业务上。问题域分解为，逻辑的纵向抽象层次，以及逻辑的横向模块分解和集成。
2. 技术上。问题域分解为，纵向的技术主题，以及横向的技术职责的分解和集成。
A. 领域基本问题
所以通常而言，领域模型设计中，模块分解，抽象分层和职责分层都是重要手段。问题域为：流程，业务实体和计算（包括规则）。
- 对象的抽象分解和集成
- 对象的依赖分解和集成（模块内和模块外）
- 流程的分解和集成（页面流，工作流以及计算流程）
- 进程边界：用户请求重定向，以及业务数据持久化等。
B. 领域组件问题
面向对象语言本身没有提供的组件级别的依赖关系集成能力。语言不提供，因为领域组件的粒度太大，超越了语言的范畴。但我们可以通过框架提供，在Java体系中，目前已经有一个较好的解决方案：OSGi（JSR291）。可以完美的解决组件服务依赖关系管理，包括热替换。
同时另一个问题——逻辑分层的问题：保险产品面临的核心层，国家层以及公司层三个逻辑层次分解和集成能力。这点的解决方案可以通过OSGi + Spring来解决，包括了静态差异性替换和动态差异性替换。
还有组件边界保护问题，我们希望限制别的组件访问本组件内部实现，有两种手段可以完成，1是提交部署时，通过在代码提交时的代码检查工具，或者发布时编译工具完成；2是通过OSGi的边界限制能力。
C. 逻辑替换问题
逻辑的替换根据开发方式不同，有两种类型：基于接口和基于继承；
A. 基于接口（包括了静态替换和动态替换）
1. 静态替换是override，在OSGi中只要停止原有服务，启用新服务即可，而在Spring中更改相应配置文件即可；
2. 动态替换，其实是指运行时Condition Service Locator，在OSGi中可以利用Extension Point（Plug-in）解决，而Spring中只要提供一个类似Service Locator就可以。
B. 基于继承（或者静态类）
1.开发时，直接修改源代码编译；
2.编译时，采用AspectJ，在编译时提供替换；
3.加载时，开发一个新逻辑的同名类，但其加载路径优先于原有类；
2. 基本手段
提高开发效率和品质的基本手段是分解——即充分的分离系统中不同的关注点，好处不用说了，可以并发的工作，每个人面对的问题都简单而容易操作。而与分解对应的集成，只有提供了好的集成能力，分解才成为现实，而只有分解了，才能清晰的提供业务更多适应性。
分解和集成的手段分为编程语言和技术框架两个层面。所谓语言就是强框架，而框架就是弱语言。
A. 语言
现代面向对象的语言提供如下能力：抽象和派生能力，以及接口隔离能力。实际提供两种分解和集成能力：
1. 把逻辑分解在两个层次中，而通过继承的方式把两个部分集成在一起。
2. 把逻辑的外观和实现分解在两个地方，而通过接口实现的方式把两部分集成在一起。
另一种语言AspectJ或者C#语言2.0之后提供的特性：把流程逻辑，分解在不同的地方，而通过签名匹配，利用代码生成的方式来把几部分集成在一起。
B. 框架
然而语言提供的集成能力，毕竟底层，而且有限，扩展起来也格外小心。因而技术框架提供另外的集成能力就格外重要：
1. 对象关联关系的分解和集成，如Spring提供容器管理能力
2. 模块间关联关系的分解和集成，如OSGi，ESB等
3. 不同系统的类型分解和集成，如Spring利用动态代理提供的Exporter模式。
4. 流程逻辑的分解和集成，如Spring Web Flow以及jBPM。
C. 设计
说起集成，就不得不提到一种类型的对象存在——VO对象。VO对象是为了集成而存在的；其意义是：1. 保护系统的信息边界，提供一种结构可以使其它系统或者组件通过编码方式获取系统内信息的方式；2. 保护系统的事务边界，领域对象技术上携带着持久化信息，通过VO可以屏蔽得以屏蔽。常见的VO对象存在于Web层和Domain层。
因此，VO对象的存在只是为了集成而存在，其是否存在的取决于框架的两个方面：对象路径访问能力以及事务边界管理。
Web层VO对象，以SWF为例，早在SWF 1.x时代，框架就提供了丰富的对象路径访问能力，但其Web交互是典型的MVC2方式，事务边界在view的render前关闭，因而导致需要特定的VO对象来避免持久化信息问题；而SWF 2.x时代，view的render是在事务边界内，VO不在需要。
Domain层VO对象，通常是用于不同领域组件间的交互，但随着架构的改进，集成代码独立存在而不再嵌入到组件内部，组件的边界问题保护不复存在；更进一步的是，框架提供自动化的接口适配映射能力的增强。因而VO对象也失去存在的意义。
BTW：通常语言作为架构的基础引入和更换是有巨大风险的；而通过提供强大的框架能力，框架尽可能多的完成技术问题，并通过元数据，模式以及约定降低业务和框架的耦合。避免因为框架升级带来不必要的成本。
从技术手段上，提高开发效率的另外两个手段是代码生成和类库引用。但代码生成和类库引用，都只解决了逻辑的分解能力，没有提供集成能力，所以一般情况下需要提供框架集成，尤其代码生成需要在系统的最外层，避免集成带来的问题。
4. 学习成本
对于开发团队来说，额外面临一个问题，组织内部的学习成本问题。
1. 需要保持分解以及集成能力本身的简约性
这个……其实是一个culture问题，不再罗唆！
2. 采用模式和约定是减少学习成本的另一种手段。ROR的兴起就是最好的例证。
成本还表现在组织的划分上，应用开发/框架开发，而在每个层面又划分为横向模块划分。
总结一下，解决架构面临开发成本问题需要如下几个方面：
0. 问题域
1. 分解与分层
2. 架构与类库，Spring，Hibernate。起支撑性作用。
3. 模式和技巧
4. 领域模型
5. 方法论
5.1.开发方法：OO（设计模式），FP(函数式编程)。
5.2.设计方法：Domain Model Prototype和业务行为的分析模式。
5. 质量问题
架构面临的品质问题，则通过自动化测试，代码检测工具来完成。
必须大量应用自动化测试，减少人工硬调试的复杂性，重复性和不确定性。
自动化测试包括单元测试和集成测试。无论是单元测试还是集成测试对面临需要脱离隔离依赖关系并保证开发的并行性。
单元测试面临的项目执行问题：
5.1. 设计的粒度问题。设计的粒度大小将直接决定单元测试的难易程度。开发分工如果是设计和开发两种角色集一体的，问题自我消化；但如果是分开，就会带来一些分工认识问题。
5.2. 遗留系统风险。遗留系统通常依赖关系复杂，设计结构以及粒度也不好，同时缺乏既有测试用例。在遗留系统维护成本很高，为了满足测试用例，通常需要对遗留系统重构，风险很高。
5.3. 测试用例评估与考核。测试用例不是越多越好，通常系统重构也会导致一些测试用例被抛弃，过多非核心用例反而是在重构中带来成本。因此对于测试用例进行评估成为一种必要，评估的标准较难确定。
5.4. 工作量评估。写测试用例技术上并非难题，但不代表没有工作量。如果评估工作量也是一个问题。
5.5. 测试用例的简易度。虽然技术上非难题，但是业务开发面临的种种问题，还是需要项目做一定的封装，以便提高测试用例的开发和运行的效率。
以上几点都是直接影响项目的进度，因此如果不能有效处理好，很难说服项目经理在项目计划中执行单元测试。
6. 文档的思考
6.1. 文档的分类
架构文档，high level设计文档和detail设计文档
6.2. Detail设计文档面临的问题
A. 维护成本高。开发过程中设计到的具体而维的细节变化较频繁，导致维护成本偏高；而开发成本和维护成本1：3的比例，导致这些文档在后期维护的成本也很高；
B. 验收成本高。目前缺乏自动化的验收工作；ST是黑盒测试，验收的是系统，而非文档；独立验收人员的学习曲线太高；而开发人员自我验收的效果不好，即便是交叉验收也容易达成私下协议；
C. 收益低。文档的维护人员，工作缺乏成就感；这些文档的阅读者通常是IT人员，使用代码阅读无疑具有更好的阅读效果；
