在传统金融企业中，不少企业已经开始构建自己的私有云。在已实施的建设成果中，大部分实现了存储、网络、服务器的资源池化，而应用服务器部分则多为一个应用服务器用于一个应用系统，呈现出一定的“烟囱式”。随着应用系统的不断增多，管理这些服务器以及在其上部署中间件服务的成本也越来越高。集中企业应用服务器资源很重要，这样多个应用系统就可以共享和使用高可用的企业级中间件服务。许多公司认可的解决方案。根据社区调研，中间件资源池化面临共享资源使用冲突、应用系统间相互影响、运维管理模式变革、功能支撑等诸多问题。1、向资源池化方向发展应用服务器有什么优势？企业为什么要开发服务器资源池？全面提升系统硬件资源的使用，同时使用池化确保它们可以快速扩展以应对高峰时段的大量请求。池化节省了开发运维的时间和成本，加速了应用的迭代开发和新版本的发布和运行。2、应用服务器的资源池化是不是类似于中间件的数据源？可以这样理解，但是应用服务器的资源池化粒度比较大，应该说是比较大的！主要体现在可扩展性和快速部署运行上。3、服务器资源池化会面临哪些问题？第一个问题是应用支持不支持集群部署，然后是管理的问题。4、核心系统中间件部署在资源池有哪些风险点？风险点是：(1)资源池的监控和对动作的响应一定要及时，也就是说要以预防为主，配置好响应策略！(2)应用系统本身的健壮性，当出现问题时，可以隔离资源池并抓取日志，分析问题根源。5.对于核心交易系统，资源冗余是安全生产的必要保障。它进行资源池化，如何保证资源池化配置达到与当前资源冗余相同的安全生产目标，如何打消运维人员在这方面的疑虑？(1)解释pooling的作用和带来的好处缺点(2)在测试环境验证，满足要求后生产(3)新技术在发展，多学多用总有好处6.如何保证资源池的高可用和高稳定性？核心系统应用服务器要实现资源池化，当前资源池的高可用性和稳定性是否可用和令人满意，以及如何处理预期故障应该是非常关键的。应用服务器资源池化之后，在实现上只是改变了资源释放的形式，高可用性和稳定性的实现机制依然沿用了之前的机制。但是，在池化应用服务器资源的基础上，增加了健康检测机制以进行自我修复。当某台服务器出现问题时，将其隔离或删除，启动另一台服务器对外服务。前端分发器会自动识别后端服务。变化，从而实现应用服务器资源池化后的高可用和稳定。7、在应用服务器实现资源池化的场景下，如何保证应用接口调用的安全认证？如何保证不同应用所需要的资源能够得到安全保障，权限细分，认证访问控制等，这些方面是如何控制的？虽然在应用服务器实现了资源池化，但是应用接口调用的安全认证不需要被改变。仍可按原应用系统自身的安全设计进行，无需随池化而改变；细粒度的权限同时，仍然在应用层考虑认证访问控制。8.“WebSphereApplicationServer实现资源池化”指的是什么池化？这由来已久。我们可以从最初的WebSphereVirtualEnterprise产品开始(1)在传统的方式中，我们有多个设计并运行的静态集群。因为每个集群资源的利用率在不同的时间段是不一样的，导致资源的层次不一样。太高了会出问题，太低了又浪费。然后它成为动态集群的池。就多开几个WAS实例来处理，谁的请求少，就关掉几个WAS实例，从而达到动态调整的作用，也就是池化；(2)后来加强了，可以动态启动一个操作系统的虚拟机，启动WAS来响应请求；(3)除第一种和第二种外，由于技术的发展，更进了一步。Docker容器技术也可以用来启动或停止多个实例，从而达到均衡响应外部请求的目的。总结：在相同硬件下，通过池化快速提供中间件基础服务，为应用提供运行环境，充分均衡地提高硬件利用率，同时保证系统的稳定性和高可用9.WAS应用服务器资源池支持什么版本？V9版本的应用服务器资源池化与之前的V7、V8版本有什么区别？WAS9和Liberty版本都可以支持，推荐使用Liberty。对于传统的WAS，V7、V8、V9都是通过原有的WebSphereVirtualEnterprise组件实现动态资源池；但是对于Liberty，更多的资源池是通过Docker实现的。镜像下载地址为：https://registry.hub.docker.com/_/websphere-liberty/10。使用什么配置服务器来承载资源池，安装什么操作系统？Power和X86都可以支持，而且可以超过如果架构集成支持，怕是打不死你:)11.在某个资源下，池化多个应用对应的WASCluster.会有竞争，资源会突然不足，导致多个应用无法接收用户请求。这样的话，遇到池化的情况，怎么处理，怎么避免，怎么优化呢？这是一个很好的问题，可能会发生什么，所以在pooling的时候，我们的前端有一个机制来判断。当CPU超过某个设定的阈值后，新的请求将不允许进入，避免出现所有人都无法访问的情况。同时给出一个警告，加硬件加硬件才是王道……WASV7&V8停止支持时间表V8将逐渐退出历史舞台。对于从V8迁移到V9，专家给出建议：逐步迁移，比如先在新机器上安装部署V9，然后把应用迁移到那边，前端做分发请求，老的慢慢关机重启，然后用于其他系统的V9迁移，这样即使迁移到V9出现问题，你的V8仍然可用，只能重启服务对外服务，更安全！迁移工具链接：WebSphere迁移策略-https://www-01.ibm.com/support/docview.wss?uid=swg27008724迁移决策支持工具-http://whichwas.mybluemix.netWebSphereApplicationServer迁移发现工具-https://www-01.ibm.com/marketing/iwm/dre/signup?source=mrs-form-3089&S_PKG=ov50193WAS迁移工具包概述：http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/WAS8.5WebSphere迁移指南-http://www.redbooks.ibm.com/redpieces/abstracts/sg248048.html(1)2018年12月之后，JavaSDK6支持仅限于“使用和已知缺陷”(2)WASonz/OSEOM将于2017年2月发布。公告发生在2016年6月。(3)WebSphereApplicationServerLiberty为所有产品版本提供单一支持流。支持佛r带有Liberty的JavaSE6将于2017年9月结束，以允许Liberty代码和包含的开源包向前发展。
