基于JWS的统一资源调度框架实现
JWS是公司基于play框架实现一套web应用开发框架，对web开发的多方面都进行了封装。在JAVA开发中，play框架有着广泛的使用，它实现了对网络模型，业务线程池管理，MVC框架支持、数据库连接支持，cache的支持，还有一点就是支持java动态编译的机制，这点在一些少量的前端服务应用中，对业务升级有着很大的意义。在实际应用，大量的分库导致框架重启的时候会产生大量的创建连接池时间消耗，这个对应用是无法接受的。PLAY框架如下：
公司的在play框架的基础上，再结合自身业务的特点，实现更多的组件化需求。比如说支持websocket、支持fastdfs、支持分布式mq、支持redis、支持配置标准化集中管理，甚至我们规划的在框架中集成名字服务的功能等等。在当前的游戏中心所有一级和二级业务，我们都统一接入这个标准化框架。标准化之后，给运维工作带来了极大的便利，包括现在我们正在推动的配置标准化和规范化、以及统一接入mysql高可用等等，在此基础上，我们正在建设服务化的运维管理平台，第一次让自己觉得持续集成理念可以得到完整的实现。JWS框架如下：
有了JWS统一的web服务框架做基础，我们运维也便有了更多的想象空间，特别是在服务化和统一资源调度方面。在之前，我一直心中在设想如何实现这一目标。因此也结合之前的工作经验，总结了四个层次，在不同层次资源调度实现的难点和技术点都有所不同，其实最大的不同是它们实现的轻量级程度有所不同。
第一个层次，基于物理机的资源调度。这个调度非常难，特别是没有做应用环境的标准化的情况下，并且还要实现对环境非常精细的管理，实现成本非常高。我们知道要把一个应用环境从A主机迁移到B主机，此时只能做应用的全环境部署，比如说发布代码、开通权限、配置环境等等；另外资源的管理没法细粒度控制，特别是在没有统一访问框架的基础上。没有资源的管理，也就意味着无法做资源的分配和调度。简单粗暴的资源调度意味着服务的风险，一种无法错峰服务压力带来的风险。
第二个层次，虚拟化。当前的虚拟化的方案很多，比如说kvm、xen，基于这些虚拟化技术，做整机的服务镜像。这个地方也会带来一些问题和难点，一是虚拟化对物理资源有一定的消耗；二则、开源虚拟化技术如果要达到一个成熟海量部署要求，需要做大量的定制和开发，提供从前端管理到后端资源监控、服务管理等需要完整的方案。并且在核心业务上运行，一定是慎之又慎，特别是在高访问量业务模型之下；三则、当前的趋势都在使用openstack虚拟化+统一块存储的方案，而openstack的体系非常庞大，如果没有运维研发的支持，无法在生成环境上运行。虚拟化在资源预分配的模式下隔离了资源的使用，同时可以通过虚拟化技术动态收缩资源的使用，是一种粗粒度的资源调度。
第三个层次，类LXC技术的虚拟化。这个虚拟化技术的基础是cgroup，通过cgroup来限制和隔离资源的使用，可以轻松实现文件、资源、网络等资源的隔离。当前在这领域最火的便是docker，Docker是一种增加了高级API的LinuX Container（LXC）技术，提供了能够独立运行Unix进程的轻量级虚拟化解决方案。它提供了一种在安全、可重复的环境中自动部署软件的方式。Docker的实现目标就是一次装载，四处运行，类似于集装箱的模式一样。不过当前这个方案非常的不成熟，正式版到现在还未推出。
第四个层次，应用级服务化方式。在统一的框架服务支持之下，应用以服务库的形式实现到框架之中，以独立的进程对外提供服务。在框架层面上，可以做统一的资源限制，网络协议的处理，名字服务支持、服务Qos保证等等。可以举个简单的例子，就是nginx+php fastcgi模式，nginx统一做http协议的处理，然后以fastcgi的形式转发给后端的php进程处理，每个php进程实现一个或者一组服务。此时nginx充当了协议网关、路由网关、Qos网关等等作用。当然这在这个层次无法做统一的资源调度，因为fastcgi进程已经脱离容器运行，无法统一的进行资源监控和调度处理。在JWS框架中，应用的服务存在就单纯得多，应用的开发只需要关注业务本身，更多的底层服务都已经被框架统一管理和接管。特别是名字服务、容错调度、Qos、服务降级等等。当然当前的框架模型中，没有实现服务资源的统一上报和集中管理。
在前面讨论的四个层次中，个人倾向于第四种的集群调度框架实现，实现简单，另外扩展性很好，但无法成为一个通用的解决方案，因为一定程度上都需要应用程序的配合修改。在回到每个成规模的公司里面肯定都会有一个这样的框架存在，有了这个框架基础，可以完整的实现这样的调度实现。统一服务调度框架如下：
针对该图，我们可以一一的拆解其中的框架细节。
1、JWS部署网关。可以认为是一个工作任务管理中心，它接收来着客户端或者集群事件的事件请求，根据事件请求确定资源调整策略，从而发起向集群发起调度请求。另外对发起的涉及代码变更类事务，可以通过JWS网关来统一进行服务代码的上传，在JWS网关中统一的服务代码的版本进行控制管理。
2、资源管理控制台。资源管理控制台的几个重要职责，第一它是集群整个资源管理中心，它知道集群任何节点级和服务级的资源状态。第二、它是一个统一的名字服务中心，在集群规模不大的情况下，比如说游戏中心，这个服务可以放在一起，也可以独立zookeeper集群实现；第三、对网关的变更事件作出资源分配的响应。
3、节点管理。负责节点的资源状态上报和节点心跳上报，在一个动态运行的环境中，节点资源和服务资源的使用状态，必须要动态上报到资源管理节点，从而确保资源节点未来的决策是准确的。
4、JWS master。负责对业务服务程序的监控、状态的检测和上报等等。当业务程序部署到节点上之后，服务程序的获取，服务程序的启动、服务程序的异常处理都是由JWS master来完成的。
5、分布式文件系统（服务库）。我们把业务所有的程序都抽象成一个一个的服务库，这些独立的服务库可以是一个程序，也可以是一个动态运行库，他们有严格的版本管理。
简单来说，其实统一调度服务框架其实不是太难实现，因为JWS框架有了一切的基础，完全可以达到。后续我还要多和框架组多沟通沟通，争取实现这一模型。
PS：第一张图片是最近看得一个非常唯美和让人深思的电影，来自韩国金基德的《春夏秋冬又一春》。春夏秋冬如同佛教之中的生命轮回之感，而在电影之中很多台词印象特别深刻“我们忘了我们喜欢的，别人也会喜欢...”“你背上石头难受，你怎么知道鱼、青蛙、蛇不难受呢”“爱让你有了占有的欲望....”，反复在告诫世人要放下。