京東PaaS平臺的主要服務對象是兩類人群，一類是個人開發者，二類是京東的ISV。在數據開放平臺日益成熟的背景下，他們都希望以最低的成本，方便地部署自己的應用，提高生產力。而京東PaaS平臺正是以滿足開發者和ISV的這一需求而開發的。
京東PaaS平臺的核心是JAE（Jingdong App Engine），它以Cloud Foundry為內核，之所以選擇Cloud Foundry，是因為Cloud Foundry是最早開源，在社區里最成熟、最活躍的基礎PaaS平臺。為了給開發者提供更加便捷的服務，JAE將基礎服務云化，接入各種應用組件服務，諸如高可用MySQL服務、Redis緩存集群服務、以及消息隊列等；此外，它結合應用開發工具，為開發者提供了類github的代碼托管服務，云測試和Java工程云端編譯，以及資源統計信息，讓開發者可以更專注于自己的代碼業務。再者，JAE對托管在平臺上的應用進行健康監控，支持查看應用日志，提供其它安全服務。讓開發者只需關心自己應用代碼，而其它一切事情，都由JAE為其提供，極大地提高了開發者的效率，降低了開發成本。下圖描述了JAE與PaaS平臺用戶及其他相關服務之間的關系。
JAE還根據京東PaaS平臺的需求，做了許多有針對性的功能擴展。本文主要就JAE的核心技術點展開討論，JAE的其它基礎服務將參見其官方網站：
智能路由（Load Balance）
我們知道，Cloud Foundry支持設置應用的實例個數。但是，當并發量增大時，請求（Request）是否能夠均勻地分配給后端的實例？針對多實例的應用，Cloud Foundry采用隨機策略地響應客戶端的請求，并不能公平有效地利用實例資源，在并發量峰值時候，存在發生雪崩的可能性。為解決這一潛在問題，JAE借鑒了nginx的路由策略，采用權重（weight）算法，負載越小的實例越有機會響應請求。那么，我們需要進一步解決的問題是：如何計算實例的負載，以及如何在接收請求之后對其進行分流？
下圖是JAE的模塊關系圖：
所有請求首先到達router模塊，router保存所有實例的路由信息（即實例的ip和port），并由它決定由哪個實例來響應請求。每個實例的ip和port信息都是dea模塊經過nats消息總線轉發給router的，其實現原理是：dea將自身服務器上的所有實例信息發給nats，router訂閱了這則消息，收到之后保存在路由表中，通過過期失效機制來定期獲得最新的實例信息。
為使router獲得各實例的負載信息。我們對dea模塊進行改造，在其每次向nats發送消息的時候，將實例在這一時刻的負載信息也“捎帶”上。dea模塊收集dea服務器本身以及所有實例的CPU使用率、內存使用率、I/O等原始信息，一并發送給router。router決定如何從這些原始數據中計算出負載值。
至于采用何種算法來計算負載，這是router自身的職責范圍，我們采用了類似下面的算法：
實例真實負載 = ( vm負載 * 30% + 實例負載 * 70% ) * 100% vm負載 = CPU 已使用% * 30% + Mem 已使用% * 30% 實例負載 = CPU 已使用% * 30% + Mem 已使用% * 30%
在上述算法中，我們在計算實例的負載值時考慮了dea的因素，其原因在于dea實際就是服務器（虛擬機），而實例運行在dea上的各個進程之上。如果某個dea的負載很高，而其上的某個實例的負載卻很低，此時router不一定會將請求交給這個實例。所有算法都要考慮dea的感受。
每個應用實例的負載值計算出來之后，如何決定哪個實例可以優先響應客戶端請求，JAE提供了以下幾個均衡策略：
從下面這段代碼可以看出，Router使用了weight策略。
有狀態的（stateful）請求不經過智能路由的處理。比如，當存在session時，第一次請求之后，服務器將響應該請求的實例信息回寫至客戶端的cookie中，當router收到該客戶端的下一次請求時，會將其轉發給同一實例。
也許有人會問，這樣做是否會影響請求的響應時間？答案是肯定的，但是影響很小，因為該算法是純數值計算，效率非常高。目前的算法只考慮了幾個常用的因素，還存在優化的空間，比如增加負載的因素，如I/O，實例帶寬使用情況等。
彈性伸縮（Auto-scaling）
接續上一話題，當并發量持續增大，通過智能路由可以均衡所有實例的負載，但如何應對實例的負載持續升高，面臨應用隨時不可用的情況？只有增加實例！雖然，我們可以通過JAE控制界面輕松地為一個應用增加或減少實例數（只要在資源滿足的情況下）。但這種純手動的方法顯然不可取，JAE將此過程自動化，所采用的就是彈性伸縮機制。
慣用的方法就是定義伸縮規則，下面這是JAE管理頁面的規則設置：
規則是用戶層面的全局定義，每個用戶可以創建多個規則，具體的應用綁定規則之后才能生效。
規則的正確執行依賴于“過去幾分鐘內，應用的平均請求次數”這一指標。我們通過實時統計來獲取這一指標，其實現流程圖如下圖所示：
所有router服務器都安裝了agent，flume集群實時收集router的nginx訪問日志，保存在redis中并定期進行清理，同時將分析結果保存在同一redis集群中，規則引擎從redis中取得數據，與此應用的規則對比，判斷是否觸發規則，之后調用cloudcontroller restful api 來擴展或縮減實例數。
將原始日志以及分析結果傳送給云日志和云監控模塊，為應用提供相應的功能。 如dashboard管理頁面上的應用日志查看，檢索；應用PV、UV監控趨勢圖等。
智能啟動（Auto-loading）
如果有80%的應用不活躍，卻一直占用著資源，就會造成極大浪費。智能啟動的含義是當某個應用在一段時間內未收到請求，則將應用暫時休眠，等下一次請求到達時，立即啟動此應用。長時間沒有請求的應用，再次訪問的時候，會有秒級的加載延遲。
如圖所示，智能啟動也用到了訪問日志的計算結果，計算的是每個應用在統計周期內的訪問次數，同樣保存在Redis集群中。智能啟動模塊從CCDB中過濾取得待處理的應用列表，依次獲取Redis關于周期內應用的總訪問次數，如發現為零則先調用cc restful api 停止應用，再將CCDB中的此應用標識為sleep狀態，同時通知Router更新路由表信息，這樣路由表中既有所有正在運行的應用實例信息，又有sleep狀態的應用信息。當Router接收到下一個訪問的時候，首先從路由表是查找對應的實例信息，發現此應用處于sleep狀態，就會激活此應用，并且立刻返回給客戶端一個正在加載頁面。這樣再刷新頁面，就可以正常訪問應用了。下表從nats message來說明模塊間的交互：
資源隔離與訪問控制
資源隔離是Cloud Foundry的精髓，應用在JAE上除了各種功能方便開發外，最重要的還是“安全感”了，資源隔離即應用之間的資源相互隔離不干擾，訪問控制是指在JAE內部，應用之間不能通過任何方式相互訪問，不能操作其它應用的代碼，但可以通過HTTP方式訪問其它應用。JAE在整個過程也做了一些嘗試，這里分享一下。
Cloud Foundry用warden來實現資源隔離與訪問控制的，但是JAE的第一個版資源隔離策略使用了vcap dev，當時沒有warden。在當時的背景下，Cloud Foundry官網還未遷移至v2版、業內的成功應用也比較少， JAE采取穩中求進的方案，即在vcap dev的基礎上，借鑒了warden思路，以此來實現資源隔離和訪問控制。下面，我們將詳細介紹JAE的第一版資源隔離實現方法，該方法部署起來所需的資源比較靈活，既支持單機部署也支持多機部署，對個人開發者有很好的借鑒參考。
如上圖所示，JAE第一版資源隔離與訪問控制的實現方式是 vcap safemode +cgroup+quota+ACL。首先，vcap safemode提供了訪問控制的功能，安全模式為dea服務器創建了n個用戶，默認是32個用戶，vap-user-11至vap-user-32，屬于vcap-dea用戶組，啟動一個應用實例就為其分配一個用戶，并將代碼目錄的擁有者設置為此用戶，實例停止則回收用戶。這樣可以簡單地保證應用間的訪問控制，不同應用（不同用戶）相互不可訪問。
vcap safemode只是設置了應用目錄的權限，限制了目錄間的訪問，但是仍然可以看到或操作大部分系統命令，系統文件，如ls, mkdir, /usr/bin，/etc/init.d/，這是很危險的。JAE通過linux的ACL（access control list）將大部分的系統命令都禁掉了，這有點殺敵一千自損八百的味道，很多應用是需要調用系統命令的。ACL的具體做法是限制了用戶組vcap-dea對絕大多數系統命令的查看、操作權限：
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集群數目則通過手動去擴展。
總結
雖然京東云擎正處于發展的初級階段，但是我們堅信未來有充分的發展空間，我們計劃后續要做的工作有：
用戶自定義域名的綁定；
智能路由和智能啟動，將負載計算多元化，更能體現后端實例的真實負載；
持久化的分布式文件系統，保證應用實例保持在本地的數據不會丟失；
智能啟動或重啟停止應用時使用snapshot，保證現場環境的完整性；
.nats cluster，避免nats單點；
