传统金融企业中，很多已经开始进行了企业私有云建设。落地的建设成果中，大部分实现了存储、网络、服务器的资源池化，而应用服务器部分更多的还是在某个应用服务器给某个应用系统使用，呈现出一定的“烟囱”式。随着应用系统的不断增加，管理这些服务器和部署其上的中间件服务代价也越来越大，将企业应用服务器资源池化，使若干应用系统可以共享使用高可用的企业级中间件服务是众多企业认可的一条解决之道。
经社区调研，中间件的资源池化面临诸多问题，比如共享资源使用冲突、应用系统之间相互影响、运维管理模式变化、功能支持等。
1、应用服务器向资源池方向发展有哪些优点?企业为什么要发展服务器资源池化?
综合提高利用系统的硬件资源，同时通过池化来保证高峰期时能够快速伸缩应对大量的请求进来。
池化在开发、运维等环节上节约时间与成本，加速应用的迭代开发与新版本的上线发布运行。
2、应用服务器实现资源池化，是不是类似于中间件的数据源?
可以这么理解，但是应用服务器的资源池化的粒度更大一些，应当说是相当大!
主要体现于可伸缩性以及快速的部署与运行。
3、服务器资源池化会面临哪些问题?
面临的首要问题是应用支持不支持集群化的部署，然后就是管理的问题。
4、核心系统中间件部署在资源池上有哪些风险点?
风险点在于：
（1）资源池监控以及动作的响应上面要及时，也就是说要以预防为主，配置好应对的策略!
（2）应用系统本身的健壮性，当有问题时能够让资源池进行隔离与日志抓取，以用来问题的根源分析
5、对于核心交易系统来说资源冗余是安全生产的必要保证，如果对其进行资源池化，怎么样保证资源池化配置达到与现阶段资源冗余一样的安全生产目的，怎么打消运维人员这方面的疑虑?
（1）说明池化的作用以及带来的好处于坏处
（2）在测试环境上验证，达需求后再上生产
（3）新技术在发展，多学多用点总有好处
6、资源池的高可用和高稳定性如何去保障?
核心系统应用服务器来实现资源池化，当前资源池的高可用和稳定性是否可用满足，预期故障如何应对，这应该是十分关键的
应用服务器资源池化之后，实现上的只是资源发布的形式有所变更，高可用和稳定性的实现机制仍沿用之前的。
只不过，应用服务器资源池化之上再增加健康检测机制来进行自我治愈，当某一台出现问题，就进行隔离或删除，再启动一台进行对外服务，前端的分发器自动识别后端的服务变化，从而达到应用服务器资源池化后的高可用和稳定性。
7、应用服务器实现资源池化场景中，如何保证对应用接口调用的安全认证?如何保证不同应用需求的资源能够得到安全性保证，权限细分，认证访问控制等等，这些方面是如何控制的?
虽然在应用服务器实现资源池化，但是对应用接口调用的安全认证这些并不需要变化，仍按照原有的应用系统本身的安全设计进行即可，不需要随着池化而变化;权限细分，认证访问控制仍是在应用程序这一层面进行考虑。
8、“WebSphere Application Server实现资源池化”是指什么池化?
这个历史久远可以从原来的WebSphere Virtual Enterprise产品开始讲
（1）传统方式我们是有设计在运行的多个静态集群，由于各个集群在不同的时间段时资源的利用率不一样，造成资源高低不一样，过高的导致问题，过低的又浪费;于是后来就为了一个动态集群，成为了池，谁要用的多，谁就多启动几个WAS实例来应对，谁的请求少了，就关掉几台WAS实例，从而达到动态调节的作用，即池化;
（2）后来又加强了，可以再动态启动一个操作系统的虚拟机并启动WAS来应对请求;
（3）现在除了第1、2种之后，由于技术的发展，就更进一步了，还可以通过Docker容器技术来启动或停止多个实例，从而达到均衡应对外部请求的目的。
总结：在同等的硬件下，通过池化来快速提供中间件基础服务为应用程序提供运行环境，充分与均衡地提高硬件的利用率，也来保证系统的稳定性与高可用
9、WAS应用服务器资源池支持的版本是多少?应用服务器资源池化在V9版本和之前的V7、V8版本有何方式方法上的不同?
WAS 9与Liberty的各个版本都可以支持，建议用用Liberty。
对于传统的WAS来讲，V7、V8、V9都是通过原来的WebSphere Virtual Enterprise这个组件来实现动态资源池的;
但是对于Liberty来讲，更多的是通过Docker来进行资源池。
镜像下载地址为：https://registry.hub.docker.com/_/websphere-liberty/
10、资源池用什么配置的服务器去承载，安装什么操作系统?
Power与X86均可以支持，而且可以超架构进行整合支持，就怕玩不死你：)
11、在一定资源下，多个应用对应的WAS Cluster池化了，如果在某个时间点上，多个应用的访问并发量同时上来，资源就会发生竞争，顿时资源不足，导致多个应用都无法接收用户请求。这种情况，在池化情况下，如果处理、如何规避、如何优化?
这是一个很好的问题与可能会发生的情况，所以在池化时，我们前端有机制进行判断，当CPU超过某一个设定的阀值后，新的请求就不让进来了，从而避免大家都无法访问的情况发生。
同时提供警告，加硬件加硬件才是王道……
WAS V7 & V8 停止支持时间表
V8将慢慢退出历史舞台，针对从V8迁移至V9，专家给出的建议方式是：
逐步迁移，比如先在新机器上安装部署V9，然后应用迁移过去，前端进行分发请求，旧的慢慢关停并转，然后用于其他系统的V9迁移，这样即使在迁移到V9上有问题时，你的V8还在，只能重新启动就可以对外服务，比较稳妥!
迁移工具链接：
WebSphere Migration Strategy - https://www-01.ibm.com/support/docview.wss?uid=swg27008724
Migration Decision Support Tool - http://whichwas.mybluemix.net
WebSphere Application Server Migration Discovery Tool - https://www-01.ibm.com/marketing/iwm/dre/signup?source=mrs-form-3089&S_PKG=ov50193
WAS Migration Toolkit overview: http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/
WAS 8.5 WebSphere Migration Guide - http://www.redbooks.ibm.com/redpieces/abstracts/sg248048.html
(1)After December 2018, Java SDK 6 support is limited to ‘usage & known defects’
(2)WAS on z/OS EOM will be Feb 2017. Announcement occurred in June 2016.
(3)WebSphere Application Server Liberty has a single support stream for all product versions. Support for Java SE 6 with Liberty will end in September 2017 to allow the Liberty code and included open source packages to move forward.
