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

平台背景

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.??优点、缺点、糟糕之处?
?

那么我们的系统是不是一个适合做成?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??和??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??版本中才支持服务器间的缓存复制。

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

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

如果应用中要缓存的数据量比较小，则可以采取?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??接口。下面的代码显示了在将对象放入到会话属性时进行的验证工作。

在上面的示例中，您创建了一个名为?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?进?行控制，控制的标签为?<security-role-ref>??和??<security-role-ref>??等协作完成，对于??EJB??的控制则通过配置??ejb-jar.xml??来完成，通过这种配置方式从而达到保护指定的受限资源的目的。

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

表?1.?WAS??控制台的角色?
?

除了?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?。

最后欢迎大家扫码关注，我们一起学习，进步和交流!?
本公连接也是一个温馨的技术互动交流的小家园，有什么问题随时都可以留言，欢迎大家来访！?

?

?

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

原文：http://3264529882.iteye.com/blog/2236728