很多人都试图给"架构"下定义，而这些定义本身却很难统一。能够统一的内容有2点：一点是“最高层次的系统分解”，另一点是“系统中不易改变的决定”。但是，表述一个系统架构的方法不只一种。
架构是一种主观上的东西，是专家级开发人员对系统设计的一些可共享的理解。一般地，这种可共享的理解表现为系统中主要的组成部分以及这些组成部分之间的关系。它还包括一些决定，开发者们希望这些决定能及早做出，因为在开发者看来，它们是难以改变的。
架构实际上就是如何将企业应用组织成不同的层次，以及这些层次之间如何协同工作。大多数重要的企业应用都是按照某种形式的层次分层设计的。
主要解决高并发，海量数据，复杂业务逻辑
在我们讨论如何设计企业应用以及使用哪些模式之前，明确这样一个观点是非常重要的，即企业应用是多种多样的，不同的问题将导致不同的处理方法。如果有人说，“总是这样做的时候”，就应当敲响警钟了。我认为，设计中最具挑战性的地方就是了解有哪些设计方法以及各种不同设计方法之间的优劣比较。
***响应时间***是系统完成一次外部请求处理所需的时间。
***吞吐率***是给定时间内能够处理多大的请求量。对于企业应用来说，吞吐率通常用每秒事务数（TPS）来度量。
当通过某种技术优化后，使得系统的吞吐率提高了，但是响应时间下降了，这时就不好说系统的性能提升了，最好用更准确的术语表示。
***负载***是关于当前系统负荷的表述，也许可以用当前有多少用户与系统相连来表示。负载有时也作为其他指标（如响应时间）的背景。因此，我们可以说，在10个用户的情况下，请求响应时间是0.5秒，在20个用户的情况下，请求响应时间是2秒。
负载敏感度***是指响应时间随负载变化的程度。假设：系统A在10~20个用户的情况下，请求响应时间都是0.5秒，系统B在10个用户的情况下，请求响应时间是0.2秒，在20个用户的情况下，请求时间上升到2秒。此时，系统A的负载敏感度比系统B低；我们还可以使用术语***衰减（degradation）,称系统B衰减的比系统A快。
***效率***是性能除以资源。如果一个双CPU系统的性能是30TPS，另一个系统有4个同样的CPU，性能是40TPS，则前者效率高于后者。
系统的***容量***是指最大有效负载或吞吐率的指标。它可以是一个绝对最大值或性能衰减至低于一个可接受的阈值之前的临界点。
***可伸缩性***度量的是向系统中增加资源（通常是硬件）对系统性能的影响。一个可伸缩的系统允许在增加了硬件后，能够有性能上的合理提高。例如，为了使吞吐率提高一倍，要增加多少服务器等。垂直可伸缩性称为垂直扩展，通常是提高单个服务器的性能，例如增加内容。水平伸缩称为水平扩展，通常只增加服务器数目。
当构建企业应用系统时，关注硬件的可伸缩性往往比关注容量和效率更重要。如果需要，可伸缩性可以给与你获得更好的性能，可伸缩性也可以更容易实现。有时，设计人员费了九牛二虎之力才提高了少许容量，其开销不如多买一些硬件。同样，增加更多的服务器也比增加更多的程序员来的便宜———只要你的系统有足够的可伸缩性。
模式
每一个模式描述了一个在我们周围不断重复发生的问题以及该问题解决方案的的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。