京東PaaS平臺(tái)的主要服務(wù)對(duì)象是兩類人群，一類是個(gè)人開發(fā)者，二類是京東的ISV。在數(shù)據(jù)開放平臺(tái)日益成熟的背景下，他們都希望以最低的成本，方便地部署自己的應(yīng)用，提高生產(chǎn)力。而京東PaaS平臺(tái)正是以滿足開發(fā)者和ISV的這一需求而開發(fā)的。
京東PaaS平臺(tái)的核心是JAE（Jingdong App Engine），它以Cloud Foundry為內(nèi)核，之所以選擇Cloud Foundry，是因?yàn)镃loud Foundry是最早開源，在社區(qū)里最成熟、最活躍的基礎(chǔ)PaaS平臺(tái)。為了給開發(fā)者提供更加便捷的服務(wù)，JAE將基礎(chǔ)服務(wù)云化，接入各種應(yīng)用組件服務(wù)，諸如高可用MySQL服務(wù)、Redis緩存集群服務(wù)、以及消息隊(duì)列等；此外，它結(jié)合應(yīng)用開發(fā)工具，為開發(fā)者提供了類github的代碼托管服務(wù)，云測(cè)試和Java工程云端編譯，以及資源統(tǒng)計(jì)信息，讓開發(fā)者可以更專注于自己的代碼業(yè)務(wù)。再者，JAE對(duì)托管在平臺(tái)上的應(yīng)用進(jìn)行健康監(jiān)控，支持查看應(yīng)用日志，提供其它安全服務(wù)。讓開發(fā)者只需關(guān)心自己應(yīng)用代碼，而其它一切事情，都由JAE為其提供，極大地提高了開發(fā)者的效率，降低了開發(fā)成本。下圖描述了JAE與PaaS平臺(tái)用戶及其他相關(guān)服務(wù)之間的關(guān)系。

JAE還根據(jù)京東PaaS平臺(tái)的需求，做了許多有針對(duì)性的功能擴(kuò)展。本文主要就JAE的核心技術(shù)點(diǎn)展開討論，JAE的其它基礎(chǔ)服務(wù)將參見(jiàn)其官方網(wǎng)站：
智能路由（Load Balance）
我們知道，Cloud Foundry支持設(shè)置應(yīng)用的實(shí)例個(gè)數(shù)。但是，當(dāng)并發(fā)量增大時(shí)，請(qǐng)求（Request）是否能夠均勻地分配給后端的實(shí)例？針對(duì)多實(shí)例的應(yīng)用，Cloud Foundry采用隨機(jī)策略地響應(yīng)客戶端的請(qǐng)求，并不能公平有效地利用實(shí)例資源，在并發(fā)量峰值時(shí)候，存在發(fā)生雪崩的可能性。為解決這一潛在問(wèn)題，JAE借鑒了nginx的路由策略，采用權(quán)重（weight）算法，負(fù)載越小的實(shí)例越有機(jī)會(huì)響應(yīng)請(qǐng)求。那么，我們需要進(jìn)一步解決的問(wèn)題是：如何計(jì)算實(shí)例的負(fù)載，以及如何在接收請(qǐng)求之后對(duì)其進(jìn)行分流？
下圖是JAE的模塊關(guān)系圖：

所有請(qǐng)求首先到達(dá)router模塊，router保存所有實(shí)例的路由信息（即實(shí)例的ip和port），并由它決定由哪個(gè)實(shí)例來(lái)響應(yīng)請(qǐng)求。每個(gè)實(shí)例的ip和port信息都是dea模塊經(jīng)過(guò)nats消息總線轉(zhuǎn)發(fā)給router的，其實(shí)現(xiàn)原理是：dea將自身服務(wù)器上的所有實(shí)例信息發(fā)給nats，router訂閱了這則消息，收到之后保存在路由表中，通過(guò)過(guò)期失效機(jī)制來(lái)定期獲得最新的實(shí)例信息。
為使router獲得各實(shí)例的負(fù)載信息。我們對(duì)dea模塊進(jìn)行改造，在其每次向nats發(fā)送消息的時(shí)候，將實(shí)例在這一時(shí)刻的負(fù)載信息也“捎帶”上。dea模塊收集dea服務(wù)器本身以及所有實(shí)例的CPU使用率、內(nèi)存使用率、I/O等原始信息，一并發(fā)送給router。router決定如何從這些原始數(shù)據(jù)中計(jì)算出負(fù)載值。
至于采用何種算法來(lái)計(jì)算負(fù)載，這是router自身的職責(zé)范圍，我們采用了類似下面的算法：
實(shí)例真實(shí)負(fù)載 = ( vm負(fù)載 * 30% + 實(shí)例負(fù)載 * 70% ) * 100% vm負(fù)載 = CPU 已使用% * 30% + Mem 已使用% * 30% 實(shí)例負(fù)載 = CPU 已使用% * 30% + Mem 已使用% * 30%
在上述算法中，我們?cè)谟?jì)算實(shí)例的負(fù)載值時(shí)考慮了dea的因素，其原因在于dea實(shí)際就是服務(wù)器（虛擬機(jī)），而實(shí)例運(yùn)行在dea上的各個(gè)進(jìn)程之上。如果某個(gè)dea的負(fù)載很高，而其上的某個(gè)實(shí)例的負(fù)載卻很低，此時(shí)router不一定會(huì)將請(qǐng)求交給這個(gè)實(shí)例。所有算法都要考慮dea的感受。
每個(gè)應(yīng)用實(shí)例的負(fù)載值計(jì)算出來(lái)之后，如何決定哪個(gè)實(shí)例可以優(yōu)先響應(yīng)客戶端請(qǐng)求，JAE提供了以下幾個(gè)均衡策略：

從下面這段代碼可以看出，Router使用了weight策略。

有狀態(tài)的（stateful）請(qǐng)求不經(jīng)過(guò)智能路由的處理。比如，當(dāng)存在session時(shí)，第一次請(qǐng)求之后，服務(wù)器將響應(yīng)該請(qǐng)求的實(shí)例信息回寫至客戶端的cookie中，當(dāng)router收到該客戶端的下一次請(qǐng)求時(shí)，會(huì)將其轉(zhuǎn)發(fā)給同一實(shí)例。
也許有人會(huì)問(wèn)，這樣做是否會(huì)影響請(qǐng)求的響應(yīng)時(shí)間？答案是肯定的，但是影響很小，因?yàn)樵撍惴ㄊ羌償?shù)值計(jì)算，效率非常高。目前的算法只考慮了幾個(gè)常用的因素，還存在優(yōu)化的空間，比如增加負(fù)載的因素，如I/O，實(shí)例帶寬使用情況等。
彈性伸縮（Auto-scaling）
接續(xù)上一話題，當(dāng)并發(fā)量持續(xù)增大，通過(guò)智能路由可以均衡所有實(shí)例的負(fù)載，但如何應(yīng)對(duì)實(shí)例的負(fù)載持續(xù)升高，面臨應(yīng)用隨時(shí)不可用的情況？只有增加實(shí)例！雖然，我們可以通過(guò)JAE控制界面輕松地為一個(gè)應(yīng)用增加或減少實(shí)例數(shù)（只要在資源滿足的情況下）。但這種純手動(dòng)的方法顯然不可取，JAE將此過(guò)程自動(dòng)化，所采用的就是彈性伸縮機(jī)制。
慣用的方法就是定義伸縮規(guī)則，下面這是JAE管理頁(yè)面的規(guī)則設(shè)置：

規(guī)則是用戶層面的全局定義，每個(gè)用戶可以創(chuàng)建多個(gè)規(guī)則，具體的應(yīng)用綁定規(guī)則之后才能生效。
規(guī)則的正確執(zhí)行依賴于“過(guò)去幾分鐘內(nèi)，應(yīng)用的平均請(qǐng)求次數(shù)”這一指標(biāo)。我們通過(guò)實(shí)時(shí)統(tǒng)計(jì)來(lái)獲取這一指標(biāo)，其實(shí)現(xiàn)流程圖如下圖所示：

所有router服務(wù)器都安裝了agent，flume集群實(shí)時(shí)收集router的nginx訪問(wèn)日志，保存在redis中并定期進(jìn)行清理，同時(shí)將分析結(jié)果保存在同一redis集群中，規(guī)則引擎從redis中取得數(shù)據(jù)，與此應(yīng)用的規(guī)則對(duì)比，判斷是否觸發(fā)規(guī)則，之后調(diào)用cloudcontroller restful api 來(lái)擴(kuò)展或縮減實(shí)例數(shù)。
將原始日志以及分析結(jié)果傳送給云日志和云監(jiān)控模塊，為應(yīng)用提供相應(yīng)的功能。 如dashboard管理頁(yè)面上的應(yīng)用日志查看，檢索；應(yīng)用PV、UV監(jiān)控趨勢(shì)圖等。
智能啟動(dòng)（Auto-loading）
如果有80%的應(yīng)用不活躍，卻一直占用著資源，就會(huì)造成極大浪費(fèi)。智能啟動(dòng)的含義是當(dāng)某個(gè)應(yīng)用在一段時(shí)間內(nèi)未收到請(qǐng)求，則將應(yīng)用暫時(shí)休眠，等下一次請(qǐng)求到達(dá)時(shí)，立即啟動(dòng)此應(yīng)用。長(zhǎng)時(shí)間沒(méi)有請(qǐng)求的應(yīng)用，再次訪問(wèn)的時(shí)候，會(huì)有秒級(jí)的加載延遲。

如圖所示，智能啟動(dòng)也用到了訪問(wèn)日志的計(jì)算結(jié)果，計(jì)算的是每個(gè)應(yīng)用在統(tǒng)計(jì)周期內(nèi)的訪問(wèn)次數(shù)，同樣保存在Redis集群中。智能啟動(dòng)模塊從CCDB中過(guò)濾取得待處理的應(yīng)用列表，依次獲取Redis關(guān)于周期內(nèi)應(yīng)用的總訪問(wèn)次數(shù)，如發(fā)現(xiàn)為零則先調(diào)用cc restful api 停止應(yīng)用，再將CCDB中的此應(yīng)用標(biāo)識(shí)為sleep狀態(tài)，同時(shí)通知Router更新路由表信息，這樣路由表中既有所有正在運(yùn)行的應(yīng)用實(shí)例信息，又有sleep狀態(tài)的應(yīng)用信息。當(dāng)Router接收到下一個(gè)訪問(wèn)的時(shí)候，首先從路由表是查找對(duì)應(yīng)的實(shí)例信息，發(fā)現(xiàn)此應(yīng)用處于sleep狀態(tài)，就會(huì)激活此應(yīng)用，并且立刻返回給客戶端一個(gè)正在加載頁(yè)面。這樣再刷新頁(yè)面，就可以正常訪問(wèn)應(yīng)用了。下表從nats message來(lái)說(shuō)明模塊間的交互：

資源隔離與訪問(wèn)控制
資源隔離是Cloud Foundry的精髓，應(yīng)用在JAE上除了各種功能方便開發(fā)外，最重要的還是“安全感”了，資源隔離即應(yīng)用之間的資源相互隔離不干擾，訪問(wèn)控制是指在JAE內(nèi)部，應(yīng)用之間不能通過(guò)任何方式相互訪問(wèn)，不能操作其它應(yīng)用的代碼，但可以通過(guò)HTTP方式訪問(wèn)其它應(yīng)用。JAE在整個(gè)過(guò)程也做了一些嘗試，這里分享一下。
Cloud Foundry用warden來(lái)實(shí)現(xiàn)資源隔離與訪問(wèn)控制的，但是JAE的第一個(gè)版資源隔離策略使用了vcap dev，當(dāng)時(shí)沒(méi)有warden。在當(dāng)時(shí)的背景下，Cloud Foundry官網(wǎng)還未遷移至v2版、業(yè)內(nèi)的成功應(yīng)用也比較少， JAE采取穩(wěn)中求進(jìn)的方案，即在vcap dev的基礎(chǔ)上，借鑒了warden思路，以此來(lái)實(shí)現(xiàn)資源隔離和訪問(wèn)控制。下面，我們將詳細(xì)介紹JAE的第一版資源隔離實(shí)現(xiàn)方法，該方法部署起來(lái)所需的資源比較靈活，既支持單機(jī)部署也支持多機(jī)部署，對(duì)個(gè)人開發(fā)者有很好的借鑒參考。

如上圖所示，JAE第一版資源隔離與訪問(wèn)控制的實(shí)現(xiàn)方式是 vcap safemode +cgroup+quota+ACL。首先，vcap safemode提供了訪問(wèn)控制的功能，安全模式為dea服務(wù)器創(chuàng)建了n個(gè)用戶，默認(rèn)是32個(gè)用戶，vap-user-11至vap-user-32，屬于vcap-dea用戶組，啟動(dòng)一個(gè)應(yīng)用實(shí)例就為其分配一個(gè)用戶，并將代碼目錄的擁有者設(shè)置為此用戶，實(shí)例停止則回收用戶。這樣可以簡(jiǎn)單地保證應(yīng)用間的訪問(wèn)控制，不同應(yīng)用（不同用戶）相互不可訪問(wèn)。
vcap safemode只是設(shè)置了應(yīng)用目錄的權(quán)限，限制了目錄間的訪問(wèn)，但是仍然可以看到或操作大部分系統(tǒng)命令，系統(tǒng)文件，如ls, mkdir, /usr/bin，/etc/init.d/，這是很危險(xiǎn)的。JAE通過(guò)linux的ACL（access control list）將大部分的系統(tǒng)命令都禁掉了，這有點(diǎn)殺敵一千自損八百的味道，很多應(yīng)用是需要調(diào)用系統(tǒng)命令的。ACL的具體做法是限制了用戶組vcap-dea對(duì)絕大多數(shù)系統(tǒng)命令的查看、操作權(quán)限：

JAE用safemode+ACL實(shí)現(xiàn)了某種意義上的訪問(wèn)控制。為什么說(shuō)是某種意義上的？它雖然提供了一些功能，但是沒(méi)有Namespace的概念，在特定的Namespace中，PID、IPC、Network都是全局性的，每個(gè)Namesapce里面的資源對(duì)其他Namesapce都是透明的，而safemode+ACL則是一種共享的方案。Namespace問(wèn)題也是后來(lái)JAE升級(jí)的主要原因。
其次說(shuō)到資源隔離，一個(gè)應(yīng)用用到的系統(tǒng)資源大概有內(nèi)存、CPU、磁盤和帶寬等。JAE借鑒warden的方案，使用linux內(nèi)核自帶的cgroup 和quota來(lái)解決內(nèi)存、CPU、磁盤的隔離問(wèn)題。
下面，借此機(jī)會(huì)介紹warden的實(shí)現(xiàn)細(xì)節(jié)。
warden實(shí)現(xiàn)原理
cgroup（Control Group）是Linux內(nèi)核的功能，簡(jiǎn)單的說(shuō)，它是對(duì)進(jìn)程進(jìn)行分組，然后以組為單位進(jìn)行資源調(diào)試與分配，其結(jié)構(gòu)是樹形結(jié)構(gòu)，每個(gè)root管理著自己下面的所有分支，而且分支共享著root的資源。由各個(gè)子系統(tǒng)控制與監(jiān)控這些組群。cgroup的子系統(tǒng)有: CPU、CPUset、CPUacct、memory、devices、blkio、net-cls、freezer，不同的linux內(nèi)核版本，提供的子功能有所差異。
cgroup的系統(tǒng)目錄位于 /sys/fs/cgroup，JAE宿主機(jī)是ubuntu12.04 LTS，默認(rèn)的有以下幾個(gè)子系統(tǒng)：CPU、CPUacct、devices、freezer、memory
當(dāng)dea啟動(dòng)的時(shí)候，會(huì)重新初始化cgroup，重新mount子系統(tǒng)。

將cgroup系統(tǒng)安裝在/tmp/container/cgroup下，mount了4個(gè)子系統(tǒng)。當(dāng)部署一個(gè)應(yīng)用時(shí)，/tmp/container/cgroup/memory目錄生成此應(yīng)用的進(jìn)程節(jié)點(diǎn)，命名為#{instance_name}-#{instance_index}-#{instance_id}，即“應(yīng)用名-應(yīng)用實(shí)例號(hào)-實(shí)例id”，將應(yīng)用的內(nèi)存配額寫入memory.limit_in_bytes以及memory.memsw.limit_in_bytes。限制了可使用的最大內(nèi)存以及swap值。

接著將實(shí)例的進(jìn)程ID寫入各個(gè)子系統(tǒng)的tasks文件中，注意到每個(gè)子模塊的notify_on_release都設(shè)置為1，這是告訴cgroup，如果應(yīng)用消耗的資源超過(guò)限制，就kill掉進(jìn)程。Warden中寫了個(gè)OomNotifier服務(wù)來(lái)監(jiān)控內(nèi)存的消耗情況，然后做具體操作。個(gè)人覺(jué)得太復(fù)雜，可能OomNotifier有更“溫柔”的處理方法或有更多邏輯處理。但是目前來(lái)看，OomNotifier 只是做了kill操作。
JAE為什么對(duì)內(nèi)存設(shè)置了配額，而對(duì)CPU子系統(tǒng)沒(méi)有設(shè)置呢？因?yàn)樵贘AE環(huán)境中，應(yīng)用主要以內(nèi)存消耗為主，而且CPU如果要設(shè)置配額，只能設(shè)置占用時(shí)間的比例，在邏輯上就無(wú)法更直觀地為某個(gè)應(yīng)用分配CPU資源，所以就采用了“平均分配”的原則。如果一臺(tái)虛擬機(jī)上只有一個(gè)應(yīng)用實(shí)例，那么此應(yīng)用實(shí)例可以“獨(dú)享”所以CPU資源，如果有兩個(gè)應(yīng)用實(shí)例，各自最多只能用50%，以此類推。 CPU的使用率是過(guò)去一段時(shí)間內(nèi)，應(yīng)用實(shí)例占用的CPU時(shí)間/總時(shí)間。
接下來(lái)說(shuō)到磁盤配額，JAE使用了linux內(nèi)核的Quota。Quota可以對(duì)某一分區(qū)下指定用戶或用戶組進(jìn)行磁盤限額。限額不是針對(duì)用戶主目錄，而是針對(duì)這個(gè)分區(qū)下的用戶或用戶組。Quota通過(guò)限制用戶的blocks或者inodes超到限額的作用。
Quota的初始化同樣發(fā)生在啟動(dòng)dea時(shí)，在此之前，要先安裝quota，并指定要進(jìn)行quota管理的分區(qū)，這里用$1傳參。

當(dāng)部署一個(gè)應(yīng)用實(shí)例時(shí)，quota設(shè)置磁盤配額。上面vcap safemode提到，每個(gè)實(shí)例都分配一個(gè)用戶，而quota就是對(duì)此用戶的配額管理。Quota管理blocks和inodes有hard和soft兩個(gè)臨界點(diǎn)，超過(guò)soft值，可允許繼續(xù)使用，若超過(guò)hard值，就不再允許寫入操作了。

Block和inode都給了512M的緩沖值。因?yàn)閷?shí)例停止或刪除后，用戶會(huì)回收，所以此用戶的quota需要重置。Repquota -auvs 查看磁盤使用情況：

通過(guò)使用cgroup、quota、ACL，JAE間接地實(shí)現(xiàn)了warden的部分功能，上面提到的Namespace問(wèn)題，由于ACL的限制，應(yīng)用無(wú)法使用系統(tǒng)命令，但是從應(yīng)用的角度，實(shí)例應(yīng)該跑在一個(gè)運(yùn)行環(huán)境完備的操作系統(tǒng)(container)上，可以做任何事情，而不是有各種限制。
JAE第一版于2013 年6月上線，維持了兩個(gè)月之后，我們?cè)絹?lái)越意識(shí)到Namespace的重要性。此后，我們又花了一個(gè)月的時(shí)間，在Cloud Foundry v2的基礎(chǔ)上，將JAE第一版的功能全部遷移過(guò)來(lái)，用warden來(lái)實(shí)現(xiàn)訪問(wèn)控制與資源隔離，JAE第二版于2013年9月中旬上線。

在升級(jí)的過(guò)程中，我們發(fā)現(xiàn)了Cloud Foundry v1與v2的諸多不兼容問(wèn)題。譬如，v2引入了organization、spaces、domain的概念；router用go重寫，去掉了nginx，導(dǎo)致flume收集nginx日志方案重新設(shè)計(jì)；v2的cloudcontroller restful api的變化，dashboard幾乎是重寫的；運(yùn)行在warden內(nèi)部的應(yīng)用，沒(méi)有權(quán)限直接讀取日志文件；在v1上運(yùn)行的應(yīng)用，大部分不能運(yùn)行在v2上，為此我們做了個(gè)轉(zhuǎn)化部署的自動(dòng)化工具，將v1上的應(yīng)用遷移至v2上。 添加了php和python的buildpack，并做了定制。
在JAE的部署方面，由于底層的openstack環(huán)境做了較多改進(jìn)，接口也發(fā)生了一些變化，Bosh原生的openstack CPI可能滿足不了要求，我們決定放棄Bosh，采用更簡(jiǎn)單的capistrano來(lái)做集群部署，JAE集群數(shù)目則通過(guò)手動(dòng)去擴(kuò)展。
總結(jié)
雖然京東云擎正處于發(fā)展的初級(jí)階段，但是我們堅(jiān)信未來(lái)有充分的發(fā)展空間，我們計(jì)劃后續(xù)要做的工作有：
用戶自定義域名的綁定；
智能路由和智能啟動(dòng)，將負(fù)載計(jì)算多元化，更能體現(xiàn)后端實(shí)例的真實(shí)負(fù)載；
持久化的分布式文件系統(tǒng)，保證應(yīng)用實(shí)例保持在本地的數(shù)據(jù)不會(huì)丟失；
智能啟動(dòng)或重啟停止應(yīng)用時(shí)使用snapshot，保證現(xiàn)場(chǎng)環(huán)境的完整性；
.nats cluster，避免nats單點(diǎn)；