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

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

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

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

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

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

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

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

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

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

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

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

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

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

Block和inode都給了512M的緩沖值。因為實例停止或刪除后，用戶會回收，所以此用戶的quota需要重置。Repquota -auvs 查看磁盤使用情況：

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

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