前面我们简单地介绍了京东PaaS云平台，本文继续剖析京东云引擎核心技术。

JAE用safemode+ACL实现了某种意义上的访问控制。为什么说是某种意义上的？它虽然提供了一些功能，但是没有Namespace的概念，在特定的Namespace中，PID、IPC、Network都是全局性的，每个Namesapce里面的资源对其他Namesapce都是透明的，而safemode+ACL则是一种共享的方案。Namespace问题也是后来JAE升级的主要原因。

其次说到资源隔离，一个应用用到的系统资源大概有内存、CPU、磁盘和带宽等。JAE借鉴warden的方案，使用linux内核自带的cgroup 和quota来解决内存、CPU、磁盘的隔离问题。

下面，借此机会介绍warden的实现细节。

warden实现原理

cgroup（Control Group）是Linux内核的功能，简单的说，它是对进程进行分组，然后以组为单位进行资源调试与分配，其结构是树形结构，每个root管理着自己下面的所有分支，而且分支共享着root的资源。由各个子系统控制与监控这些组群。cgroup的子系统有: CPU、CPUset、CPUacct、memory、devices、blkio、net-cls、freezer，不同的linux内核版本，提供的子功能有所差异。

cgroup的系统目录位于 /sys/fs/cgroup，JAE宿主机是ubuntu12.04 LTS，默认的有以下几个子系统：CPU、CPUacct、devices、freezer、memory

当dea启动的时候，会重新初始化cgroup，重新mount子系统。

将cgroup系统安装在/tmp/container/cgroup下，mount了4个子系统。当部署一个应用时，/tmp/container/cgroup/memory目录生成此应用的进程节点，命名为#{instance_name}-#{instance_index}-#{instance_id}，即“应用名-应用实例号-实例id”，将应用的内存配额写入memory.limit_in_bytes以及memory.memsw.limit_in_bytes。限制了可使用的最大内存以及swap值。

接着将实例的进程ID写入各个子系统的tasks文件中，注意到每个子模块的notify_on_release都设置为1，这是告诉cgroup，如果应用消耗的资源超过限制，就kill掉进程。Warden中写了个OomNotifier服务来监控内存的消耗情况，然后做具体操作。个人觉得太复杂，可能OomNotifier有更“温柔”的处理方法或有更多逻辑处理。但是目前来看，OomNotifier 只是做了kill操作。

JAE为什么对内存设置了配额，而对CPU子系统没有设置呢？因为在JAE环境中，应用主要以内存消耗为主，而且CPU如果要设置配额，只能设置占用时间的比例，在逻辑上就无法更直观地为某个应用分配CPU资源，所以就采用了“平均分配”的原则。如果一台虚拟机上只有一个应用实例，那么此应用实例可以“独享”所以CPU资源，如果有两个应用实例，各自最多只能用50%，以此类推。 CPU的使用率是过去一段时间内，应用实例占用的CPU时间/总时间。

接下来说到磁盘配额，JAE使用了linux内核的Quota。Quota可以对某一分区下指定用户或用户组进行磁盘限额。限额不是针对用户主目录，而是针对这个分区下的用户或用户组。Quota通过限制用户的blocks或者inodes超到限额的作用。

Quota的初始化同样发生在启动dea时，在此之前，要先安装quota，并指定要进行quota管理的分区，这里用$1传参。

当部署一个应用实例时，quota设置磁盘配额。上面vcap safemode提到，每个实例都分配一个用户，而quota就是对此用户的配额管理。Quota管理blocks和inodes有hard和soft两个临界点，超过soft值，可允许继续使用，若超过hard值，就不再允许写入操作了。

Block和inode都给了512M的缓冲值。因为实例停止或删除后，用户会回收，所以此用户的quota需要重置。Repquota -auvs 查看磁盘使用情况：

通过使用cgroup、quota、ACL，JAE间接地实现了warden的部分功能，上面提到的Namespace问题，由于ACL的限制，应用无法使用系统命令，但是从应用的角度，实例应该跑在一个运行环境完备的操作系统(container)上，可以做任何事情，而不是有各种限制。

JAE第一版于2013 年6月上线，维持了两个月之后，我们越来越意识到Namespace的重要性。此后，我们又花了一个月的时间，在Cloud Foundry v2的基础上，将JAE第一版的功能全部迁移过来，用warden来实现访问控制与资源隔离，JAE第二版于2013年9月中旬上线。

在升级的过程中，我们发现了Cloud Foundry v1与v2的诸多不兼容问题。譬如，v2引入了organization、spaces、domain的概念；router用go重写，去掉了nginx，导致flume收集nginx日志方案重新设计；v2的cloudcontroller restful api的变化，dashboard几乎是重写的；运行在warden内部的应用，没有权限直接读取日志文件；在v1上运行的应用，大部分不能运行在v2上，为此我们做了个转化部署的自动化工具，将v1上的应用迁移至v2上。 添加了php和python的buildpack，并做了定制。

在JAE的部署方面，由于底层的openstack环境做了较多改进，接口也发生了一些变化，Bosh原生的openstack CPI可能满足不了要求，我们决定放弃Bosh，采用更简单的capistrano来做集群部署，JAE集群数目则通过手动去扩展。

总结

虽然京东云擎正处于发展的初级阶段，但是我们坚信未来有充分的发展空间，我们计划后续要做的工作有：

1. 用户自定义域名的绑定；
2. 智能路由和智能启动，将负载计算多元化，更能体现后端实例的真实负载；
3. 持久化的分布式文件系统，保证应用实例保持在本地的数据不会丢失；
4. 智能启动或重启停止应用时使用snapshot，保证现场环境的完整性；
5. .nats cluster，避免nats单点；

本文旨在讲述京东云引擎对Cloud Foundry的重要扩展，升级改造过程以及定制的功能，介绍了基于Cloud Foundry的若干核心技术。不足或错误之处，还望读者批评指正。