这一节的内容非常的多，我拷贝到word中之后达到了30页的大小，为了防止无法上传到博客，我分成2部分翻译。因此能看完此篇，绝对有学好oracle的潜质。

因为文章太长，所以我可能会将一些英文的内容在翻译完删除掉；最好的办法是花几分钟扫一眼大致内容，然后去看原版的英文文档最妙。

2 Designing and Developing for Performance

Optimal system performance begins with design and continues throughout the life of your system. Carefully consider performance issues during the initial design phase so that you can tune your system more easily during production.

理想情况下，性能设计要在系统设计阶段就要考虑进来，并且要贯穿在系统生命周期当中。在应用系统设计阶段仔细的考虑好系统的性能问题，远比在上线之后再去调优性能要容易的多。（这些话说起来很简单，但是在银行的系统中，很多项目经理可能只有2年左右的工作经验（5年工作经验的或许都转行去淘宝开店了，或者当个小官，不做技术了），很难让他们去考虑那么多，而且他们本身开发能力就不够，哪里能考虑那么多。不仅是年轻人办不到，在项目工期比较紧的时候，牛人也顾不了那么多，只能靠经验大概的去判断一下就开始设计开发了（这算好的了，有些项目主管是那种仅仅嘴上能说的那种，许多知识只是听说过一点却不懂实际开发技术还要参与设计，即使不对它还要坚持它的想法，可想而知后果是什么样子的。因此项目经理参与的越少项目成功的概率越大）。因此性能问题基本上都放到项目上线前的那段压力测试阶段去修正，而oracle已经告诉我们这样是比较难的了---它说的没错，的确比较难了。很多时候在性能出现问题时需要修改代码，但是往往代码已经开始进行冻结状态，SVN也要冻结的，没有高层的授权不能去随意的改的，否则一旦修改后就需要将全部的业务功能要重新测试一遍----测试人员能饶得了你这么折腾嘛！下次还想不想混了！）

This chapter contains the following sections:

• Oracle Methodology

• Understanding Investment Options

• Understanding Scalability

• System Architecture

• Application Design Principles

• Workload Testing, Modeling, and Implementation

• Deploying New Applications

2.1 Oracle Methodology

System performance has become increasingly important as computer systems get larger and more complex as the Internet plays a bigger role in business applications. To accommodate this, Oracle has produced a performance methodology based on years of designing and performance experience. This methodology explains clear and simple activities that can dramatically improve system performance.

Performance strategies vary in their effectiveness, and systems with different purposes—such as operational systems and decision support systems—require different performance skills. This book examines the considerations that any database designer, administrator, or performance expert should focus their efforts on.

System performance is designed and built into a system. It does not just happen. Performance problems are usually the result of contention for, or exhaustion of, some system resource. When a system resource is exhausted, the system cannot scale to higher levels of performance. This new performance methodology is based on careful planning and design of the database, to prevent system resources from becoming exhausted and causing down-time. By eliminating resource conflicts, systems can be made scalable to the levels required by the business.

随着互联网应用扮演着更加重要的角色，系统变得非常的庞大而且复杂，性能问题显得更加的重要。为了达到性能要求，oracle根据自己多年的深耕发展了自己的一些性能方法论。这种优化技术清晰明了简单实用，同时能像梦一般（显著）的提升性能，呵呵。居家生活必备良药啊！

性能优化策略在不同的系统业务领域有着不同的方式，比如在OLTP系统和数据库仓库中就不一样。本书主要研究了对于数据库开发人员，管理人员，和性能专家都应该考虑的基本问题。

系统性能功能被内嵌到系统之中。不是说性能问题时时刻刻都发生。它通常是由于争用（竞争，并发）或者是过度的使用某些系统资源造成的。当一个系统资源被过度使用时，系统性能很难提升到一个很高的层次。oracle新的性能技术是基于对数据库深入的研究以及精心的设计而发展演化的，它能阻止那么系统资源被过度使用所导致宕机情况的出现。通过消除这些资源乱用情况，系统将变得更加的稳固可靠，以达到业务要求的水平（只要适合业务要求即可，不需要过多的优化----每多一步优化对项目都是成本压力）。

2.2 Understanding Investment Options     项目投入

With the availability of relatively inexpensive, high-powered processors, memory, and disk drives, there is a temptation to buy more system resources to improve performance. In many situations, new CPUs, memory, or more disk drives can indeed provide an immediate performance improvement. However, any performance increases achieved by adding hardware should be considered a short-term relief to an immediate problem. If the demand and load rates on the application continue to grow, then the chance of the same problem occurring soon is likely.

In other situations, additional hardware does not improve the system's performance at all. Poorly designed systems perform poorly no matter how much extra hardware is allocated. Before purchasing additional hardware, ensure that serialization or single threading is not occurring within the application. Long-term, it is generally more valuable to increase the efficiency of your application in terms of the number of physical resources used for each business transaction.

随着CPU，内存，硬盘的价格不断的下降，通过购买更多的硬件去提升性能是许多人的想法。在许多场景下，购买新的CPU,内存，硬盘的确能立竿见影的看到效果。通过购买硬件来立即大幅提升系统性能仅仅是一种吃兴奋剂的效果。但是如果需求和压力继续增长的话，这种解决问题的办法是不可行的，也就是说问题还是在前面路口等着你。

在有些场合下，加硬件一点都无法提升性能。差劲的系统设计无论加多少CPU内存都没用的，它们根本无法使用到的。在你购买新的硬件之前，确保你的应用程序不是串行化处理的，同时不是单任务（单进程）在运行。长期来看，通过提升应用程序的资源使用效率是更加划算的。

注：在银行业开发C语言程序是很简单的一件事，因为内存不够要银行加就是了。所以很多时候看到一个人在仔细的节约内存使用时，就知道他基本上是个外行（或者高高手）。多数情况下通过增加CPU和内存，我们可以更加容易的提升系统的性能，特别是硬件很便宜的情况下。简单算一下：买32G内存也不过3000块钱，请个专家优化一下可能几万就没了，回头可能还要买硬件，对不？

应用服务器加再多的CPU也不过是电费空调费增加的问题。但是我们知道ORACLE可是有一种按CPU卖钱的，这样在数据库上加更多的CPU有时是不划算的，这就是为什么有时在开发的时候会将许多业务直接在应用中实现，而不是去使用数据库已提供的功能，就是这个原因。

但是有的时候加硬件是没有用的。可能有人说怎么可能？ 我举个简单的例子，兄弟我唯一能玩的游戏就是蜘蛛纸牌（4幅牌的那种噢），其他的都不喜欢。那你说给我一个8核，32G内存的电脑对于提升蜘蛛纸牌性能有多大影响？同样的道理，我见过一个系统，他们在服务器上就一个进程在处理业务（因为难以并发执行，我看了系统设计后发现要并发的确需要大量的工作要做，的确比较难），这样使用1个主频更高的POWER CPU更划算些，因为它只能使用这一个，给2个就是浪费，不如划分一个给我玩蜘蛛纸牌了。另外一个就是批量程序，通常这玩意儿是要按串行化进行处理的，比如先要批量增加新注册的个人资料，然后再处理公司的工资入账预处理，同时并发执行个人业务相关预处理，但是以上所有这些工作不能放到真正入账程序步骤之后，必须要提前处理的，顺序一定要正确的，这就是串行化。因此对于多大的交易量，单一时刻也只能使用那么多。更简单的说就是只有一张嘴，不能说着话再吃着东西吧！（或许上帝发明鼻子就是为了解决吃饭时还可以吸气？）

2.3 Understanding Scalability

The word scalability is used in many contexts in development environments. The following section provides an explanation of scalability that is aimed at application designers and performance specialists.

扩展性这个词在开发环境中使用的比较多些。下面的章节和系统设计人员和性能分析人员讨论一下扩展是什么玩意儿。包含了什么是可扩展性？系统如何扩展？阻止可扩展的因素有哪些？（我个人特别喜欢oracle这种风格，它总是能以枚举的方式仔细的剖析问题，然后加以解决）

This section covers the following topics:

• What is Scalability?

• System Scalability

• Factors Preventing Scalability

2.3.1 What is Scalability?

Scalability is a system's ability to process more workload, with a proportional increase in system resource usage. In other words, in a scalable system, if you double the workload, then the system uses twice as many system resources. This sounds obvious, but due to conflicts within the system, the resource usage might exceed twice the original workload.

可扩展性就是可以通过增加系统硬件资源的使用量就能处理更多业务的一种能力。换句话说，当业务量增加一倍的时候，系统资源比如CPU使用率真就随之增加一倍。听起来好像是理所当然的事情，但是由于系统内部设计中的资源竞争和冲突，这个系统资源的使用可能不止2倍的。下面列举几个差劲的扩展性导致资源无法合法使用的情况：

Examples of poor scalability due to resource conflicts include the following:

• Applications requiring significant concurrency management as user populations increase   随着用户量的增加，系统需要更多的并发处理

• Increased locking activities                                                                                         业务量增加时锁随之增加

• Increased data consistency workload                                                                           数据并发量随着业务量增加而增加

• Increased operating system workload                                                                          操作系统负荷增加

• Transactions requiring increases in data access as data volumes increase                        业务量增加时事务处理随之增加

• Poor SQL and index design resulting in a higher number of logical I/Os for the same number of rows returned  SQL和index设计差劲

• Reduced availability, because database objects take longer to maintain                           数据库需要更长的维护，导致可用性降低

An application is said to be unscalable if it exhausts a system resource to the point where no more throughput is possible when its workload is increased. Such applications result in fixed throughputs and poor response times.

由于过度使用系统资源，当一个系统的业务增加到一定程度时，系统的吞吐量或者响应时间已经无法再提升时，我们称它是不可扩展了。这类系统就是吞吐量是固定的，而响应时间也是相对无法再提升的。

资源过度使用包括了以下几个：硬件的消耗；过多事务进行表扫描造成IO资源不足；过度的网络占用；内存过度占用导致交换出现；过多的进程或线程配置导致操作系统忙于调度。（简单说就是CPU消耗多，IO消耗多，网络消耗多，内存消耗多，进程太多）

Examples of resource exhaustion include the following:

• Hardware exhaustion

• Table scans in high-volume transactions causing inevitable disk I/O shortages

• Excessive network requests, resulting in network and scheduling bottlenecks

• Memory allocation causing paging and swapping

• Excessive process and thread allocation causing operating system thrashing

This means that application designers must create a design that uses the same resources, regardless of user populations and data volumes, and does not put loads on the system resources beyond their limits.

也就是说应用程序设计人员要开发出一个可以使用相对固定资源的应用程序，当用户量增加（比如网银应用，ATM机增加）和数据量增加时，不会导致系统资源的使用超过应有的限制。（在银行里通常会监控CPU,内存的使用，一般情况下一旦达到90%就开始报警了；几分钟内警报无法解除就要开始问责了）

2.3.2 System Scalability

Applications that are accessible through the Internet have more complex performance and availability requirements. Some applications are designed and written only for Internet use, but even typical back-office applications—such as a general ledger application—might require some or all data to be available online.

互联网应用对于可用性有着更高的性能和可用性的要求（12306就是活生生的例子啊）。有些程序只是为了互联网的应用，但是对于一些商业的如账务处理程序也要求7*24小时的可用性的。简单说就是不能宕机！工行，建行等ATM机的前置系统宕机试试！上交所，深交所宕机试试，一会就上报国务院啦！

Characteristics of Internet age applications include the following:  互联网应用主要包含着下面几个特点：

• Availability 24 hours a day, 365 days a year                       7*24小时服务

• Unpredictable and imprecise number of concurrent users     不可预测的并发用户量（天弘基金做余额宝就是一开始没预测到吧！网民太给面子了，我算一个了）

• Difficulty in capacity planning              难以预先做好扩容计划（准备处理1000W用户的系统如果只有10W人来用，也是浪费钱；反之更惨）

• Availability for any type of query         查询条件乱七八糟

• Multitier architectures                        多层次的体系架构（这个应该还可以了，weblogic，spring等等架构还是必要的）

• Stateless middleware                        无用的中间层（这个在C架构中容易出现，可能是为了灵活造成不必要的中间层设计）

• Rapid development timescale             开发时间比较短（银行里开发更短！）

• Minimal time for testing                     测试时间不够（互联网应用有测试吗？许多程序1天三更新的，不就是说明没测试就让我们做小白鼠嘛）

Figure 2-1 illustrates the classic workload growth curve, with demand growing at an increasing rate. Applications must scale with the increase of workload and also when additional hardware is added to support increasing demand. Design errors can cause the implementation to reach its maximum, regardless of additional hardware resources or re-design efforts.

下面的图说明了一个随着交易量增加后的一个压力增长曲线图。应用程序必须要要灵活的处理突如其来的压力，要设计成当在增加硬件情况下就可以从容处理。如果设计不善，将无论怎么增加服务器配置都已经达到自己性能的瓶颈（吃的再多也跑不过博尔特）。（其实这个只是理论上的，比如说oracle自己的RAC系统很强吗？不见得吧。但是在增加单服务器配置时oracle的确很NB，但总会有它的一个峰值的）

Figure 2-1 Workload Growth Curve      压力增长曲线图

Applications are challenged by very short development timeframes with limited time for testing and evaluation. However, bad design typically means that you must later rearchitect and reimplement the system. If you deploy an application with known architectural and implementation limitations on the Internet, and if the workload exceeds the anticipated demand, then failure is a real possibility. From a business perspective, poor performance can mean a loss of customers. If Web users do not get a response in seven seconds, then the user's attention could be lost forever.

In many cases, the cost of re-designing a system with the associated downtime costs in migrating to new implementations exceeds the costs of properly building the original system. The moral of the story is simple: design and implement with scalability in mind from the start.

在有限的开发测试时间里开发出好的系统是非常有挑战性的。然而糟糕的系统设计通常意味着需要重新设计架构和重新编码实现。对于互联网应用而言，当数据量超过了系统能够承受的压力，错误是总是难免的。从商业角度看，差劲的性能将会导致客户的流失。如果一个用户在7秒无法得到响应结果，那么这个客户可能永远也不会登录了。（什么逻辑啊，你瞧瞧我们银行业网银设计的那么烂，不还得用嘛，客户算个屌啊，不理解中国国情的表现！呵呵，我个人很看不起那么银行的JAVA网银设计人员，多少年啦，除了浦发等个别银行能在firefox上使用，其他还是绑定在那个破IE上，对这些开发人员真是无语！你们小小的变更一下CSS,js能死啊！）

2.3.3 Factors Preventing Scalability

When building applications, designers and architects should aim for as close to perfect scalability as possible. This is sometimes called linear scalability, where system throughput is directly proportional to the number of CPUs.

In real life, linear scalability is impossible for reasons beyond a designer's control. However, making the application design and implementation as scalable as possible should ensure that current and future performance objectives can be achieved through expansion of hardware components and the evolution of CPU technology.

在设计系统时，架构师应该尽可能地实现可扩展性。也就是说达到线性增长的方式，系统的处理能力随着硬件资源的增加，吞吐量也随之增加。

在现实生活中，线性扩展性架构是由于多种原因无法实现的。但是我们要有理想，有信念，要尽可能在在设计阶段就考虑到如果压力增大时，通过对CPU内存增加达到提升系统性能。

（微软SQL SERVER这个破东西在解决并发方面就是一个反面的例子！一并发就乱加锁啦，能不能学学Oracle的设计啊！DB2好像也会锁提升的，只学oracle的DBA绝对不可想像这些系统的！好在银行的核心系统除了oracle，DB2是不会用其他的了。informix,sybase逐渐被oracle替代，SQL SERVER是那种可有可无的边缘项目可能会用，MYSQL这种互联网应用数据库，果断无法应用到金融方面大事务系统上的。我OCM老师说MYSQL主要就是要消灭SQL SERVER的，呵呵）

Factors that may prevent linear scalability include:                                            影响线性扩展的因素包括：

• Poor application design, implementation, and configuration                        差劲的应用程序设计、实现、及配置化

  The application has the biggest impact on scalability. For example:             应用程序在扩展性方面有非常大的影响，比如：

  • Poor schema design can cause expensive SQL that do not scale.         糟糕的schema设计导致昂贵的SQL处理（你oracle能实现此功能不就可以啦？）

  • Poor transaction design can cause locking and serialization problems.  糟糕的事务处理机制导致锁和串行化处理

  • Poor connection management can cause poor response times and unreliable systems. 糟糕的连接管理导致响应时间下降和系统不稳定（这个多数不是问题的，因为C是通常长连接的，JAVA是用连接池的）

  However, the design is not the only problem. The physical implementation of the application can be the weak link. For example:

  然而应用程序设计差还不是所有问题的全部。物理配置方面也是薄弱环节。

  • Systems can move to production environments with bad I/O strategies.  糟糕的硬盘配置不正常（通常测试环境配置差，结果生产也按测试一样配置的结果）

  • The production environment could use different execution plans than those generated in testing. 测试环境与生产环境执行计划不一样，这很正常，因为测试环境使用的数据通常都是自己手工造的数据。但是我们应该去分析。同时如果是维护期的话可以使用手续章节讲解的内容处理。

  • Memory-intensive applications that allocate a large amount of memory without much thought for freeing the memory at run time can cause excessive memory usage.    应用程序分配了太多的内存却没有释放掉。

  • Inefficient memory usage and memory leaks put a high stress on the operating virtual memory subsystem. This impacts performance and availability.                         内存太小或者出现内存泄漏导致内存swap到硬盘上了，这个是影响性能和可用性的。

• Incorrect sizing of hardware components

  Bad capacity planning of all hardware components is becoming less of a problem as relative hardware prices decrease. However, too much capacity can mask scalability problems as the workload is increased on a system.

糟糕的硬件配置不足已经随着硬件价格的下降很少成为一个问题了。然而太多的容量有时候会掩盖系统的一些问题。（比如程序设计的差，但是来了128G内存，要很久才能知道有没有内存泄露）

• Limitations of software components            软件限制

  All software components have scalability and resource usage limitations. This applies to application servers, database servers, and operating systems. Application design should not place demands on the software beyond what it can handle. 所有的软件都有资源使用的限制。无论是对于应用软件，数据库，还是操作系统都是一样的。应用程序设计应该考虑到这些因素，不要超过他们的能力范围。（比如oracle让给它设置processes=10000，操作系统也挂了，何况它呢）

• Limitations of Hardware Components          硬件限制

  Hardware is not perfectly scalable. Most multiprocessor computers can get close to linear scaling with a finite number of CPUs, but after a certain point each additional CPU can increase performance overall, but not proportionately. There might come a time when an additional CPU offers no increase in performance, or even degrades performance. This behavior is very closely linked to the workload and the operating system setup.

  Note:

  These factors are based on Oracle Server Performance group's experience of tuning unscalable systems.

硬件也不是完美扩展的。多处理器在有限的CPU数量内可无限的接近线性扩展，但是过于这个点再增加也没用了，即不是成比例增加的。当过了那个极限以后，再增加CPU已经没有什么性能提升，还可能会导致性能下降的。这种行为类似于压力和操作系统启动（这个不是很理解啊，CPU多的话，操作系统启动会变慢，和这个有什么关系）

这些内容和写oracle此文章的作者无关。因为他们是根据Oracle Server Performance group's 的一些非扩展系统的经验而编注的。

也和我无关，英语不是我母语，只能这么翻译。

2.4 System Architecture

There are two main parts to a system's architecture:

• Hardware and Software Components

• Configuring the Right System Architecture for Your Requirements

2.4.1 Hardware and Software Components

This section discusses:

• Hardware Components

• Software Components

2.4.1.1 Hardware Components

Today's designers and architects are responsible for sizing and capacity planning of hardware at each tier in a multitier environment. It is the architect's responsibility to achieve a balanced design. This is analogous to a bridge designer who must consider all the various payload and structural requirements for the bridge. A bridge is only as strong as its weakest component. As a result, a bridge is designed in balance, such that all components reach their design limits simultaneously.

现在的设计人员和架构师是有责任去规划硬件的规格，或者说提出最少的硬件要求。这是一个架构师要实现一个平衡设计的要求。这个和一个桥梁设计是类似的，工程师要考虑各种部件的负荷，但是你只给他砖头不给水泥他达不到工程师建造的要求的。这个桥梁到底有多结实，是看他最薄弱处有多结实的。因此在资金一定的情况下，设计人员要考虑各种情况去平衡各个部件，以使其达到最大可靠性。

简单说就是架构师要提出自己的要求，需要多少CPU,多少内存，多少硬盘。这个在系统需求分析完之后就会提一个文档给运维组，由他们去采购的。如果无法达到要求的话，就需要回头赶紧修改自己的架构。多数情况下银行还是可以给满足的，但是对于一个老的系统，如果要进行功能或性能升级的话，就要在现有的服务器上进行。或者是当一个服务器最大只支持16G内存的时候想增加再多的内存，那只能等下一批机器采购的时候才能考虑是否能给项目组使用。所以有时候看起来很简单的一个升级却要拖一年，很大一部分原因就在这里----硬件不太位。

The main hardware components include:

• CPU

• Memory

• I/O Subsystem

• Network

2.4.1.1.1 CPU

There can be one or more CPUs, and they can vary in processing power from simple CPUs found in hand-held devices to high-powered server CPUs. Sizing of other hardware components is usually a multiple of the CPUs on the system. See Chapter 9, "Managing Operating System Resources".

从个人用的低效的单核到服务器的高性能多核处理器，他们性能差距是很大的。其他的一些硬件容量通常是CPU的好几倍。

2.4.1.1.2 Memory

Database and application servers require considerable amounts of memory to cache data and avoid time-consuming disk access. See Chapter 7, "Configuring and Using Memory".

数据库和应用服务器需要足够的内存去缓存数据，以避免太多的硬盘访问。

2.4.1.1.3 I/O Subsystem

The I/O subsystem can vary between the hard disk on a client PC and high performance disk arrays. Disk arrays can perform thousands of I/Os each second and provide availability through redundancy in terms of multiple I/O paths and hot pluggable mirrored disks. See Chapter 8, "I/O Configuration and Design".

IO子系统在个人电脑和服务器上差别是非常大的。服务器上的磁盘组可以达到几千个的IOPS（SSD都是几万几十万了），以及提供了可以热插拔和多路冗余功能（不是你想像的那种几分钟的热插啊拔啊的运动，不过也差不多了）。

2.4.1.1.4 Network

All computers in a system are connected to a network, from a modem line to a high speed internal LAN. The primary concerns with network specifications are bandwidth (volume) and latency (speed).

所有服务器都要连接到网络上，从简单的电话线到高速的内网（通常是光纤或者是华尔街的微波传输，我请教过一个物理研究生朋友，他说微波会比光纤快30%左右）。在网络中我们主要关注网络带宽和网络延迟两个指标。（对于光纤而言，每秒钟几G到几百G可以理解，但是这个延迟的指标我目前也不清楚生产上大概会达到多少毫秒或者微秒）

2.4.1.2 Software Components

The same way computers have common hardware components, applications have common functional components. By dividing software development into functional components, it is possible to better comprehend the application design and architecture. Some components of the system are performed by existing software bought to accelerate application implementation, or to avoid re-development of common components.

The difference between software components and hardware components is that while hardware components only perform one task, a piece of software can perform the roles of various software components. For example, a disk drive only stores and retrieves data, but a client program can manage the user interface and perform business logic.

与硬件方面的限制类似，软件也有自己设计功能上的限制。将软件的功能划分开来，会更好的理解这个系统的架构设计。有些系统模块，是根据现有的一些已经实现的功能中组装起来的，避免重新发明轮子。（比如已经有开源的linux,就没必要再自己写个操作系统了；oracle大量的使用了开源的软件，比如perl,glibc,libaio,sysstat,odbc等等我们安装时要求的软件，这些都是避免再重写一套的案例）

软硬件的区别在于硬件模块只执行一个任务，在各种软件模块中一部分软件就可实现此功能（这个地方翻译不准确，被绕进去了，可以不用看这段，讲的一点不生动活泼！）。例如磁盘驱动程序只负责存取数据，但是一个客户端应用程序要管理用户的界面录入，业务逻辑处理等等。

Most applications involve the following components:  多数的系统都会实现以下的功能

• Managing the User Interface                                用户接口管理（这个通常是JAVA做的）

• Implementing Business Logic                               业务逻辑处理（这个通常是C做的）

• Managing User Requests and Resource Allocation  管理用户请求和资源分配（网银的话是由JAVA处理或是weblogic吧，其他的多数是由C处理）

• Managing Data and Transactions                         数据管理和事务处理（基于上都是C来做的，存储过程也可以的）

2.4.1.2.1 Managing the User Interface

This component is the most visible to application users, and includes the following functions: 对用户可用的模块通过包含下面的功能：

• Displaying the screen to the user                                        一个漂亮的显示界面，不像sqlplus黑不拉叽的

• Collecting user data and transferring it to business logic        收集用户录入的数据，然后对其进行加工处理

• Validating data entry                                                          验证用户的数据合法性

• Navigating through levels or states of the application             根据级别或身份做不同的应用导航，简单说就是不同人看到的东西是不一样的

在银行业里，JAVA主要是负责用户录入，验证数据及展示一些报表，他们是为后面账务核心系统（C语言处理）做预处理。更简单的说就是JAVA将录入的配置信息插入或更新到表中，同时要保证数据正确，这样账务系统才能正常运转。比如一个人最大的年龄是150岁，结果导入了一个15000的数据进来，这样是不行的，必须要由JAVA去判断一下年龄是否符合业务要求；到了核心系统，就仅仅看这个录入的100岁的人有没有能力去贷款，要给他放贷的话最高额度可能是100块等等。通常情况下核心系统要求的人员非常少，一般1到5个人就差不多了够，JAVA人员通常会占用10到几十个，每天给客户画界面。

2.4.1.2.2 Implementing Business Logic

This component implements core business rules that are central to the application function. Errors made in this component can be very costly to repair. This component is implemented by a mixture of declarative and procedural approaches. An example of a declarative activity is defining unique and foreign keys. An example of procedure-based logic is implementing a discounting strategy.

应用实现的核心就是那些处理核心功能的模块。一旦这些核心模块出现错误就要赶紧去修复，就像看到alert日志中出错一样。这些模块的实现通常是declarative and procedural 共同实现的。具个例子就是：declarative 就是定义唯一索引和外键。procedure-based logic 就是实现打折销售策略。（这两个词语还没有好的翻译方式；或许他的意思是一个是搞技术的去做，一个是搞业务的去做，两个人共同配置以达到需要的效果？）

Common functions of this component include:

• Moving a data model to a relational table structure         将数据模型迁移到关系数据库上（比如以前的网状结构数据库或者将EXCEL表格数据）

• Defining constraints in the relational table structure        在数据结构（表）上定义约束（这个多数不用，因为很多语法在不同数据库上不好迁移）

• Coding procedural logic to implement business rules       编写程序逻辑去实现业务需求

2.4.1.2.3 Managing User Requests and Resource Allocation

This component is implemented in all pieces of software. However, there are some requests and resources that can be influenced by the application design and some that cannot.

In a multiuser application, most resource allocation by user requests are handled by the database server or the operating system. However, in a large application where the number of users and their usage pattern is unknown or growing rapidly, the system architect must be proactive to ensure that no single software component becomes overloaded and unstable.

这种模块通常是在所有的程序上都会有的。然而有些要求和资源会对应用程序的设计造成影响，而有的则不会。

在一个多用户的环境中，多数处理用户请求的资源分配是由数据库和操作系统做的。然而在一些大的应用系统中，用户的数量和使用方式是未知的，或者增长非常快的，这种系统架构的设计就要前瞻性的确保任何一个模块都不能出现大的问题，即应对大的冲击。

Common functions of this component include:

• Connection management with the database                                     与数据库的连接管理（如dedicade,shared,mixed）

• Executing SQL efficiently (cursors and SQL sharing)                         SQL执行的效率

• Managing client state information                                                   客户端状态信息管理

• Balancing the load of user requests across hardware resources         根据硬件资源来平衡用户的业务请求（如VIP单独给一台机器处理）

• Setting operational targets for hardware and software components   配置软硬件的资源使用

• Persistent queuing for asynchronous execution of tasks                   异步执行任务的持久排除

2.4.1.2.4 Managing Data and Transactions

This component is largely the responsibility of the database server and the operating system. 这个模块是数据库和操作系统的职责

Common functions of this component include:

• Providing concurrent access to data using locks and transactional semantics 通过锁和事务原语对并发数据进行访问管理

• Providing optimized access to the data using indexes and memory cache      使用index和缓存提供最佳的数据访问方式

• Ensuring that data changes are logged in the event of a hardware failure      确保在宕机时数据已经做了记录

• Enforcing any rules defined for the data                                                    确保数据的定义规则

2.4.2 Configuring the Right System Architecture for Your Requirements

Configuring the initial system architecture is a largely iterative process. System architects must satisfy the system requirements within budget and schedule constraints. If the system requires interactive users transacting business-making decisions based on the contents of a database, then user requirements drive the architecture. If there are few interactive users on the system, then the architecture is process-driven.

设计一个系统的架构是一个迭代的过程（也就是说不可能一次性设计好就完了，是需要不断进行调整的，或者是业务量上升或者响应时间要求提高等等）。系统架构师需要在计划时间及预算内设计出满足系统要求的功能。假如一个系统需要根据数据库中的内容处理交互式的用户请求，那么这个系统设计时就是由用户的要求驱动的。假如交互的用户比如少，那么这个系统就是功能驱动的。（个人理解：像淘宝之类的就是用户驱动的，它要考虑用户的数量，查询的条件等等；而银行的账务系统很少需要人去干预的，这类系统就是业务功能驱动的）

Examples of interactive user applications:         用户交互类的系统

• Accounting and bookkeeping applications  会计账务系统（会计人员要登录上去做查询或账务录入）

• Order entry systems                               订单处理系统

• Email servers                                         邮件服务

• Web-based retail applications                  淘宝零售

• Trading systems                                    交易系统

Examples of process-driven applications:         应用（程序，业务）驱动的系统

• Utility billing systems                              账务处理系统

• Fraud detection systems                        欺诈系统（或者是风险管理系统）

• Direct mail                                            直接的邮件处理系统

In many ways, process-driven applications are easier to design than multiuser applications because the user interface element is eliminated. However, because the objectives are process-oriented, system architects not accustomed to dealing with large data volumes and different success factors can become confused. Process-driven applications draw from the skills sets used in both user-based applications and data warehousing. Therefore, this book focuses on evolving system architectures for interactive users.

许多情况下，业务驱动系统要比多用户应用开发要相对容易些，因为他们不需要处理用户的接口请求。同时因为由业务驱动的方式，使得系统架构师不习惯于处理大数据量以及不同的成功历史因素使得他们变得混乱，神智不清（说的可能是以前的设计经验在这种新的系统上已经不适合了，或者说的就是我了）。业务驱动系统从基于用户的应用程序和数据仓库的技术经验中获得。因此本书聚焦于涉及到用户交互的体系架构（直接讲最难的啦）。

Note:

Generating a system architecture is not a deterministic process. It requires careful consideration of business requirements, technology choices, existing infrastructure and systems, and actual physical resources, such as budget and manpower.

The following questions should stimulate thought on system architecture, though they are not a definitive guide to system architecture. These questions demonstrate how business requirements can influence the architecture, ease of implementation, and overall performance and availability of a system. For example:

设计一个系统架构不是一个一成不变的过程（不确定的过程）。因为需要考虑到许多因素如：业务的需求，技术架构的选择，公司已经存在的基础架构或者说是代码库，实际的系统限制或项目预算、团队人员素质（开发人员的能力）等等的物理资源限制。---给的钱的少，团队差，时间紧，公司代码差，这些全都体现在我们国内的企业上了。设计一个好的产品，难！有多难？难于上青天啊！所以作为一个二流的架构师，如果有人再说我设计的差，那先多给点钱吧（我再去请个好的来设计，再招些好的开发人员，这总可以了吧）

下面的这些问题应该在系统架构设计时仔细的思考，尽管他们不是一个明确的指导手册。这些问题决定了一个业务系统怎么影响架构的设计，降低程序的实现的难度，以及总体的系统可用性及高效性。（下面具的例子一般是在需求分析阶段都要去考虑的，否则没有办法设计的）例如：

• How many users must the system support?             -----&gt 你的破系统，破业务到底要支持多少用户访问？

  Most applications fall into one of the following categories:     多数的系统基于上基于以下3个考虑：

  • Very few users on a lightly-used or exclusive computer                                  只有很少的用户在一个独有的或者压力比较小的系统上运行

    For this type of application, there is usually one user. The focus of the application design is to make the single user as productive as possible by providing good response time, yet make the application require minimal administration. Users of these applications rarely interfere with each other and have minimal resource conflicts.   这种系统通常只有一个用户在使用。设计的目标是给这个哥们提供尽可以快的响应时间，因此这种应用很少需要去管理。这种应用程序很少需要和其他用户进行打交道。（说的可能是我的蜘蛛纸牌程序不需要和其他人的蜘蛛纸牌沟通了吧）

  • A medium to large number of users in a corporation using shared applications  在一个中等的公司内部大家共用一些资源

    For this type of application, the users are limited by the number of employees in the corporation actually transacting business through the system. Therefore, the number of users is predictable. However, delivering a reliable service is crucial to the business. The users must share a resource, so design efforts must address response time under heavy system load, escalation of resource for each session usage, and room for future growth.对于这类应用程序，用户数是由在公司内部的，实际通过此系统进行交易处理的员工数决定的（比如公司报销时，可能同一时间就那2%左右的员工会同时登录系统进行报销录入）。因此用户数是可以预测的。然而这类系统需要一个非常健壮的服务功能。许多用户共享一个资源，那么设计的原则就是要在大负荷下能提供尽可能快的响应时间，增加资源以满足未来增加的员工。（我们公司那个破财务系统，是由2个2年工作经验的人写的，还只是支持IE,我都告诉他们去修改一点点CSS就可以用的情况下他们也不改，实在是不好意思在办公室骂人，特别是人家不是我们部门的，更不好去当着人家领导的面批评他们了）

  • An infinite user population distributed on the Internet                                    互联网上不确定的用户数据（网游，淘宝等）

    For this type of application, extra engineering effort is required to ensure that no system component exceeds its design limits. This creates a bottleneck that halts or destabilizes the system. These applications require complex load balancing, stateless application servers, and efficient database connection management. In addition, use statistics and governors to ensure that the user receives feedback if the database cannot satisfy their requests because of system overload.对于这类系统，额外的一些工作就是要确保系统中没有某一个模块是超负荷动作。这样就产生了一个瓶颈。这些应用程序需要更加复杂的压力测试（国内一般用loadrunner来压的），无状态的应用服务（这个不清楚啊），和有效的数据库连接（一般weblogic都帮应用开发人员处理了）。另外，要使用统计数据和协调部件确保，在数据库超负荷压力下无法满足客户请求时给用户一些反馈信息。（就像404网页无法打开错误一样，给点安慰的信息）

• What will be the user interaction method?   用户需要以什么样的方式和系统交互？在基于B/S的浏览器方式还是基于传统的windows窗口程序（客户应用程序）？

  The choices of user interface range from a simple Web browser to a custom client program.

• Where are the users located?  用户分布在哪里？用户的分布决定了网络的延迟处理设计。同时也影响一天业务高峰区间，影响批量或维护时间的确定。

  The distance between users influences how the application is engineered to cope with network latencies. The location also affects which times of the day are busy, when it is impossible to perform batch or system maintenance functions.

• What is the network speed?  网络的速度？速度决定了传输的方式。高度灵敏的用户接口可以应对任何的冲击；否则就需要发送等待模型处理。在慢网络中不可能去实现大数据传输的同时满足客户的通讯体验。

  Network speed affects the amount of data and the conversational nature of the user interface with the application and database servers. A highly conversational user interface can communicate with back-end servers on every key stroke or field level validation. A less conversational interface works on a screen-sent and a screen-received model. On a slow network, it is impossible to achieve high data entry speeds with a highly conversational user interface.

• How much data will the user access, and how much of that data is largely read only?  需要处理多少用户数据，多少数据是只读的？查询的方式会很大的影响系统的设计，包括表创建方式及索引的创建。必须要确保数据库的响应时间不是一个问题。假如系统主要是读取一些数据的话，那么将数据缓存到应用程序服务端就是一个好的方案。这也减少了核心事务处理的压力。（我们在设计系统时，这方面很多时候处理的相对是过度的，也就是说都尽可能的去缓存，要么缓存到共享内存中，或者自己的进程内，尽可能地去麻烦数据库，因为数据库是要处理多用户多并发的，因此实现一个单用户多并发是效率非常高的。由于现在数据库服务器性能越来越强劲，所以有些系统又把这些缓存放回到数据库端，不再做这些功能的编写。当然oracle是建议我们这么做的）

  The amount of data queried online influences all aspects of the design, from table and index design to the presentation layers. Design efforts must ensure that user response time is not a function of the size of the database. If the application is largely read only, then replication and data distribution to local caches in the application servers become a viable option. This also reduces workload on the core transactional server.

• What is the user response time requirement?                                                         需要提供的一个用户响应时间是多少？

  Consideration of the user type is important. If the user is an executive who requires accurate information to make split second decisions, then user response time cannot be compromised. Other types of users, such as users performing data entry activities, might not need such a high level of performance.  不同用户需求是不一样的。如果一个公司高官，他需要一个准确的信息以制定计划，那么就不能以提供响应时间上的妥协。另外一些用户，例如主要做一些数据的录入工作，那就不需要太高的性能。

• Do users expect 24 hour service?                                                                          是否需要7*24小时的服务？

  This is mandatory for today's Internet applications where trade is conducted 24 hours a day. However, corporate systems that run in a single time zone might be able to tolerate after-hours downtime. You can use this after-hours downtime to run batch processes or to perform system administration. In this case, it might be more economic not to run a fully-available system.

• Must all changes be made in real time?                                                                   是否需要实时的处理？

  It is important to determine whether transactions must be executed within the user response time, or if they can be queued for asynchronous execution.

简单概括一下就是设计时考虑一下：系统有多少人会访问，以什么方式访问，对网络要求有多高， 一天的交易量大概有多少，TPS要求多高，系统是否需要7*24时运行。

The following are secondary questions, which can also influence the design, but really have more impact on budget and ease of implementation. For example:

下面的一些问题是次要的问题，它也一样决定了如何去设计，但是主要是项目预算及简易实现方面的。例如：

• How big will the database be?                                                    需要多大的数据库？

  This influences the sizing of the database server. On servers with a very large database, it might be necessary to have a bigger computer than dictated by the workload. This is because the administration overhead with large databases is largely a function of the database size. As tables and indexes grow, it takes proportionately more CPUs to allow table reorganizations and index builds to complete in an acceptable time limit.

• What is the required throughput of business transactions?          业务处理的最大吞吐量是多少？

• What are the availability requirements?                                       可靠性要求是什么？ （是否要做DG）

• Do skills exist to build and administer this application?                  开发人员的能力是否能够满足目前的项目开发？（银行里很多是由刚毕业的大学生做的）

• What compromises are forced by budget constraints?                  在项目预算是有多少可以协商的余地？（一般没得商量）

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/1696240/viewspace-1166544/，如需转载，请注明出处，否则将追究法律责任。