《酷壳博主陈皓:高并发互联网应用性能优化实践》读后感
酷壳博主、亚马逊高级研发经理陈皓,作了《高并发互联网应用性能优化实践》,演讲中提出一个新的观点——节省资源,少用资源,你的程序可能会跑得更快。还解析扩展的三个方向和程序性能等精彩观点。
扩展性总结出三点:
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展示在用户面前。