j2ee中解决基础服务层方案的实现

    基础服务层构建于J2EE平台之上，借助于中间件的接口服务，提供电子商务平台系统所需要的通用服务接口组件。系统将提供以下主要的服务接口支撑不同业务需求的实现。
    ◆ 栏目管理模块：
    栏目是一个抽象资源对象，是一种特殊的内容类型。栏目可以表示产品、新闻信息类别、资源节点、导航栏的项、菜单中的项等等。栏目是一种组织管理型的资源。
    系统设计上支持多级子栏目，采用虚拟文件系统（Virtual File System）技术以支持直观的树型导航风格，一个栏目节点相当于一个虚拟的文件目录。
    对于大型电子商务系统，栏目的节点是个非常大的数字，这对系统栏目树展示的速度和性能有极高要求。考虑到以上原因系统采取了栏目对象缓存策略，同时对于页面节点的呈现通过动态JavaScript输出的技术，从而使系统能很好的支持上万个栏目数据节点操作管理。能平滑、高效的展示树型风格的栏目结构。
    ◆ 用户权限管理模块：
    大型电子商务应用系统有用户多，模块多，权限多的特点，因此必须采用分组的用户管理系统，并设置一个具有最高权限的管理员，负责对整个系统用户设置，为每个用户角色、用户指定不同的权限，依照不同的权限在系统中可以使用不同的功能。
    系统设置了Administrator用户组，并设置了root这个具有最高权限、不可删除的用户。您可以根据您的需要使用root这一个管理员用户。管理员可以创建、编辑和删除用户组，您可以根据您的需要给每个用户组合理的权限划分，并给每个用户组添加、编辑和删除用户。用户登录系统后，系统会根据该用户的权限提供相应的功能，并对用户的每个操作检查用户的使用权限。
    系统采用Window用户权限的思想，将用户、用户组的权限通过各个栏目节点进行绑定，在各个栏目节点上实现继承与非继承的设置管理，从而使管理员可以进行灵活的配置。

    ◆ 属性管理模块：
    在现实情况中，不同的事物对象存在其特殊的信息描述；比如一个手机，存在 “网络类型—GSM”、“外观样式—翻盖”等等；同时这些特殊的信息描述在同类别的数据对象下经常存在共性；比如TCL和 联想 生产的手机，应该都存在以上两种属性的描述。
    针对以上的情况，系统进行了一个数据抽象，定义了一套属性管理组件，可以方便、有效的描述相关的需求情况，同时对于存在共性描述的对象采用继承模式来描述，从而很好的表现一个事物对象的特征。

    ◆ 继承性管理模块：
    继承是面向对象接口特性之一。考虑到抽象事物的通用性，系统通过一个通用的对象继承模型接口，对所有需要实现继承的功能提供基础的支持。从而提高系统的重用性和降低系统的偶合度。

    ◆ 日志服务管理模块：
    日志是一个成熟的电子商务应用系统所必备的功能。日志可以用于数据统计，为系统其他功能提供初始数据；用于查看一个对象的修改历史记录，用于方便追踪对象的修改状态和明确事务责任。
    通过对系统各种操作数据的分析，根据各操作功能，系统将日志进行类别的划分：
    1、系统日志：记录系统各种操作的信息数据。（比如：用户某个时间登陆了系统……）
    2、商品日志：记录系统商品数据发生改变的信息。（比如：商品价格发生变化）
    3、信息日志：记录系统信息数据发生改变的信息。（比如：某管理员增加了一个新的促销公告……）
    4、订单日志：记录系统订单数据发生改变的信息。（比如：某个订单已经进行了送货处理……）
    系统通过抽象出一个Log日志接口，采用Abstract Factory 模式，通过不同的构造参数来获取不同分类的Log日志实现。系统将各中类别下的日志，又区分不同的操作。日志组件将通过抽象和封装后，给各功能模块提供统一接口服务，方便系统各模块的日志功能的开发和维护。

    ◆ 缓存服务管理模块：
    页面访问的时候，生成动态 Web 页会耗用各种各样的系统资源。当 Web 服务器收到页面请求时，它通常必须从数据库或其他存储系统中实时的检索所请求的信息。对这些资源的访问通常需要通过有限的资源池（如数据库连接、套接字或文件描述符）进行。因为 Web 服务器通常需要处理很多并发请求，所以对这些共享资源的争夺可能会延迟页面请求，直到资源变为可用。在将请求发送后，仍然必须将结果转换为 HTML 代码以便进行显示。
    使系统速度更快的一种显而易见的方法是购买更多、配置更好的硬件。此方法可能很吸引人，因为硬件便宜，而且不必更改程序，但更多的硬件只能在未达到其物理限制之前才会对性能有所帮助。系统中实施缓存管理，是一个有效的解决方案。
    系统中存在两中缓存对象：
    1、 Java对象缓存：对于一些经常被使用的Java对象保存于规定的内存空间，通过配置的更新规则，同步更新数据库内容。
    2、 前台页面缓存：对于前台的html页面按不同的块来区分，然后通过一个key对象，通过开源JCS技术存储于内存或磁盘空间。

   


    （请求中的页面对象不在缓存对象中）



   

    （请求中的页面对象存在于缓存对象中）

    从上边两幅图可以很清晰的看到，对于并发访问的页面请求，通过页面的缓存可以极大的减少对紧缺资源（数据库连接）的调用，减少访问响应的时间，从而提高系统的访问速度和整体性能。

    ◆ 集群模块：
    集群目标：
    1、 支持更大的访问量，并且可以随着访问量的增加可以通过增加服务器的方式很容易的增加处理能力，而不增加用户的访问时延。
    2、 提高系统稳定性，提供几乎永不停机的服务质量。即使某一台服务器软件或者硬件崩溃系统仍然能对客户提供服务。
    网客通平台集群实现了以下功能：
     1、Session复制
     使用应用服务器自带的Session复制功能。
     如开源的Tomcat，Tomcat5.5带有Session复制功能。Tomcat5.5的Session复制功能有如下的特点：
    1）需要保证Session中的所有的对象都是可序列化的。
    只有调用session的SetAttribute、removeAttribute方法时才会触发session的复制。例如有一个user类型的对象u保存在Session之中，如果u.setName(“aaa”)是不会触发Session复制的，只有u.setAttribute(“user”,u)才会触发Session的复制。
    2）Session的复制是一个all-all的复制，也就是说Session的每次复制都复制给集群中的每一台服务器。
    由于Session的复制是All-All的，因此当服务器中的集群数量过多时，有可能发生集群之间的Session复制流量过大，本身成为了性能的瓶颈。针对这个情况一方面要尽量的减少复制的数据量，这就要求将保留在session中的对象尽量变得更小，例如应该尽可能的拆分开对象。因为一个大对象只要一个小的属性发生了变化则整个对象都要被复制，如果将对象拆分开则只要复制一个小对象就可以了，尽量将保存在session中的对象变小。
    另一方面，当集群中的服务器数目真的变得很大时，单靠缩小session中的对象已经是没用了，这样的话我们还有两种技术方案：
    1）将集群分域，即将大的集群分成几个小的集群，Session复制只在小集群内部发生。
    2）主——从session复制，即将所有session 保留在中心的一台或几台服务器中，并不向集群中的所有服务器复制。

    2. Cache复制和更新
    网客通平台的Cache分成两类，页面Cache和对象Cache。页面Cache我们现在采用jcs包。Jcs包中带有Cluster功能，能够将Cache内容复制到整个集群的服务器中。该功能需要满足以下条件：
    1）需要保证Cache中的所有的对象都是可序列化的。
    2）只有调用Cache的setObject、removeObject方法时才会触发session的复制。
    事务型的cache
    在实际的使用中，Cache起到了巨大的作用，但是也存在有问题。Cache是非事务化的，即如果在使用过程中，在没有关闭Cache的情况下突然关闭服务器，或者服务器突然Down了，则缓存有可能被破坏。在集群环境下，则缓存会在服务器重起的时候从其他服务器中复制过来。
    在正常使用时 Cache能达到上 G的数量级，如果集群中某台服务器崩溃后损坏了Cache则在服务器重起的时候将有几G的数据需要复制过来，这样有可能造成网络诸塞，成为整个系统的性能瓶颈，因此我们采用事务型的 Cache，保证系统崩溃后，重起的时候只有少部分的数据需要从其他服务器上复制过来。
    对于cache的事务管理，我们采用Berkeley DB，Berkeley DB是历史悠久的嵌入式数据库系统，主要应用在UNIX/LINUX操作系统上，其设计思想是简单、小巧、可靠、高性能。当数据类型较少（特别注意：这并不是说需要管理的数据量小），数据管理本身不复杂，且对数据操作要求高效率时，使用Berkeley DB是一个很好的选择。Berkeley DB是一个具有工业强度的嵌入式数据库系统，数据处理的效率很高。Berkeley DB功能的稳定性历经时间的考验，在大量应用程序中使用便是明证。可以想见，在同等代码质量的条件下，软件的BUG数和代码的长度是成正比的，相对几十兆、几百兆大型数据库软件，Berkeley DB的只有不到500K的大小，但可以管理大至256T的数据量。从这些特性看来，cache非常适合使用Berkeley DB进行管理。

    3. 上传文件的共享
    我们采用共性文件形式的文件共享，主要使用磁盘阵列技术，简称RAID(Redundant Arrays of Inexpensive Disks)。磁盘阵列是由一个硬盘控制器来控制多个硬盘的相互连接，使多个硬盘的读写同步，减少错误，增加效率和可靠度的技术。
    磁盘阵列有以下优点：
    1）传输速率快；
    2）储存容量可提升；
    3）提升I/O每秒的数量；
    4）增加数据安全性及稳定性；
    5）大量数据快速及简易管理；
    6）增加可用运时间，减少维护；
    7）通过磁盘阵列，可以将不同服务器上传的文件统一管理。

    


    如图所示：各台服务器共享磁盘阵列，这样所有的上传的文档都放到磁盘阵列之中。

    4. Cookie的共享
    采用负载均衡器使得多台服务器对外有相同的IP这样就能使所与的服务器都能共享Cookie。同时采用这个方案还能保证系统的高可用性。具体可参照下一点。

    5. 高可用性
    我们建议采用负载平衡器，负载均衡器可以根据实际的响应时间制定优先级交付决策，从而实现高性能、智能化流量管理，达到最佳的服务器群性能。采用第七层应用控制还可以减少通信高峰期的错误讯息，因为差错控制和流量管理技术可以侦测到一些错误信息，并透明地将会话重定向到另一个服务器，使用户顺利地进行使用。例如，服务器A不可用或者数据库出现错误，错误信息将会返回到负载均衡器上，然后会将客户的访问指向服务器B或者将消息重放到其他数据库中去，整个过程对用户是透明的。
    将内部的多个私有ＩＰ的服务器，对外映射成一个相同的IP。而且当其中某台服务器Down掉的时候，负载均衡器将不会将这个服务器映射出去。



    
    6. 数据库集群
    如果数据库是用Oracle的话，数据库集群可以采用Oracle RAC。基于RAC的电子商务应用的用户或者中间层应用服务器客户，可以通过虚拟数据库服务名连接到数据库上。Oracle在集群中多个节点之间自动平衡用户负载。不同节点上的Real Application Clusters数据库实例预订所有数据库服务或者部分子集数据库服务。这使得DBA高度灵活地选定，连接到特定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点。RAC在工作期间，每个节点可以单独的被使用并且被应用程序负载均衡。如果发生意外，如一个节点的失败，可以实现节点的失败切换，保证数据库24*7的高可用性。
    虽然每一个节点有一个不同的物理IP地址时，应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。

    ◆ 任务调度模块：
    对于电子大型的成熟的电子商务平台系统，每天都有很多特定的数据需要进行分析或处理（比如：每天都有大量的邮件需要发送）。对于大数据量、高数据运算的处理功能，往往不希望在系统繁忙的时间进行处理。
    针对这种状况，系统采用Jcrontab提供的基础服务，通过Jcrontab接口的扩展，实现对系统自动执行的任务灵活的、人性化的配置。管理员可以根据系统的实际情况，配置相应的系统任务来执行。