某工业企业公共服务平台架构设计

平台背景

XXXXXXXX平台需依托现有 IT系统及未来信息系统建设的要求，规划部署公共服务及基础计算资源，要求对现有业务系统平台进行全面的统一规划和翔实的梳理，建立高可用性、高性能的业务服务载体，提供不间断的业务统筹水平和实施监管能力，符合现代 IT 建设运维要求。

系统多样化，采用技术平台也有其多样性，既有集中控管的业务系统，也有分布式运营的生产系统，从技术层面来看，存在多种异构应用服务，异构数据平台等多种计算资源。硬件层面涵盖了多中操作系统及主机环境的服务器和存储系统，网络交换及路由分布涉及到多种网络设备及核心汇聚。

新的公共服务平台应该是一个具备高可用性的业务环境，这种高可用表现在业务运行的高可用性，而非单一的数据库层面或服务器系统的高可用性。

新的公共服务平台应该是一个具备高性能的业务环境，这种高性能不但体现在业务响应时间和业务处理的速度，还体现在对业务并发控制及数据吞吐量的性能保障。

新的公共服务平台应该是一个具备松耦合架构的可扩展的技术平台，该平台可以提供统一的标准来保障异构系统的读取接口和其他业务横联及流程系统所需的开放协议，此架构易于实现，原有业务系统改造可在此架构上实现平滑的重构，降低系统迁移的风险。

新的公共服务平台应该是一个安全的、易于管理的、符合ITIL 运维建设思路的服务管理平台。

总体思路

基于以上背景和技术要求，架构设计的总体思路如下：

由于这是一个新建系统且必须严格的考量其业务的高可用性、高性能，因此从设计之初务必考虑其系统载体所提供的服务类型及特征，比如此公共服务平台上运行的系统属于哪种性质的 IT系统，是计算密集型还是服务流转型，是高集中高频率的数据处理吞吐型还是并发访问控制型，是计算资源安全重于效率型还是为保证效率平衡系统瓶颈型，是总线服务入网即用的 ESB 类型还是面向服务流程保证高度统一的 SOA 类型，是分布式集中控管的私有云类型还是多层次的集中服务分发类型。根据这些我们有必要编制一个企业 IT 业务系统调查表并请用户方及系统实施方配合填写。

当我们确认了系统类型后，结合业务情况，比如考虑应用吞吐量、分发HTTP 请求数量、 session 持久性、数据处理形式（逻辑读写、查询）等确认系统的初始架构，并以业务系统数据流为轴线，划分每一个层次的架构分布，结合容量管理充分考虑硬件及服务器存储数量和负载均衡的模式。

涉及到数据库层面的东西我们还是要结合业务的特征，来确认在保证高可用、高性能的条件下，如何进行数据库的环境架构设计，是使用多库横联形成DW 便于使用 cube 查询并将其用于 BI 等业务，还是使用多实例同步方式保证性能和高可用，还是使用单实例多节点方式来保证性能，以上方式各有适合的方面，需要我们审时度势来分别考量。

技术架构思路

本小节旨在描述技术架构，不涉及任何厂商产品配置，您可以使用任何厂商的产品来配置此技术架构的搭建。本技术架构适用用于目前的主流厂商和开源厂商产品。并已经过实际项目的论证。

业务的高可用性这一点上，我们以 2点设计来实现这个要求。

1、 我们将数据流向作为轴线，划分了几个层次，对每个层次中的应用服务提供HA/LB 的集群设计，用以避免单服务的单点故障，并在集群设计的时候考虑故障切换和负载均衡的设计属性，包括链接上级服务和下级服务的链路均衡并采用适合的链接方式，如采用 JDBC/OCI POOL 方式及含有 LB/HA 特性的连接字符串 XE 的驱动模式。

2、 我们从整个系统来看，对于业务流程，如HTTP 分发过程中，静态页面及 J2EE MDB 的 SESSION 会话、 Spring Framework 中涉及到的数据持久化设计中对于 HTTP 会话性能和应用服务器处理时的路由过程是不一样的，在前端页面中及时采用了 JSON 或其他 AJAX 方式的页面对于 webcache 的处理产生了业务响应速度的不同影响，因此在整个横向的轴线上，我们有必要对进入 HTTP 服务的数据进行 cache 的缓存设计，用以保证 HTTP 的高可用。对于应用服务层面，如何涉及到异步数据传输的层面的东西，为了考虑更好的可用性和可靠性，必要将 JMS 服务作单独的冗余设计，同理，如果业务系统中发现应用服务中涉及到的流程 BPEL 的服务占有率很高，那么单一的设计应用服务器的冗余和负载均衡已经无法解决业务流程上的可靠性了，那么有必要对流程曾面上的 BPEL 的处理进行冗余设计了，再进一步来看，如果这些应用层面的服务还涉及到了流程集成和页面集成是否还需要对异步响应发布订阅、页面集成等技术要点进行冗余设计都值得大家考虑。

业务的高性能这一点，首先不能为了性能而设计性能拓扑。这一点对于复杂系统设计来说不具备好的耦合度，很容易和可用性设计产生重复投资。架构产生冗余。因此最好的性能设计在设计高可用的时候架构已经考虑了性能的规划，如缓存服务的设计，集群设计等。

松耦合和高度开放的可扩展性是以架构设计之初就需要拿捏的，松耦合需要进行设计上的迭代和测试，优化才能满足。实践是检验耦合度的唯一标准，再次不作赘述。可扩展性这一点对于不符合标准规范的私有协议，我们设计的时候一概不采用，不考虑，必要有开源组件的兼容和替换使用，其次使用有标准支持规范的设计模式，最后使用具备API 接口调用的架构组件。以上三点保障可扩展性的成功实施。

易于管理监控维护是架构设计的必备考虑，标准化后的组件、流程、服务均有对应的管理方法、工具来维护，因此松耦合可扩展成为了易于管理维护的基础。

 

以上架构图是一个典型的应用数据流的系统流程图，我们可以看到这些标注了数字的部分所需的高可用性方式，一般来说我们可以从技术上考虑以下 cluster模式：

  第一种模式（如图左所示）也称为 “ 青铜拓扑 ” 。 这种模式包含一个应用程序服务器集群，其中，形成系统集成总线（ SIBus ）的  WebSphere Process Server  业务应用程序、 CEI  和  BPC Explorer  等支持应用程序、以及托管消息传递引擎（ ME ）的消息传递基础设施全部驻留在构成集群的每个应用程序服务器中。

青铜拓扑适合这样的解决方案：只包含同步 web  服务和同步  SCA  调用，最好只有短期运行流。

第二种模式（如图中所示）也称为 “ 白银拓扑 ” 。这种模式拥有两个集群：第一个集群包含  WebSphere Process Server  业务应用程序和支持应用程序，第二个集群包含消息传递基础设施。

白银拓扑适合这样的解决方案：使用长期运行流程，但不需要 CEI 、消息排序、异步延迟响应、 JMS  或  MQ  绑定、以及消息排序机制。

第三种模式（如图右所示）也称为 “ 黄金拓扑 ” 。与前面的模式不同，支持应用程序被分隔到第三个集群中。

黄金拓扑适合其余的所有情况，其中，异步处理在解决方案中发挥举足轻重的作用。这种拓扑还为应该在这种环境中运行的业务流程应用程序提供大部分 JVM  空间。如果可用硬件资源允许设置一个黄金拓扑，建议使用这种拓扑模式从头开始，因为它是用途最广的拓扑。

构建 cache服务非常有必要，有效的网络 Cache 系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若 Cache 服务器超载而不能及时地处理请求，反而会增加响应延时。所以， Cache 服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高 Cache 服务的处理能力。尤其，在主干上的 Cache 服务可能需要几个 Gbps 的吞吐率，单台服务器（如 SUN 目前最高端的 Enterprise 10000 服务器）远不能达到这个吞吐率。可见，通过 PC 服务器集群实现可伸缩 Cache 服务是很有效的方法，也是性能价格比最高的方法。 基于LVS 可伸缩 Cache 集群的体系结构如图 2.3 所示：在前端是一个负载调度器，一般采用 IP 负载均衡技术来获得整个系统的高吞吐率；在第二层是  Cache 服务器池，一般 Cache 服务器放置在接近主干 Internet 连接处，它们可以分布在不同的网络中。调度器可以有多个，放在离客户接近的地 方，可实现透明的 Cache 服务。

 

Cache服务器采用本地硬盘来存储可缓存的对象，因为存储可缓存的对象是写操作，且占有一定的比例，通过本地硬盘可以提高 I/O 的访问速度。 Cache  服务器间有专用的多播通道，通过 ICP 协议（ Internet Cache Protocol ）来交互信息。当一台 Cache 服务器在本地硬盘中未命中当前请求时，它可以通过 ICP 查询其他 Cache 服务器是否有请求对象的副本，若存在，则从邻近的 Cache 服务器取该对象的副本，这样可以进一步提高 Cache 服务的命中率。

对于是否有必要对于系统采用 SOA化，我们首先来归纳一下目前的 SOA 优点、缺点，如下表：

表 1.  优点、缺点、糟糕之处
 

SOA 的良好业务影响	SOA 的不良业务影响	SOA 糟糕的业务影响
敏捷性- SOA  支持更加快速地开发业务流程以及更加轻松地对业务流程进行改变。它可以使组织更迅速地适应他们业务环境的改变。这就转化成为实际的市场优势，因为它能够使产品和服务比竞争对手更快速地推向市场。	组织结构的改变-  在每个  SOA  的中心都有一个卓越中心（ COE ）。 COE  就是一个控制  SOA  技术开发以及向组织的其他人员提供专业知识的新实体。 SOA COE  是对任何组织来说都是新增加的，并且由此推出，当它实力雄厚并且在这里所做的决定会影响组织的其他人员时，它的引入可能会导致冲突。	转变并不容易-  转化和组织成为以服务为中心并不容易。过渡到  SOA  的特点是演变而不是革命。以孤岛的传统形式创建的组织需要改变它们的结构，以充分利用成为以服务为中心的优势。这种转变是复杂的、昂贵的，而且从来不缺少这种变革的反对者。
一致性-  业务与  IT  之间更加紧密的合作关系抛开了阻碍  IT  实现业务需求的传统障碍。业务领域中的服务足迹是一项业务功能，并且用业务术语对其进行了描述。它实现的细节是隐藏的。	组织权力结构的改变将服务的所有权和控制权放到业务领域中，会改变组织中的权力结构。这样做通常会遭遇来自那些有维持现状特权的人的阻力。	文化改变- SOA  不仅仅代表着技术的改变。伴随着这种改革产生了一个组织的文化变革，因为它成为了价值的驱动。组织必须明白敏捷意味着什么以及如何充分开发其自身的敏捷性。糟糕的事实是，这是最难学习的课程之一。
业务流程的改进-  一般而言，任何  SOA  与业务流程的再次思考都是相关的。这种业务流程重构对优化组织运营业务的方式而言是一次机会。良好的重构工作能够使业务的运营效率得到显著提高。	业务面临的新挑战-  业务必须给予  IT  更多的指导。业务线必须对服务及增强行使所有权并对其负责，从而启动开发与变化周期，因为它们将推动这一进程。这不是一种典型的由业务线进行补充的作用，这将会导致不合适的改变。
灵活性-  在  SOA  中坚持良好的软件工程实践能够提高  IT  对业务需求的响应。缩短了产品和服务的上市时间，降低了开发与改变流程的成本。	IT 在变得更简单之前会越来越复杂 -  利用一套如业务流程执行引擎和  ESB  的技术来实现  SOA 。把这种技术添加到  IT  规划中并不会让它更加简单，即使当它的优势远远超过了它的成本。然而， IT  规划更复杂并不意味着它就不能以更简单的形式出现。这种服务的推出让  IT  的复杂性成为秘密。这些服务的消费者不需要知道服务内部是如何运行的。结果，任何发生在后端的的合理化操作，都可以隐藏在服务界面之后。	技术本身不会体现价值-  专注于基础架构和技术的  SOA  是很可能失败的。 SOA  举措是建立在比以往更快速更低成本地提供业务价值的承诺之上的。一种过于重视技术的  SOA  是不可能实现该承诺的，因为它们不会显示出业务人员希望看到的价值。灵活性只有在加速运营性业务需求，或者通过支持业务的合理性来降低操作系统成本时才会 被认为是业务价值。以技术为中心的举措一般不会这样做。
数据统一-  服务接口可提供统一数据特征的机会，以使服务接口使用遵照统一的数据模型的数据。统一在这里的意思是通用：  结构 -  元素之间的结构关系是相同的，因此例如地址一贯地包含门牌号、街道、城市、地区和邮政编码。 语义 -  语义是指含义以及数据的使用。数据必须有统一的含义，并且必须以不会产生歧义的方式使用。例如客户的概念可能会在网站上遇到，与帐户所有者形成对比。 格式 -  数据的表现方式很重要。 DDMMYYYY  格式的日期不能与  MMDDYYYY  格式混淆。 类型 -  类型是由数据的表现形式以及一套可以执行的行为决定的。 时间 -  时间指的是属性更新的时候。在某些情况下属性会在前端系统进行实时更新。然而一些属性只在定期的批处理时进行更新。 生命周期 -  在什么情况下将数据添加到数据库中，什么时候进行更新，以及什么时候、以什么方式最终从数据库中删除数据。	没有数据视图-  服务的标准接口需要统一的数据视图。这种统一视图通常不存在，并且设法开发统一视图时往往会发现组织中的视图非常不同。	可能无法实现统一-  使数据的所有特点一致几乎不太可能实现。除了上述问题之外，与  “ 脏数据 ”  相关的问题也总是存在。处理一致性是设计服务接口面临的巨大挑战之一。尴尬的事实是建立统一的服务接口是一件非常困难的事情。
运行监控-  用于支持  SOA  的技术和原理使对业务流程的监控更加轻松。这种监控类型支持来自日常运行的反馈。该反馈可用来衡量组织对其战略目标的实现情况如何。  传统的业务流程（BP ）与表现逻辑都写入了包含业务逻辑的相同程序。所能希望的最好结果就是至少将不同逻辑类型组合在一起，但是即使这一点也往往难以实现，其结果是很难监控逻辑范畴。例如业务流程只能作为应用程序的一部分来监控，因为它不能被分离出来。 SOA 通常伴随着业务流程执行引擎。这种技术的引入可促进业务流程逻辑被分配到一个点上。在一个点上拥有  BP  使  BP  监控成为可能，而无需在应用逻辑中使用  BP  逻辑。这不是  SOA  的专有技术，但是用于支持  SOA  与来自  SOA  良好软件工程实践规则的技术能够使该技术在  SOA  中更加轻松地得以实现。	监控复杂性-  开发一个针对组织目标提供反馈的业务流程监控模型是一项需要专业技能的重要工作。
利用操作平台- SOA  使用操作平台为服务提供业务功能。这意味着对现有系统的投资可通过将其重新包装到服务中来使用。	技术不匹配-  在某些情况下并不能轻松地对操作平台进行重新打包，原因是业务功能结构与需求不匹配。例如，如果一个添加新客户的事务在姓名和地址添加到客户数据库之后有一个提交点，并且在安全数据被添加之后有第二个提交点，那么这两种操作将紧密链接。	可能需要做出改变-  在某些情况下可能需要改变操作平台。当需要在  ERP  中作出改变时，供应商非常不情愿做出改变。如果组织决定在内部作出变革，服务资金必须考虑维护成本。

那么我们的系统是不是一个适合做成 ESB企业服务总线形式的系统架构呢？回答是否定的。 ESB 有时被描述为 分布式 基础架构，这与其他的解决方案形成了对比，比如消息代理技术一般被 描述为 中心辐射型（hub-and-spoke） 。然而，这并 不是真正的差别。正在研究两个不同的问题： 控制的集中 和 基础架构的分布 。ESB  和中心辐射型（ hub-and-spoke ）解决方案都集中控制配置，比如服务交互的路由、服务命名等等。同样，这两个解决方案可能部署在简单的集中式基础架构中，也可能采用更复杂的分布式方式进行部署。毫无疑问，不同的技术对它们所支持的物理部署模式有不同的约束 —— 有些可能适合于非常广泛的分布，以支持在很大的地理范围内进行的集成，而其他的可 能更适合于部署在本地群集中，以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是  ESB  设计的一个重要方面。另外的一种能力也是非常重要的，就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。 如下图： 分布式 ESB  基础架构的集中控制
 

产品架构思路

基于上的思路，我们按照以下关键字来定义我们的产品架构设计：

产品架构

下图是符合我们的业务系统架构需求的一个产品架构图，该架构图采用的的 Oracle产品线，当然，开源和 IBM 厂商也可以提供此架构的产品，而且性能和价格会更便宜些。我来解释一下这个图：

 

自顶向下来看，我们防火墙以下首先 web请求需要通过负载均衡设备，此设备可以是硬件的 F5 等设备也可以是例如 IBM 产品中的 websphere edge server 服务，可以将此服务配置成为 HA 模式，第一条虚线表示此层次的 web 负载分发已经完成并很高效了，第二层，这里使用的是 10.1.2 版本的 Oracle web cache ，这就是缓存的作用，在 Websphere 中也有此产品，使用 HA 设计，第二条虚线表示此层将 HTTP 会话进行了分类和静态缓存，提升了性能和高可用，到了第三层， HTTP SERVER ，这里对应 IBM  的 HTTP SERVER ，提供静态页面解析，缓解应用服务器的压力，并提供反向代理的负载均衡。如果涉及到 OCI 和 proxy 方式的数据库操作，实时性高以及管理维护的需求，包括业务中涉及到数据库的事务 / 回滚段可以 PLSQL 直接操作数据库，否则就将请求交给对应的 servlet 交给相应的 javabean 去出去，这些 bean 可以去进行数据库读写，那么就走 jdbc/jdo 的路径去 oracle rac ，可以去关联某个流程 BPEL 处理 BPLM 的数据，那么就走 process server 去走流程，当然这里的 process server 也可以根据情况设计成 HA 方式，可以去关联某个异步文件传输同步服务，那么就可以管理 JMS 组件，如 MQ 服务，涉及到订阅和发布的就设计为 MESSAGE BROKEN 。应用服务出口可以有安全审计模块，对应 IBM TAM ， SSO 等组件，无此安全要求的可以去找 DB ，这里的 DB 可以设计为单实例多节点的 ORACLE RAC 形式。如果涉及到多个 RAC 形式可以考虑使用 gird 做，那就是管理层面的问题了。

缓存

大型互联网应用，例如门户网站、在线商城以及联机交易系统等等，往往需要处理大批量、高并发的用户访问请求，这对应用程序的性能提出了比较高 的要求。性能问题一般可以在开发和部署两个阶段加以解决。在应用部署阶段，通过增加软硬件投入的方式比较常见，但其费用往往较高；而在软件开发阶段如果能 够提前定位并解决性能瓶颈，则会减少大量成本。在开发阶段提升性能，一种常用的思路是降低瓶颈资源、业务模块的访问压力，因而在应用程序中加入缓存机制则 因成本低、实现方便等优点成为常见解决方案。

缓存（Cache ）在计算机科学领域指的是一些数据副本的集合。当原始数据访问速度较慢或代价过高时，可以通过使用在高速存储区域中保存原始 数据的常用数据副本，从而提升访问速度。常见的硬盘缓存， CPU  缓存，网页缓存等等都是缓存概念的应用。在企业应用开发时，开发人员也可以基于缓存的概念，使用应用程序级别的缓存，从而来提升应用性能。

常见的开发方式为在 Java  虚拟机里通过  Static  成员变量、 Context  对象或者用户  Session  中，保存常用的业务数据。一旦有访问需求，则先从缓存中尝试获取数据，如果尝试失败，再从实际模块获取数据并更新缓存。

此类方法实现简单，但容易遇到扩展性方面的问题：为了满足业务增长需求，用户可能需要在  多台  主机组成的  集群  中部署应用。此时 JVM  级的缓存会面临服务器间缓存同步的问题，处理不好，会导致数据不一致等严重错误。其他可能的问题还有：

·  应用开发模式的改变：应用程序需要在相关业务处理逻辑处加入缓存相关处理。

·  配置管理：需要在缓存的有效期、大小等方面，如果要求可配置，则需要开发人员一定的工作量来满足此类需求。

针对这些常见问题，IBM WebSphere Application Server  则提供了一套动态缓存框架，能从不同方面加以解决。

IBM WebSphere Application Server 动态缓存机制介绍

动态缓存机制是 WebSphere Application Server  为应用程序开发人员提供的一套扩展服务，其主要功能组件如下图所示：

WebSphere Application Server 动态缓存的主要功能组件
    动态缓存机制架构如上图所示。动态缓存机制的核心功能为：在内存中缓存 Java  对象，应用程序可以通过  API  来访问这些对象。为了减少内存消耗，动态缓存服务也采用一些缓存替换机制（例如  LRU-  最近最少使用算法）来实现。对应不同的应用类型，动态缓存机制为应用开发人员提供了不同层面的缓存服务：展示层的  Portlet  和  Servlet  缓存服务和业务层的  WebService  缓存服务、 Java  命令缓存服务和对象缓存服务。

动态缓存服务部署示意图
 
为多服务器环境下动态缓存机制的部署示意图。应用程序只需通过 API  来调用缓存服务即可，动态缓存服务会 自动 在不同服务器之间根据定义好的策略进行缓存数据同步。当收到应用程序缓存访问请求时，缓存服务会首先在本地缓存中查找相应对象提供服务。一旦被请求的对象 位于其他服务器时，动态缓存服务会通过数据复制服务（Data Replication Service, DRS ），来从其他服务上获取相应数据。如果对象在本服务器上有改动，如缓存更新或者缓存删除，动态缓存服务也会通过数据复制服务通知其他服务器。

以下为不同种类动态缓存服务之间的功能比较 :

缓存服务功能比较及使用 ： 动态缓存服务模块功能比较
 

服务名称	应用范围	优点	缺点
Portlet 缓存	对 Portlet  的页面输出进行缓存	使用方便，仅需配置即可。	适用范围有限。
Servlet 缓存	对 Servlet/JSP  页面输出进行缓存，包括对  Struts  和  Tiles  标签的输出结果进行缓存。	使用方便，仅需配置即可。	适用范围有限。
Web Service 缓存	缓存 Web Service  的执行结果	使用方便，仅需配置即可。	适用范围有限。
命令缓存 （Command Cache ）	缓存某个 Java  类的方法的执行结果。	通过 API  访问，适用面广，配置简单。	需要修改编程模型，实现特殊的缓存接口，并需要一定的开发工作量。
对象缓存（Object Cache ）	缓存应用程序数据。	通过 API  访问，适用面广，使用方便。	需要一定的开发工作量。

如需使用 Portlet  和  Servlet  缓存，需要以下步骤

·  在 WebSphere Application Server  管理控制台中，启动动态缓存服务，并在  Web  或者  Portlet  容器配置界面中，启动相应缓存选项。

·  根据规范，完成缓存策略配置文件 cachespec.xml 。该文件中一般包含缓存  id 、要缓存的  Servlet url 、缓存有效时间等等内容。

在缓存策略配置文件中，以下一些高级属性也可以被使用：

·  缓存输入参数：如果某个 Servlet  的输出是由输入参数决定的（例如；查询汇率的  Servlet  输出，是由源币种、目标币种和时间三个参数决定），因此在获取缓存结果时，需要考虑当前的输入参数值。这些输入参数可以配置在策略配置文件中。

·  缓存失效条件：在某些场景下，缓存需要立刻失效。例如返回产品列表的 Servlet ，一旦用户在添加产品  Servlet  中作了某些操作，则需要缓存立刻失效。这些发出失效的动作，也可以配置在缓存配置文件中。

动态缓存应用场景分析

应用场景分析 1

需求 ：

某网上商店应用访问速度过慢，经过分析，是由于产品列表和购物车处理模块由于逻辑复杂，执行效率不高引起的。

解决方案：

在优化相应代码外，也可以利用动态缓存机制，缓存一些常用页面的输出。动态缓存机制能够自动根据配置缓存某些页面的输出结果，这样该页面在下次访问时，Web  容器可以直接返回页面输出结果，而不用再次执行相关业务逻辑。

需要注意的一点是，一些页面的输出内容跟当时的某些数据和环境信息相关，例如：http://www.shop.com/products.jsp?category=books  中， products.jsp  的输出就与  Category  参数决定。因此，在进行缓存定义时，需要将相应的参数作为缓存  key  定义的一部分。

除了请求参数外，WebSphere Application Server  动态缓存的  key  定义还支持将  request  对象的属性、相应页面路径、 Session  值、 Http Head  信息、 Locale  和  Cookie 。

应用场景分析 2

需求 ：

假设在集群环境下的企业应用中，存在一系列 XML  格式的元数据，数据量为  100  条左右。由于该数据经常被访问，项目组希望能够通过某种措施，减少数据访问和  XML  解析的开销，进而提高系统性能。而且一旦元数据被操作员修改（例如访问  http://www.app.com/changeMetadata.jsp ），缓存内容需要立即得到更新。

解决方案：

在这种需求下，一种简单的做法是使用 JVM  级  static  对象来做缓存，具体做法为：定义一个  static HashMap  对象，应用程序读取数据时，首先检查该  HashMap  中是否存在缓存，如果存在，则直接从缓存中读取。在这种情况下，一些相应的缓存控制机制也必须被实现，比如缓存大小的控制、缓存过期等等。在数据被修改 时，通过修改相应的代码（如在  changeMetadata.jsp ）来更新缓存内容。

这种做法的问题在于，在集群环境中，操作员实际的访问请求是被某一个 JVM  上部署的应用所服务的。当操作员更新数据时，相应的更新代码，只会更新当前  JVM  上的缓存内容，而不会通知其他服务器，这样会导致数据不同步现象。而实现该数据同步，可能需要应用程序人员基于网络接口，开发相应的通知功能。

而在 WebSphere Application Server  中，动态缓存服务已经支持数据复制的缓存服务，我们只需要调用相应接口即可。而由于不同层面的应用程序模块，如前台用户界面和后台业务逻辑都需要访问该元 数据，因此我们只能在动态缓存中的  Java  命令缓存和对象缓存中选择其一。鉴于应用中已经有类似的命令框架，因此无法简单的扩展该框架以使用  Java  命令缓存，因此对象缓存可以被用来解决此类问题。

集群环境下的动态缓存应用部署

将开发完成的应用部署到集群环境，一般有以下几步：

·  集群环境的安装和部署

·  创建复制域

·  启动动态缓存服务，并指定复制策略

·  安装应用

注意：  只有在 WebSphere Application Server Network Deployment  版本中才支持服务器间的缓存复制。

服务器间缓存复制策略分析

缓存复制策略有以下几种：

not-shared 不共享	缓存内容不与集群中其他服务器共享。在这种模式下，缓存的数据内容可以不实现序列化接口 java.io.Serializable 。
shared-push 共享  -  推	缓存中的数据在多台服务器之间共享，且每台服务器均存放一个复本。一旦缓存内容发生变化，会自动同步到其他服务器中。这种模式下，缓存中数据必须实现序列化接口 java.io.Serializable 。
shared-pull 共享  -  拉	缓存中的数据在多台服务器之间共享，任何一个被缓存对象在所有服务器中，存在且仅存在一份。当一个服务器读取缓存中数据时，会首先检查本地受否存在复本， 如果不存在，则会尝试从其他服务器缓存中读取该数据。如果该对象在所有服务其中都不存在，则该服务器会创建该对象。这种模式下，缓存中数据必须实现序列化 接口 java.io.Serializable 。该模式已  不建议使用 。
shared-push-pull 共享  -  推拉	缓存中的数据在多台服务器之间共享，任何一个被缓存对象在被创建时，会保存在本地服务器的动态缓存中，并且将缓存 id  广播到其他服务器中。一旦某个对象被请求，当前服务器会根据本地缓存信息和广播信息立刻得知被缓存对象的位置，从而完成读取工作。这种模式下，缓存中数据 必须实现序列化接口  java.io.Serializable 。

如果应用中要缓存的数据量比较小，则可以采取 shared-push  方式，以空间换取性能。假如被缓存的数据对象比较大，或者服务器内存比较紧张，我们则可以考虑采用  shared-push-pull  模式。

当我们 完成了基于对象缓存技术的应用部署步骤。我们也启动了缓存复制机制，使一台机器上的缓存改动，能够复制到所有其他机器上。

集群

在构建强大而灵活的可扩展 J2EE  应用程序时，您需要考虑一些相关因素。一个重要的注意事项是允许应用程序在集群环境中高效地运行。本文讨论了在  WebSphere Application Server  集群环境中设计基于  Web  的应用程序时需要考虑的事项。

WebSphere Application Server 集群机制允许将整个应用服务器（包括  EJB  容器、 EJB 、 Web  容器、 Web  模块和  Servlet ）作为一个集群进行复制。集群提供了工作负载管理以及  URL  和  EJB  请求故障转移。各个集群成员是该集群中完全相同的副本，它们可以运行于  WebSphere  单元中的节点。集群可以位于相同或不同的节点。 Network Deployment  单元可以不包含集群、或者包含多个集群，这取决于该单元的管理需求。有关  WebSphere Application Server  集群的信息，请参见  WebSphere Application Server  联机帮助。

集群拓扑有两种类型，垂直集群或水平集群。垂直集群在同一节点或物理计算机上具有多个集群成员。水平集群在计算单元中的很多计算机的多个节点上都具有集群成员。本文将讨论如图 1  所示的水平集群拓扑。

图 1.  集群拓扑
 

我们将讨论在设计基于 Web  的应用程序时的三个注意事项：

·  实现应用程序文件同步：我们将研究常用的机制是什么，以及如何利用 WebSphere Application Server 6.0  的新特性来实现它。

·  序列化会话对象：因为会话中包含的对象将在集群内的节点中进行同步，所以必须实现它们的 serializable  接口。本文提供了一个示例，以介绍如何强制完成这项工作。

·  使用动态缓存：我们将讨论如何使用 WebSphere Dynamic Cache  和  Data Replication Service  在集群中共享  Java™  对象。

实现应用程序文件同步

在企业应用程序的生命周期中，通常可以通过应用修复程序、添加新的 Web  内容或更新应用程序行为来对已部署的应用程序进行更新。一般来说，应用程序提供了允许用户上传在服务器端更改或创建的文件的用户界面。

将下面的场景作为一个示例：用户希望更新 Web  站点徽标图像文件，并且将原始文件作为  .war  文件应用程序的一部分进行存档。该应用程序提供了相关的功能和用户界面，以便用户完成这项任务。然后，用户选择一个新的图像作为  Web  站点的新徽标，并且上传该文件。系统使用新的文件替换原始的文件，并且当用户再次访问他的  Web  站点时，可以看到相应的更改。在单节点环境的应用服务器中，所有这些工作都可以顺利进行。然而，在集群环境中却存在一些问题。

在集群环境中，如图 2  所示， WebSphere Application Network Deployment  服务器中的  Deployment Manager  将接收到用户的上传请求，然后该请求被发送到  Node A 。 Node A  将执行相应的业务逻辑并使用本地文件系统中的新图像文件替换原始图像文件。然而该集群中其他的成员并不清楚这项更改，其本地副本并没有得到更新。因此，该 集群中各个成员之间的这个图像文件就出现了不一致的情况。如果  Node A  因为致命错误而停机，而  Node B  接收到了该请求，那么仍将使用原始的  Web  站点徽标。看上去客户似乎丢失了他所做的更改。

图 2.  集群环境中不一致的文件
 

这意味着，当应用程序运行于 WebSphere Application Server  时，需要在集群成员之间同步配置文件、二进制文件和资源文件。有一种机制可以处理上述问题。解决方案是使用共享的文件系统（例如， NFS ）或共享的数据 库。在这个解决方案中，所有经过更改或更新的文件都位于同一个共享文件系统或同一数据库中。对于共享的文件系统，所有应用程序都使用相同的位置，因此对于 这些应用程序来说，任何文件更改都是可见的。对于共享的数据库，应用程序可以从数据库中获得相应的更改。

上述解决方案的缺点包括：

·  共享的文件系统和数据库导致一个新的单点故障。

·  它增加了编程和配置工作的复杂性。

·  它引入了一个新的性能瓶颈。

另一个解决方案是使用细粒度 WebSphere Application Server  应用程序管理  API ，在集群的各个成员之间实现文件同步。 WebSphere 6.0  中提供了这一特性。 WebSphere 6.0  中包含许多改进，从而使得应用程序的部署更加容易并且更加高效。其中一个重要的改进是允许向系统提供部分经过更改的应用程序代码。不需要停止当前正在运行的应用程序。 WebSphere 6.0  还提供了灵活的应用程序文件管理。它允许应用程序通过以下方式进行更新：

·  替换整个应用程序（例如，整个 .ear  文件）。

·  替换、添加或删除应用程序中的单个模块（例如，.war 、 EJB.jar  或  .rar  文件）。

·  替换、添加或删除单个文件。

·  替换、添加或删除多个文件。

在对集群中的某个成员上的应用程序文件进行更新之后，将使用另一个新的特性 Rollout Update  对集群中各个成员的文件进行同步。它通过以下方式对应用程序进行更新：

·  保存更新的应用程序配置。

·  停止给定节点上所有的集群成员。

·  通过同步配置和重新启动该节点上停止的集群成员来更新该节点上的应用程序。

让我们回到前面关于 Web  站点徽标更新的示例。在这个场景中，徽标的更新和同步对于用户来说应该是透明的，无需  WebSphere  管理员进行人工干预。这就意味着，应用程序必须控制应用程序的更新，如替换存档于  ear  文件中的原始文件，并在集群的成员之间执行文件同步。您可以通过调用  WebSphere  提供的  Java Management Extensions (JMX)  接口来完成这项任务。 JMX  是一项  Java  应用程序资源管理标准。图  3  显示了使用细粒度更新特性进行文件更新和同步的流程。
图 3.  使用细粒度特性更新和同步文件
 

应用程序在接收到用户上传的文件之后，它将调用 File Updater  以构造增量  EAR  文件。这个增量  EAR  文件是一个存档文件，它具有与完整的应用程序  ear  文件相同的结构。增量  EAR  文件和完整的应用程序  EAR  文件之间的区别在于，该增量  EAR  文件仅包含要进行更新的文件。 File Updater  将构建这个增量  EAR 。它可以是封装了增量  EAR  生成逻辑的简单  Java  类，或者是添加了验证逻辑和生成文件的相关复杂组件。

序列化会话对象

使用集群方式的应用程序可以提高系统的可靠性和可用性。然而，这也引入了一些挑战，如会话管理。HTTP  会话是包括用户特定信息的集合。从用户开始访问到用户最后一次访问结束的这段时间内，由容器对会话进行维护。会话由一系列的会话属性组成。事实上，这些属 性都是由系统或开发人员创建的  Java  对象。

在集群环境中，开发人员必须清楚，HTTP  会话可能运行于多个  JVM  中。这些会话属性应该在每个  JVM  中保持一致。否则，当应用程序运行于不同的节点时，相同的输入可能产生不同的结果，这是因为与用户相关的数据在这两个节点中不一致。

WebSphere 为集群方式的应用程序提供了实时的、完全一致的数据共享。然而，前提是必须对所有共享的属性进行序列化和反序列化。当您将  Java  对象放入到会话中并希望在所有的节点之间共享该对象时，需要将这个  Java  对象声明为一个  serializable  接口。下面的代码显示了在将对象放入到会话属性时进行的验证工作。

public class MySession{        public static void addObjectToSession(HttpServletRequest req, String key,        Object value)        {             HttpSession session = req.getSession(true);             if(value instanceof Serializable)                  session.setAttribute(key, value);             else                  throw new NonSerializationException ();        }        public MySession()        {       }  }

在上面的示例中，您创建了一个名为 MySession  的新类，用来将对象添加到会话中。您可以通过调用  addObjectToSession()  方法来添加它。首先应该检查该对象是否实现了  serializable  接口。如果已经实现，可以随后将这个对象添加到当前的  Http  会话中。否则，将会出现  NonSerializationException 。有些时候，在运行于另一个  JVM  中时，会话属性中包含的信息无关紧要，如文件的绝对目录。在这种情况下，通过将其声明为瞬态属性可以使得这些字段不使用集群方式。

使用动态缓存

如上所述，将应用程序数据保存在中央数据库中可以确保在集群环境中写入和一致地读取数据。这种解决方案的缺点是，数据库服务器引入了新的单点故障 (SPOF) ，并且不适合那些需要高性能的应用程序。另一种解决方案是使用  WebSphere Dynamic Cache  和  Data Replication Service (DRS) 。您可以在基于内存的对象缓存的方式下，通过共享整个集群中某些服务器上的对象，来实现这个解决方案。图  4  显示了带  Data Replication Service  的  WebSphere Dynamic Cache  的体系结构。
图 4. WebSphere  动态缓存概述
 

WebSphere Dynamic Cache 是面向  J2EE  体系结构和缓存对象的解决方案。表示层中  Web  服务、 Servlet  和  JSP  的输出、 WebSphere  命令类以及  Java  对象都可以使用应用程序编程接口  (API)  进行缓存，或者声明一些缓存策略并将其添加到应用程序中。

Data Replication Service (DRS) 是用于复制数据的  WebSphere Application Server  内部组件。 DRS  使得集群中的各个服务器都可以使用会话管理、动态缓存和无状态会话  Bean  的数据。动态缓存可以利用应用服务器中的  DRS  在集群的各个服务器中复制缓存的数据。在集群范围内传输数据失效通知，以保持数据的一致性和有效性。图  5  显示了如何使用动态缓存和  DRS  在集群中共享应用程序数据。

图 5.  在集群中共享对象
 

首先，应用程序运行于 Server One ，并通过调用  DistributedMap API  将  Object A  放入其本地缓存中。通过合适的配置， DRS  可以在整个集群范围内复制缓存的对象并保持缓存数据的一致性。因此，将  Object A  复制到  Server Two  的本地缓存。当应用程序运行于  Server Two （假如  Server One  遇到问题或根据负载平衡策略将事务提交到  Server Two ）时，应用程序可以从  Server Two  的本地缓存中获得  Server One  的  Object A 。

WebSphere Application Server 通过使用缓存实例存储和管理缓存的  Java  对象。缓存实例还可以用于对相关的对象进行逻辑分组。特定实例的缓存中存储的对象不会受到其他缓存实例的影响。如上所述， DistributedMap  公共接口使得应用程序可以直接访问缓存实例。

JVM性能和可靠性

在我的讨论中，将最大堆容量超过 2GB  的任何  JVM  都视为 “ 大型  JVM” 。

64 位  JVM  是否适合您？

在 IBM的 JVM 性能优化 中， 文章 指出：

“请记住，很多从  32  位迁移到  64  位的人并没有实现性能的优势，相反带来了更大的内存占用，因为  64  位地址所占用的空间是  32  位地址所占用空间的两倍。 ”

占用较大的空间就意味着计划向服务器添加更多 RAM  的可能性极大。所需的额外  RAM  的具体量将取决于您当前所使用的  RAM  量以及当前具有的可用内存的量，但最后会毫不意外地发现，最终必须在服务器上使用双倍的  RAM  才能运行与当前  32  位  JVM  具有相同堆大小的  64  位  JVM 。例如，最近的一个客户以前在  RAM  为  2GB  的系统上运行正常运行最大堆大小为  768 MB  的  32  位应用服务器  JVM ，但过渡到  64  位  JVM  时，最终需要  4GB  的  RAM  才能使用相同大小的应用服务器  JVM 。

您可能会想 “最大堆大小为  768 MB  的  JVM  怎么会导致进程占用内存超过  768MB  呢？这完全没有道理嘛！ ” 堆 只是 JVM  的一个部分，另外还有解释程序；根据操作系统、 JVM  和堆大小的不同，解释程序在进程内存占用方面会在最大堆大小上增加  20%  到  50% 。因此，对于此客户，对于最大堆大小为  768 MB  的  32  位  JVM ，其硬件和软件配置所占用的内存约为  950MB ，而其对应的  64  位  JVM  所需的内存量约为  1.9GB ，而在只有  2GB  的  RAM  的情况下就没有任何内存供操作系统或系统上运行的其他进程使用。

除了添加 RAM （或至少确保拥有  64  位  JVM  所需的足够  RAM ）外，还将需要花时间调整所使用的  JDK  的垃圾回收  (GC)  算法。 IBM  为  WebSphere Application Server  开发的  J5SE  实现  (Java™ 5) （即在  Windows® 、 Linux® 、 AIX® 、 iSeries®  和  System z  上运行的  J5SE) 提供了两个  GC  内存模型，缺省为 “ 平 ” 内存模型，此模型一直在  IBM  开发的  Java  实现之前的版本（ JDK 1.4.x  和更早的版本）中使用；另一个模型为分代  GC  内存模型。

考虑到性能因素，在处理大型堆时，将要使用分代 GC  内存模型（在  Sun™  和  HP  上， JDK  仅提 供分代 GC  内存模型） ， 此模型在 IBM JDK  上通过命令行参数设置：

-Xgcpolicy:gencon

之所以首选分代 GC  内存模型，是因为大型  JVM  必须尽可能减少执行  GC  的时间。在分代  GC  内存模型中，对象最初在年轻代  (young generation)  空间（通常称为 “ 保育室 ”(nursery) ）中创建，如果对象在多次  GC  操作之后仍然存在，然后会将其移动到年老代  (old generation)  空间中。另外，在分代  GC  中会涉及两种类型的  GC  操作：

·  小回收 (Minor Collection)  仅在年轻代中进行，这通常通过直接复制进行，因此非常高效（迅速）。

·  大回收 (Major Collection)  在年老代中进行，将使用通常的标记与清除算法。

正如您可能已经猜到的，正确地确定“ 保育室 ” 和年老代空间的大小是减少小回收或大回收操作所耗时间的关键；对于大型缓存的 情况，您会希望调整年老代空间的大小，以保存所有缓存内容和其他长时间存在的对象。年老代太小将会导致  GC  操作过多，甚至出现内存不足的情况。要确定年老代空间大小，最佳方法可能是在每次采用缺省模式进行  GC  操作之后查看可用堆的量（可用堆百分比乘以总堆大小）。还应该分析  GC  日志，以了解年老代空间回收的频率；最优的分代应用程序进行年老代空间回收操作的频率应该非常低。

年轻代空间的大小通过 -Xmn (-Xmns/-Xmnx)  设置，而年老代空间的大小通过  -Xmo (-Xmos/-Xmox)  设置。

大型保育室通常适合处理吞吐量较大的情况，而小型保育室通常能提供较短的暂停时间，而要获得较高的 WebSphere Application Server  性能（吞吐量）通常需要相当大的保育室。一种不错的做法是，从  512MB  开始，然后逐步向上或向下，以确定最优值、测定吞吐量或响应时间，并分析  GC  日志，以了解进行清除操作的频率及时间。

ObjectGrid 是否适合您？

如果您需要为应用服务器使用大型 JVM ，则有必要认证考虑一下  ObjectGrid 。我在前面提到过，对于此讨论，我们将任何堆大小为  2 GB  及更高的  JVM  都视为 “ 大型 ”JVM 。这并不是说要从  ObjectGrid  获益就需要使用大型堆，远不是这个意思。任何大小的缓存都可以帮助提高性能和吞吐量，但是  ObjectGrid  能够存储大量数据，而且使用  32  位  JVM ，这就使其成为了一个非常理想的方案，不用过渡到相关内存开销大的  64  位  JVM 。

正如前面提到的，ObjectGrid  属于  WebSphere Extended Deployment （而且作为  Data Grid  单独提供）。如果您对其不了解，在此我对此作一下极为简单的介绍： ObjectGrid  是用于  Java  应用程序的启用了网格的灵活内存数据存储，提供了一系列部署和编程选项。最简单的选项是，将其作为内存内数据库使用，或作为  Java Platform Standard Edition (Java SE)  或  Java Platform Enterprise Edition (Java EE)  应用程序的缓存使用。每个  ObjectGrid  都由一个或多个映射组成，而每个映射又由一组键值对组成。在本讨论中，特别有意义的是两项  ObjectGrid  功能：

ObjectGrid 可以通过使用静态集群或动态集群采用客户机 - 服务器部署模型部署。动态集群使用目录服务来维护服务进程  JVM  列表， ObjectGrid  应用程序容器就承载在其中。目录服务为  ObjectGrid  部署提供多项服务（位置服务、放置服务、运行状况监视以及管理访问）。反过来，客户机可以与这些  ObjectGrid  服务器交互，以访问缓存内容（图  1) ，而这样又允许应用服务器 “ 客户机 ” 将缓存的主要内容分流到其他进程，而且同时仍然将访问最频繁的数据保存在本地缓存中。
图 1.  采用客户机 - 服务器部署模型部署的  ObjectGrid

ObjectGrid 能够跨多个  ObjectGrid JVM  对映射进行自动分区，此功能是维护大量数据的关键：将数据分散在多个  ObjectGrid  服务器上，每个服务器都在  32  位  JVM  中运行，而且没有  64  位  JVM  的巨大的内存开销。此外， ObjectGrid  还提供数据复制功能，消除了由于单个服务器而造成单点故障的情况。图  2  显示了分区和复制功能的情况。这些功能对于考虑将  ObjectGrid  作为  64  位  JVM  的企业级替代方案时非常重要。
图 2. ObjectGrid  跨多个  JVM  对映射进行分区

创建 ObjectGrid  集群的能力取决于应用程序客户机，而此能力支持在应用程序客户机之外部署  ObjectGrid  服务器层，如图  3  中所示。尽管图中显示了多种应用程序客户机类型，但在本文的讨论中，客户机将为  WebSphere Application Server ，此客户机将不再需要各自维护缓存的副本。而这将消除将应用服务器作为  64  位  JVM  运行的需求。此外，跨多个  ObjectGrid  服务器实例对  ObjectGrid  映射中的数据进行分区的能力可以作为  32  位  JVM  实现，而且每个服务器可存储的缓存内容量可达  4GB （总缓存量大得多）。这样可以节约大量的  RAM ，因为  32  位  JVM  并不会带来  64  位地址所带来的内存开销，每个应用服务器都不再需要维护整个缓存的副本（尽管可以在需要的情况下维护本地缓存）。

图 3. ObjectGrid  集群
 
对于当前维护大型缓存的应用程序，迁移到基于 ObjectGrid  的解决方案应该非常简单，因为  ObjectGrid ObjectMap API  与现有的基于映射的标准  API （如  HashMap ）非常相似。应用程序流通常可以采用任何缓存实现模式。实际上，使用  ObjectGrid  时，应用程序将按照以下顺序操作：

1  开始 ObjectGrid  会话。

2  获取 ObjectMap 。

3  将数据放入 ObjectMap 。

4  提交会话。

ObjectMap 是应用程序本地的映射，也就是说，映射存在于应用程序运行所在的堆空间中。当应用程序将数据放入  ObjectMap  中时，数据放置在本地堆中。应用程序提交会话时， ObjectGrid  会将数据复制到  BackingMap  中。 BackingMap  属于基于  ObjectMap  的  API  集，驻留在  ObjectGrid  服务器（例如，容器服务器）的堆空间中，其中包含所提交的数据。通过将数据提交到  BackingMap ，应用程序可将数据提供给其他应用程序（或者，如果应用程序在并发环境中运行，则为其他应用程序线程）访问。最重要的是，与很多其他 分布式缓存解决方案不同， ObjectGrid  集群的配置以及服务质量（如同步或异步复制、按 “ 区域 ” 的重复放置、分区的数量等）都由数个  XML  属性文件进行控制，而这些属性文件可以方便地根据需要进行更改

缓存之外的应用

或许您需要大型 JVM  的原因并不是因为应用程序缓存，而是需要处理大量  HTTP  服务器对象或大型  HTTP  会话对象，因为  HTTP  经常作为隐式应用程序缓存使用。 ObjectGrid  提供了用于通过  Servlet  筛选器分流  HTTP  会话数据的内置机制。 Servlet  筛选器以  J2EE EAR  文件的形式为应用程序提供  ObjectGrid HTTP  会话管理器，而且通过  addObjectGridFilter  脚本采用管理方式添加，此脚本以  Servlet  上下文初始化参数的形式向  Web  应用程序添加相应筛选器声明和配置 —— 而不用进行任何应用程序更改。图  4  中显示了使用  ObjectGridFilter  为  HTTP  会话数据部署的应用程序。

图 4.  使用  ObjectGridFilter
 
 

通过这种方式使用 32  位  JVM  分流  HTTP  会话，同样可以通过避免  64  位寻址的开销而节约大量的内存。

DynaCache 和  Distributed Map

我并没有忘记这两项，不过对于需要大型应用程序服务器堆的情况，DynaCache  和  Distributed Map  都没有提供  64  位  JVM  的替代方案。 DynaCache  是  WebSphere Application Server  的功能，可缓存  Servlet 、 JSP 、 Web  服务和  WebSphere Application Server  命令生成的结果，而  Distributed Map  提供用于在  WebSphere Application Server  实例中创建本地或远程缓存的  API 。由于这些  API  都依赖于  WebSphere Application Server  运行时，因此缺少将缓存分流到独立缓存层的能力。因此，它们并不提供使用  64  位  JVM  保存缓存数据运行应用服务器的替代方案。虽然  Distributed Map  提供了磁盘分流（可以用于将缓存的大小限制为在  32  位磁盘空间内），但通过这种方式进行分流带来了在磁盘上写入和检索数据的延迟，其性能可能不为某些时间敏感的应用程序所接受。此外，正如我们提到 的， DynaCache  特定于应用程序构件生成的输出，因此没有用于检索底层应用程序数据用于其他用途的机制。

安全

对于网络方面的安全问题，不同的开发者和设计者有不同的认识和见解， 我试图采用 和《 JAVA  探索者： JAAS  和  JSSE  的  JAVA  安全》相同的分类方法，将  Web  系统的安全问题分为三个类别：认证、授权和传输。认证和授权是任何一个应用系统中的基本安全问题，认证过程是首先通过各种形式的认证表单或途径获得使用者 认证数据，然后根据认证数据确定对方身份的过程，对于  Web  认证安全数据提交形式包括普通表单、证书等；授权过程则是对确认了的认证身份的主体进行判断的过程，判断认证了的主体是否有对客体实施某种操作的权限；相 对于传统的  C/S  应用系统， Web  应用系统采用  B/S  结构， B/S  得以广泛使用和迅速发展很大程度上依赖于其瘦客户端的标准化脚本解析和传输的标准化，然而标准化的  HTTP  协议传输方式一方面使得开发网络应用快速而简单，另一方面  HTTP  协议的网络传输问题也暴露很明显，因此传输过程中的安全问题成为亟待解决的  Web  三大安全问题之一。

图 1.  网络安全问题
 
 

上图 1  详细刻画了  Web  安全三个方面的问题，三者之间的关系可以表述如下：

首先，服务器端需要确认客户端用户的身份；其次，当客户端请求访问服务器端某一受限的访问资源时，服务器端需要根据客户端提交的身份确认其 是否有足够的权限访问该受限资源；最后，客户端和服务器端的交互访问方式需要通过网络完成，传输过程中的数据可能被非法获取、篡改，当然也存在不能确认传 输双方的身份等问题。

WebSphere Application Server（ WAS ）结合的计算机安全近  40  年的成果，在网络安全、操作系统安全、 J2EE  安全等方面提供了坚如磐石般的安全体系的同时，还保持了极其灵活的特点，成为  Web  领域解决方案的重要利器。本文接下来的章节，将从以上描述的三个方面为出发点，对  WAS  安全机制进行概述，包括  WAS  整体安全架构和各个层次上的安全解决方案。由于每个层次上的安全问题都是一个安全领域独特的知识，本文对每个层次的安全方案进行简介，并探讨其与其它层次 之间的关系。更深入的讨论将在本系列文章的其它文章中进行阐述。

WAS 安全体系架构

对于 WAS  的管理，常用的管理方式包括管理控制台、 JMX 、 Java JNDI  等， 管理内容相应的包括命名、用户注册表、 JMX  管理资源以及常见的  Web  资源，包括  Html 、 JSP 、 Servlet  等，按照上一节中对于  Web  中安全的阐述的观点，这些资源为受保护的服务器资源，而对于这些资源的访问控制则为  Web  安全的管理对象，在图  2  中统称为  WAS  资源，在本节下面的篇章将依次介绍各个安全层次对于这些受保护资源控制。

图 2.  自底向上的安全体系结构
 
 

从安全技术使用范畴的角度，将 WAS  的安全体系结构自底向上的划分方式分为，平台安全、 Java  安全、 WAS  安全，详细的架构体系层次关系如图  2  所示。

平台安全 包括两部分，即操作系统安全和网络安全。网络安全解决网络传输中的安全问题，包括网络传输中的 完整性交验，机密性保证等网络传输中存在的问题，在 WAS  中通常通过配置对  SSL  和  VPN  安全配置解决传输中的安全问题。对于操作系统层次上的安全，除了通常意义上的依赖于不同的平台本身的安全特点，对于  WAS  文件系统和进程等进行的安全访问控制， WAS  提供了基于操作系统帐户的  WAS  安全控制管理，大大提高了  WAS  的安全管理的便捷性和易用性；此外在不同的操作系统平台上，提供了具有平台相关性的安全特点，在影响着  WAS  的安全管理。

对于网络安全中的 SSL  安全和操作系统上的安全机制在以后的篇章中将进行介绍。

JAVA 安全 ，由于 WAS  是  J2EE  认证服务器，因此  WAS  遵从  JSR  社区的  JAVA  安全规范，从  JDK  到  Java2  安全体系结构， JAAS ，再到  J2EE  安全模型等等，因此  JAVA  中的安全管理也适用于  WAS  中。对于  Web  安全的三个问题中的认证与授权，《  JAVA  探索者： JAAS  和  JSSE  的  JAVA  安全》认为， JAVA2  安全体系结构主要解决授权问题，而  JAAS  主要解决认证问题。 J2EE  也提供了  class  级别的安全授权模型，并提供了对上层的  J2EE  资源的安全管理规范，因此对于  Web  的安全认证与授权问题本文主要介绍  Java2  安全体系结构、 JAAS  和类级别的安全授权模型。

对于这一层次的安全本文着重于 JAVA2  安全架构、 JAAS  和  J2EE  安全角色三个安全层次的介绍，这三个安全层次的安全策略为属不同的领域，可以相互补充使用，本文在其后章节予以介绍。

WAS 安全： 对于图 2  中  WAS  安全层上的安全主要是强制使用统一的安全访问控制方式对  Web  资源、企业  Bean  和  JMX  管理资源。可以理解为对于  WAS  服务器资源的访问时， WAS  安全层强制自顶向下依次调用安全架构中各安全层次进行访问控制，从而保证了任何一种资源的访问都采用了统一的完整的安全控制，此外配备了对于不同的安全层 次的管理具体控制选项设置，这些设置可以被运用于管理当中。在访问控制内容上，安全访问控制的内容包括  JMX Bean ， Web  资源等；在访问控制方式上则包括， JMX  访问、控制台、 WSadmin 、纯  JAVA  的  JNDI  访问等等；在访问控制的层次上，则对于不同的访问方式， WAS  安全提供了从传输到上层的用户角色等的自底向上的访问控制方式 。

从上下层的关系看，WAS  提供了自底向上的安全管理模型，在实际的应用中，使用者可以根据具体需求对安全层次的选取进行设定和管理，图  3  所示的为在  WAS  管理控制台中对于不同层次安全的管理控制设置，如  Administrative Security  中则主要应用  J2EE  角色安全的方式进行控制； Java2 Security  则是  JAVA2  安全体系； User Account Repository  则可选操作系统安全或者其他安全方式； Java Authentication and Authorization Service  为  JAVA  安全层次中的认证机制。

从 Web  安全三大问题的角度看，如图  3  介绍，对于  Web  安全授权分别由  JAVA  安全层次中的  J2EE  安全模型，  Java2  安全模型来完成；对于  Web  认证则由操作系统用户认证方式、 JAAS  认证模型，以及  WAS  统一的  LTPA  等的认证机制；而对于  Web  传输则主要由图  4  中展示的  SSL  传输安全机制来完成。

图 3. WAS  中的安全认证与授权
 
 
图 4. WAS  中传输安全
 
 

WAS 安全体系中各层次安全简介

在本章中将分小节对三个安全层次中的主要安全领域问题进行重点介绍，主要介绍内容包括，平台安全中的操作系统安全和网络；JAVA  安全中的  JAVA2  安全、 J2EE  角色安全和  JAAS  安全。

SSL 安全介绍

SSL 安全属于  WAS  安全体系中的平台安全层， 在  WAS  中，对于网络传输安全主要采用的是  SSL  协议，在  WAS  安全控制启动后，不论以  Web  控制台方式、 JMX  方式访问  MBean  还是对于  wsadmin  方式管理  WAS ，启动的访问进程都必须遵从  SSL  协议进行通信。

对于浏览器访问 WAS  管理控制台的方式， WAS  会完成自动跳转，启用  Https  协议进行传输；对于  wsadmin  和  JMX  则在正常的管理控制用户认证开始前进行  SSL  的握手过程，握手过程完成后，整个交互过程采用  SSL  握手时建立的安全通道进行通信。

SSL（ Secure Socket Layer ）即安全套接字协议， SSL  协议结合了对称加密算法和非对称加密算法进行传输过程中的数据加密、解密，保障了数据传输过程中通信双方的身份认证、数据的机密性和完整性等问题。

对称加密算法是较为最为经典且古老的加密算法，这一加密算法最大的特点是在实际的加密、解密过程中，加密、解密运算互为逆运算，这两个运算 过程中用到的密钥相同，这一过程可用图 5  予以解释。由于对称加密算法要求通信双方使用相同的密钥并约定加密算法，因此在实际的网络传输应用中对称加密算法面临着密钥传输和算法约定等问题，降低了 这种加密算法使用的可用性。但是这种经典的加密算法执行效率高，加密快。

图 5.  对称加密算法
 
 

非对称加密算法也称作公钥加密算法包含一对密钥，分别称作公钥和私钥，在加密和解密过程中，这对密钥互为反运算的密钥，即假设用公钥对明文 进行加密的密文，则只能用私钥密钥进行解密得到明文，非对称密钥的这一特性可以用图 6  予以解释。在实际的运用中，非对称加密算法的这种特性得到了很好的运用，将公钥公布、私钥个人保留，解决了传输网络过程中的身份认证问题，同时解决了公钥 的物理传输问题，不足之处在于非对称加密算法较为复杂，计算过程较慢，效率不及对称加密。

图 6.  非对称加密算法
 
 

基于这两种算法的特点，SSL  协议的安全网络传输协议应运而生，利用非对称加密解决身份认证问题、密钥传输、算法协商等问题，这一过程也称作握手过程，握手过程结束后，通信双方得到了 协商好的对称加密算法和加密钥，从而建立了一条安全的通信信道；安全的通信信道建立成功后正常的通信过程开始进行，这一过程中通信双方的请求与应答内容都 采用对称加密算法完成后进行网络传输。

在 WAS  管理过程中， WAS  服务器强制客户端（浏览器或者  JAVA  程序）与  WAS  服务器采用  SSL  协议进行安全通信，当然这一过程中涉及了网络传输安全中的认证授权、机密性、完整性以及不可否认性，采用的算法除了本节所讨论的对称加密算法和非对称加密 算法外还采用了不可逆加密算法，对于非对称加密算法引入了证书和证书授权机构等概念，这些不在本文进行阐述，将会在以后篇章中进行较为详细的阐述，并结合  WAS  对于证书和算法的管理进行阐述。

操作系统安全

操作系统安全也属于 WAS  安全层次的平台安全层，作为底层操作系统为  WAS  提供了安全基础设施，操作系统定义并管理着后台启动的任务，建立启动概要文件，并是访问底层的基础系统资源例如文件、安全套接字等的基本设施。除此之外， 底层操作系统为  WAS  提供了可信的认证服务用户注册表，这一部分内容将在本文后边的章节有所介绍。对于授权服务，本地底层操作系统提供了  SAF （ System Authorization Facility ）服务为运行在  WAS  内的控制台、应用程序等提供了授权服务，

由此可以看出对于 WAS  的运行管理，甚至于  WAS  使用时的认证授权都必须协调操作系统的安全配置管理来完成，例如对于使用本地操作系统的用户注册表时候，则需要登录用户或者启用用户具有相应得操作系统的 一定的管理权限来完成，否则会造成  WAS  不能正常运行，进而应用程序不能正常运行，因此对于  WAS  的管理一部分工作实际上是对于操作系统的管理工作。

对于 WAS  的管理在不同的情况下可能需要本地受限用户进行管理工作，因此对于本地受限用户操作  WAS  的管理工作就涉及到操作系统的限制和  WAS  的限制，充分了解操作系统的安全认证、与授权是管理  WAS  安全工作的一部分。从某种程度上讲，操作系统安全在  WAS  整个安全管理体系中相当于为其他安全和  WAS  本身的正常运转创造一个正常有序、合理安全的运行环境，而维系这中正常的运行环境在以  WAS  启动、运行、停止为周期过程为基本指导原则的，在充分考虑  WAS  运行声明周期中各个环节的安全特性，结合操作系统的安全认证、与授权的特点的前提下来最终完成。

JAVA 2 安全架构及在  WAS  中应用

JAVA2 安全属于  WAS  安全架构中的  JAVA  安全层上， JAVA  语言发展迅速除了其本身的面向对象的强大特点之外，其坚如磐石的架构设计理念也不容忽视的，强大的安全设计架构使其能够适用于企业级安全需求。 JAVA  的安全模型主要保护功能是保证系统资源不被非法程序所接触，这些系统资源包括文件、网络等资源，与此同时提供较为完善的访问控制模型使得得到授权的程序可 以正确访问资源，因此《  J2EE  探索者》的观点认为  JAVA2  在  Web  应用安全中解决授权问题的。

JAVA2 安全架构模型相对于  JAVA1  安全模型提供了更为强大的安全管理模型，如图  7  所示的  JAVA2  与  JAVA1  的安全对比模型。 JAVA1  的安全模型认为本地程序是安全程序可以自由的通过  JVM  访问受限的系统资源，而对于远程程序则要对远程程序进行签名验证，可信签名的程序可以和本地程序一样正确访问本地资源，而对于没有得到认证或者没有签名的 程序则会进入沙箱进行运行，进入沙箱的程序对本地资源访问受限，只能运行普通功能。

图 7. Java1  安全模型和  Java2  安全模型
 
 

JAVA2 安全模型在对程序可信方面做了调整。对于本地程序同样要进行签名验证和管理，对于不可信的本地的资源同样进行首先控制，使得本地非法程序仍旧不能访问本地资源。

JAVA2 提供了更为灵活的安全控制模型，开发者可以通过定制安全策略、安全类装载器从而保证了开发人员可以动态定制开发出更为灵活的安全管理架构。比如开发出使用时间受限的应用程序。

JAVA2 提供了更多的域概念，除了可信和进入沙箱的程序， JAVA2  安全模型提供了更为细分的安全域，不同的应用程序根据不同的应用签名和安全策略制定相适应的安全域， JVM  通过调度使得应用程序进入进入相应的安全域访问受到约束的部分本地资源，在保证了安全前提下，提供了更为细分的权限分配，满足了对于企业级应用的安全需 求。

从可信任层次上看， JAVA2  安全模型认为可信的  JAVA  代码是  JVM  本身的  JAVA  代码；从控制方式的角度来看， JAVA2  安全模型以交验  JAVA  代码的运行路径、 JAVA  代码本身的签名，因此  JAVA2  模型更多强调代码的所有权，从而保证系统的安全性。

基于 J2EE  角色安全介绍

J2EE 安全属于  WAS  安全架构中的  JAVA  安全层上。 J2EE  提供了基于角色的安全授权控制模型，基于角色的安全授权模型主要是提供基于角色的安全控制检查，确保只有足够权限的安全角色能访问相应的受限资源。角色是 一组权限的逻辑集合，这组逻辑集合可以被赋予真实用户注册表环境中一个或者多个合法用户或者组，在系统程序运行时，通过检查某一个真实用户所属的角色或者 真实用户组所属的角色来完成相应的安全检查。

对于授权检查方式上，J2EE  提供了声明型和程序型授权性安全检查策略，由于  J2EE  的安全保护对象为  J2EE  资源，因此声明型的授权模式对不同的保护资源通过不同的声明文件进行控制，常用的  J2EE  资源一般通过  web.xml 进 行控制，控制的标签为   和    等协作完成，对于  EJB  的控制则通过配置  ejb-jar.xml  来完成，通过这种配置方式从而达到保护指定的受限资源的目的。

值得一提的是 WAS  本身控制台的安全管理角色授权机制就是基于  J2EE  的安全模型管理机制的，如表  1  中所示，列出的为基本的  WAS  控制台角色以及相应的权限，这些用户角色可以根据不同的真实用户注册表情况映射到不同的用户和用户组。

表 1. WAS  控制台的角色
 

角色	权限
监视员	监视员可以查看 WAS  中的各种配置信息，运行状态，但是不能做任何更改
操作员	操作员可以触发运行时状态改变，例如启动、停止服务器，但是不能做任何配置的改变
配置员	配置员可以修改配置信息，但是不能更改运行状态。
管理员	管理员具有操作员和配置员的权限，除此之外还能修改敏感的安全配置信息和服务器安全策略等，例如服务器 ID  和密码，启动和禁用管理安全， JAVA2  安全等等。

除了 WAS  控制台使用安全角色模型，正常的  J2EE  应用自然适用于这种安全控制模型。如图  8  所示，该应用中定义了  3  个角色， WAS  提供了机制对这些在应用中预定义的角色从用户注册表里进行分配管理，通过应用程序预定义抽象的角色，在实际应用中对这些抽象的角色进行用户分配，大大提高 了应用的灵活性。

应用程序在实际的运行过程中通过声明型和程序型管理方式直接或间接操纵这些抽象对象，这部分安全管理工作可以通过声明的方式进行管理，这样 WAS  可以来处理这部分角色级别的安全认证、授权管理；当然有时候基于角色不能解决实际问题，那么需要更为灵活的程序型安全授权管理方式， J2EE  资源可以直接操纵这些委托  WAS  容器进行认证的用户。

对于 Servlets ：

isUserInRole() 用来检查登录用户是不是在某个角色中。

getUserPrincipal() 用来得到登录用户实例，通过实例可以获得姓名等。

对于 EJBs ：

isCallerInRole() 用来检查登录用户是不是属于某个角色。

getCallerPrincipal() 用来得到登录用户实例，通过操纵实例完成相应的动作。

图 8.  应用的安全模型角色
 
 

基于 JAAS  安全认证介绍

JAAS 属于  WAS  安全架构中的  JAVA  安全架构层上，全称  Java TM Authentication and Authorization Service ，JAVA  认证与授权服务，故名思义用来解决安全认证与授权的问题。

PAM（ Pluggable Authentication Module ）可插拔认证模块，PAM  是一种认证授权框架，这种框架提供了一种认证机制，使得上层业务应用程序的开发使用不依赖于底层的认证授权机制， JAAS  正是  PAM  的  JAVA  版应用框架。

JAAS 的认证机制是通过检查  JAVA  代码的执行者身份，这些  JAVA  代码包括  Servlet

、应用程序、Applet  等等； JAAS  的授权机制主要是用来检查并确保执行者有足够权限进行相应的动作， JAAS  可插拔认证模型关系如图  9  所示。

图 9. JAAS  可插拔认证模型
 
 

根据 JAAS  的运行机理，本文将  JAAS  的认证授权模型分为四个层次，自上向下依次为应用层、授权层、通用认证对象层、认证层。由于授权层是外部和内部结合的控制方式，因此跟上层业务应用程序本 身之间没有直接的耦合与调用关系，按照分层架构模型设计原理，在运行时，授权层通过访问安全控制策略只能访问通用认证对象模型，而通用对象层的认证对象凭 证是在运行势态动态生成的，跟底层的认证层没有依赖关系，因此上层应用对底层也没有依赖关系，从而达到了上层商业业务逻辑和下层认证模块之间没有直接耦合 的关系。

JAAS 机制与  JAVA2  安全模型相比，两者解决不同的问题，面向的侧重点不同。从保护对象角度来看， JAVA2  安全模型提供内嵌的系统资源保护模型，当然开发者可以开发更多的面向业务的保护对象，而对于  JAAS  则提供更灵活的认证授权控制，除了保护业务对象，也可以面向业务操作进行保护；从授权检查机制的角度， JAVA2  安全模型更多强调安全代码的所有权，而  JAAS  则强调的是代码的使用权；从检查形式来看， JAVA2  的安全模型属于声明型的管理模式，而  JAAS  的管理模型可以声明型和程序型相结合；从安全检查级别来看， JAVA2  安全模型属于角色级别的检查控制，而  JAAS  可以提供基于角色和基于实例的安全授权控制。因此两种安全认证模型可以结合使用，保证更为安全和灵活的管理控制。

WAS 开放认证授权架构介绍

前面介绍了 WAS  安全架构中的自底向上的安全层次，不同的安全层次有着不同的安全管理控制方式，然而这些安全层次之间如何交互，则需要从交互关系来看。 WAS  的开放认证授权架构如图  10  所示，在一个  WAS  中对于认证、授权是相应的  Security Server  和  Access Manager  两个模块来完成的，而其中对于认证模块又包括两部分  JAAS  登录和  User  注册表两部分组成，因此常规的安全登录实际过程是首先采用某种机制通过  JAAS  登录模块进行登录认证， JAAS  登录模块利用得到用户登录数据到相应的选定的用户注册表里进行验证。从而完成相应的认证工作，当然对用户进行一系列的映射动作，完成映射动作后用户如果要 访问相应的受限访问资源，则  WAS  对其角色进行验证，从而完成授权检查等动作。

图 10. WAS  开放认证授权架构
 
  对于 JAAS  的常规实现是每个  JAAS  是一个认证方式，从而保证了业务高层和登录模块的分离，因此大部分的认证实现直接完成了对于某一个用户注册表的认证。而  WAS  对于这一问题进行了较为灵活的设计，对于每一种  JAAS  登录模块都是一种登录机制和映射机制，每种登录机制会控制登录的  Cookie/taken  等的格式，以及多个  WAS  间共享登录信息的格式等等，这些机制对于各种登录机制是不同的，但是对于同一个用户注册表管理方式可能会使用同一种登录机制。因此  WAS  的灵活认证架构设计在对于认证机制和用户注册表之间采用桥模式进行设计，如图  11  所示，保证了认证机制和用户注册表的选取之间的组合方式。

图 11.  灵活的  WAS  认证机制
 
WAS 安全体系的认证机制

认证在 Web  安全中主要解决是谁的问题，而对于授权则是解决有没有权限进行某种操作的问题，如图  12  所示，对于  WAS  中的认证与授权之间的关系， WAS  作为  Web  容器，是应用程序运行的管理和调度者，对于应用程序的认证则不能局限于  WAS  本身内部，因此对于认证问题委托给了用户注册表。同样对于授权方式，每个应用程序有着不同的授权方式，对于声明型的授权管理工作， WAS  通过读去应用程序的授权声明进行调度和监控；对于程序型的授权管理，应用程序通过与  WAS  进行交互得到登录用户的信息，进行授权管理。因此应用程序对于授权工作都要最终依托于相应的应用程序进行授权工作， WAS  作为容器提供管理和调度交互工作，最终的认证与授权的方式和具体内容细节则交由应用程序来管理和控制，一方面降低了开发难度，对于应用程序保证自底向上的 安全性的开发工作是复杂和庞大的；另一方面在使用  WAS  提供强大的安全控制时保证了安全性的同时，提高了开发效率。

图 12. WAS  中的认证授权
 
 

在 WAS  中的具体认证过程如图  13  所示， Web  客户端在得到服务器认证响应后进行认证数据提交，对于认证数据提交的方式一般的包括三种形式， Http  基本认证、 Https  客户端认证和自定义表单认证，一般的自定义表单认证具有自定义的界面，因此这种模式适用的比较多。

认证数据同过网络传输到服务器，根据前一节对于 WAS  认证架构的认识与了解， WAS  会使用一种在服务器中选定的认证机制进行认证管理，认证数据通过认证机制进行一定的处理提交到用户注册表进行验证，认证后的认证凭证存在  WAS  对于  JAAS  的扩展中，在登录用户访问需要进行授权时即从凭证中取得相应信息进行授权管理。

对于 WAS7  中使用比较多的是  LTPA  认证机制， LTPA(Light Weight Third Party Authentication)  第三方轻量级认证，对于  SWAM  则将在以后的版本中放弃使用。

对于用户注册表，目前支持的主要为四种类型。本地操作系统，如果用户选择本地操作系统的认证方式，那么用户需要有本地用户才能成功进行认 证，对于 Windows  的域环境，这种管理方式更是有其绝对优势，一方面对于任何本地用户不用分配额外的帐号易于使用和管理；另一方面由于不使用额外帐号，对于授权了访问操作系 统的本地用户，直接可以访问应用程序降低了管理成本。 LDAP  轻量级目录访问协议，通过  LDAP  的控制管理方式，保证了对于  LDAP  应用企业的应用的兼容性，大大改善了以往应用程序对于  LDAP  支持的难度。联合用户注册表提供了一种多种存储方式并存的管理模式，大大改善了对于多用用户注册表并存系统的集成和兼容。最后一种用户注册表是自定义注册 表，对于任何一个应用，如果前面三种用户注册表策略仍旧不能满足相应的需求，用户可以通过自定义注册表的方式，和系统中已有或者新开发的登录机制相结合完 成特殊的登录认证需要。

图 13. WAS  中的认证过程
 
WAS 安全体系的授权机制

授权主要是用来满足对于受限资源的访问控制问题，如图 14  所示的授权管理工作，当用户需要对受限资源进行某种操作时，操作请求信息会发送到  WAS  服务器中，根据上一节中所介绍的  WAS  服务器通过认证进程对用户信息进行管理和控制，如果用户没有进行认证，则按照上一节中讨论的方式进行认证管理，认证后得到用户认证凭证，用户认证凭证和请 求操作被转发到相应的授权管理进程，授权管理进程将用户认证凭证和请求的操作通过授权矩阵进行评估，从而判断用户是否有权限进行请求的操作。

图 14.  授权逻辑视图
 
对于基于 WAS  的应用程序的授权管理工作，依照上一节中介绍的观点， WAS  直接或者间接的委托于应用程序， WAS  在其中进行管理、协调和监控， WAS  对于授权管理工作遵守  J2EE  授权的管理模型，即基于角色的授权声明性授权管理和更为灵活的程序性授权相结合。那么对于授权的实施过程可以参考图  15  所示。

如图 15  所示的为从安装、使用的自左向右的顺序，但是先开发后进行安装部署的角度，则是从右到左的顺序。按照  J2EE  安全授权模型的设计思想，首先对于应用程序抽象出用户角色，然后对于抽象的用户角色进行声明性和程序性授权控制，因此程序具有很强的健壮性和兼容性，不依 赖于任何某种用户注册表，进行合理的配置可以应用于不同的用户注册表以满足不同注册表用户对于程序需求。对于部署阶段则是映射实际的用户到  J2EE  中定义的用户角色，依照  J2EE  安全授权模型的定义，用户角色实际上是一组权限的逻辑集合，这些集合可以是一个用户或者是一个用户组，因此对于映射工作实际上是角色的认定过程。

因此对于一个应用程序从开发到实际的运行环境需要至少需要经过开发和部署两个阶段，开发阶段应用程序对抽象用户角色进行依赖与交互，而对于 部署阶段则是将开发阶段预定义好的用户角色实际运行环境中的用户注册表进行映射，在完成了基于抽象用户角色的用户权限控制开发和抽象用户角色到实际用户注 册表中的映射部署才最终完成了应用程序的授权过程。

图 15.  授权实施
 

重难点分析

时间有限不作分析。

 

1.  业务系统的架构分析需要深入的剖析，这个准备工作要早，对于项目管理人员来说，如何更早的知道这个系统的预期架构的全貌是重点。

2.  Edge server的集群和 F5 设备的 PoC 测试中集群搭建的重点，动态扩展方面是项目经理在性价比上进行讨论的重点。

3.  缓存设计是难点，难度在于如何降低开发人员的难度但同时不失缓存特性的优势。

4.  WAS和同一层的 WVE ， MQ ， WPS 等集成是一个重点。

5.  系统全局后的应用架构环境测试是一个耗时长的重点，需反复修正达到3 个要求，完全可用，高性能， webservices 高效。

6.  运维监控匹配的IBM Tivoli 其他产品比较庞大，需专业匹配。

7.  数据库层面的性能问题不能简单处理，可用性也不能单纯依赖RAC 来做，可以结合用户系统情况，充分利用 Oracle11g 中的新一代高可用性技术以及 RAT 来验证。需专业 DBA 。