酷壳博主、亚马逊高级研发经理陈皓，作了《高并发互联网应用性能优化实践》，演讲中提出一个新的观点——节省资源，少用资源，你的程序可能会跑得更快。还解析扩展的三个方向和程序性能等精彩观点。
扩展性总结出三点：
X轴扩展，分布式、负载均衡、数据冗余/分区。
Y轴扩展，业务异步、业务模式扩展，消息队列、缓存技术，像一个客服中心，Y轴扩展像一个生产线，因为像亚马逊把书卖好，然后我去卖电视，所有的业务系统包括我的团队全部到那边去，然后改版面，很可能这种一样。所以的软件设计一定要想着扩展性。
Z轴扩展，业务模式扩展。
其中，可以解决网站高并发访问的架构模式就是分层结构，下面从概念以及应用等方面，较为详细的的阐述分层模式设计概念。
一、分层架构概念
分层架构是大多数Jave EE应用的实际标准，因此很多的架构师，设计师，还有程序员都知道它。许多传统IT公司的组织架构和分层模式十分的相似。所以它很自然的成为大多数应用的架构模式。
二、分层架构模式分析
分层架构模式里的组件被分成几个平行的层次，每一层都代表了应用的一个功能(展示逻辑或者业务逻辑)。尽管分层架构没有规定自身要分成几层几种，大多数的结构都分成四个层次:展示层，业务层，持久层，和数据库层。有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。
分层架构中的每一层都有着特定的角色和职能。
分层架构的一个突出特性是组件间关注点分离 (separation of concerns)。一个层中的组件只会处理本层的逻辑。比如说，展示层的组件只会处理展示逻辑，业务层中的组件只会去处理业务逻辑。多亏了组件分离，让我们更容易构造有效的角色和强力的模型。这样应用变的更好开发，测试，管理和维护。
三、分层架构关键概念之层隔离
这是分层架构中非常重要的特点。这意味request必须一层一层的传递。举个例子，从展示层传递来的请求首先会传递到业务层，然后传递到持久层，最后才传递到数据层。
层隔离就是说架构中的某一层的改变不会影响到其他层:这些变化的影响范围限于当前层次。如果展示层能够直接访问持久层了，假如持久层中的SQL变化了，这对业务层和展示层都有一定的影响。这只会让应用变得紧耦合，组件之间互相依赖。这种架构会非常的难以维护。
四、分层架构设计原则
1、层意味着组建的逻辑分组。例如，对用户界面，业务逻辑和数据访问组建应该使用不同的不同的层。
2、在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作，而不是提供其他操作。
3、在设计的每一个层接口时要考虑好物理边界。如果通信扩展了物理边界，使用基于消息操作；否则使用基于对象操作。
4、考虑使用接口类型（interface）来定义每层的接口。这将允许你创建该接口的不同实现，提高可测性。
5、对于Web应用程序，在表示层和业务逻辑层之间实现基于消息的接口是一个好主意，即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。
五、分层架构应用实例
为了演示分层架构是如何工作的，想象一个场景，如图，用户发出了一个请求要获得客户的信息。黑色的箭头是从数据库中获得用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成（客户下的订单）。其中，Presentation 层代表了代码中的jsp界面层；Business 层代表代码中处理请求并返回结果的servlet层；Persistence持久层代表代码中的dao层；Database数据层代表了代码中的sql语句。
用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate）模块。这个模块能找到业务层里对应的模块处理对应数据（约束关系）。业务层里的customer object聚合了业务请求需要的所有信息（在这个例子里获取客户信息）。这个模块调用持久层中的custom dao来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层当customer object收到数据以后，它就会聚合这些数据然后传递给customer delegate，然后传递这些数据到customer screen展示在用户面前。