JAVA開發者必備：PaaS解決方案盤點

PaaS(Platform-as-a-Service)是雲服務的一種，服務提供者不僅提供按需索取的硬體和作業系統服務，還提供了應用程式平臺和解決方案棧。 對開發者而言，PaaS極大程度上減少了IT部署的開銷和痛苦，按需為應用程式提供資源，讓其更易伸縮。

JVM、應用伺服器和部署包(例如，WAR和EAR)為JAVA應用程式提供了天然的隔離，允許不同開發者在同一套基礎設施中部署應用程式，因此JAVA平臺十分適合PaaS。 但是，過去幾年裡，大多數PaaS產品都圍繞著Ruby和Python這樣的平臺，當時Google App Engine是唯一為JAVA開發者提供PaaS服務的。 幸運的是，現在的情況已經大為改善了。

差不多從去年開始，多家商務服務商進入了JAVA PaaS領域。 這一舉動很有意義，因為JAVA開發者差不多有1000萬之多，也許是世界上最大的開發者群體之一。 本文中，我們將從開發者的角度來比較這些服務提供者。 特別要說明一下，具體比較以下4個方面：

文中我們會比較以下JAVA PaaS產品(按字母排序)。

Amazon Elastic Beanstalk 是Amazon構建于EC2雲上的JAVA PaaS產品。 其中提供了運行于EC2上的受管Tomcat實例，帶有負載等化器，還可按需提供伸縮能力。 Amazon Elastic Beanstalk集成了Amazon Web Services的其他服務，能訪問受管關聯式資料庫(RDS)、大資料存儲(SimpleDB)、訊息佇列、電子郵件和其他服務。

CloudBees 是一家風投的創業公司，成員由JBoss和Sun的前雇員組成，最近在兩輪融資中共募得1400萬美元。 CloudBees也許是個新名字，不過它在這個領域中的影響力正在不斷擴大，為JAVA PaaS帶來了多項獨特的特性，尤其是持續集成——一個完整的雲端開發/部署週期管理。 此外，和Heroku一樣，它還包含一個協力廠商外掛程式和服務的市場。

Cloud Foundry 是VMware發起的一個開源產品。 VMware軟體驅動著虛擬化資料中心，這是大多數PaaS產品的基礎。 VMware還是Spring Framework的擁有者，它是在企業JAVA中非常流行的一個平臺棧。 Cloud Foundry的一個獨一無二的特性是它根本無需成為受託管的PaaS，你可以下載其代碼，自己託管PaaS!這樣一來，它既是一個託管平臺，也是一個受託管PaaS服務。

Google App Engine for JAVA 也許是市面上問世時間最長(也是最成熟)的JAVA PaaS產品。 它的目標是提供線性伸縮性，而且不擔心對JAVA平臺本身做出巨大變化。

Heroku for JAVA 是PaaS大廠Heroku最近才推出的產品，Heroku在Ruby社區頗受歡迎。

Red Hat OpenShift 是Red Hat試水PaaS的實驗性產品。 Red Hat的JBoss Application Server (AS)是最流行的JAVA應用伺服器之一，OpenShift服務提供了全面的JBoss AS支援。

支援的技術平臺和技術棧

JAVA PaaS供應商最重要的屬性之一就是它所支援的技術平臺和技術棧。 總而言之，技術平臺是JAVA PaaS區別于其他PaaS產品的地方。 在JAVA平臺的長期進化中，湧現了很多頗有競爭力的技術棧。 對於JAVA PaaS廠商而言，我相信盡可能多地支援不同技術棧是十分重要的。

這方面OpenShift和CloudBees對技術的支援面最廣，從簡單的Servlet容器(一般是Tomcat)到完整的JAVA EE 6 Web Profile(JBoss AS 7)都有支援。 JAVA PaaS先驅，Google App Engine，在標準支援方面與後來者的差距最大。 Google App Engine不支援完整的JAVA SE平臺，因此對很多流行框架的支援都很差。 它還要求使用者使用Google App Engine自己的網路和持久化API，而不是支援公開標準，這讓應用程式很難遷移。 類似的，Heroku for JAVA要求應用程式圍繞它自己的Jetty實例做封裝，打破了傳統JAVA EE應用程式的部署模型。

Cloud Foundry專案支援Tomcat容器，但它的應用程式開發和部署針對Spring Framework做了大量優化，創建了一個半外置的依賴。 因為VMware擁有Spring Framework，所以Cloud Foundry很適合基於Spring的應用程式。 此外，它還支援使用RabbitMQ 的訊息佇列，這是基於 AMQP 標準的。 但它對其他JAVA框架(例如JAVA EE)的支援很弱。

PaaS的關鍵價值之一，是讓應用程式開發者的生活更簡單，因為它消除了應用程式和資源管理的開銷。 所以說，對開發者友好，有工具集成是我們的一個重要考量點。

在這方面CloudBees無疑是贏家。 它不僅是一個PaaS運行時環境，還是一個完整的構建和測試環境。 開發者可以利用Jenkins服務讓CloudBees自動並持續地簽出、構建、測試並報告代碼庫中的代碼。 這個持續集成過程已經被運用於多個大型團隊，作為他們軟體發展過程的重要環節。 但是，構建伺服器管理對QA團隊而言是一項費時費力的工作。 CloudBees替QA團隊承擔了這份痛苦，讓這一過程對開發者更加透明。 最近，Red Hat OpenShift通過支援Maven和Jekins集成，在這個領域裡慢慢追上CloudBees了。

Amazon Beanstalk、OpenShift和Google App Engine都提供了開發工具、SDK和IDE外掛程式，與其他市面上的基於JAVA的工具保持一致。

相比JAVA開發者，Cloud Foundry和Heroku for JAVA提供了更適合Ruby開發者的工具。 試用了這些工具後，我懷疑很多JAVA開發者可能要花一些時間來適應其中的慣例和術語。 另外，Cloud Foundry目前還缺乏文檔，舉個例子，它的很多文檔還是視頻教程形式的。 雖然視頻教程很容易讓開發者上手，但在部署重要應用或希望瞭解視頻場景之外的內容時，這些內容顯然缺乏深度。 儘管Cloud Foundry平臺在最近幾年裡經歷了重大變更，但官方入門指南文檔的日期還停留在2007年。 目前已經有了更多的文檔——比如 這篇 ，但它們不該這麼難找。

另一個重要的問題，Cloud Foundry允許開發者配置自己的雲環境，部署Micro Cloud可比僅僅安裝一套SDK麻煩多了。 這也是一個障礙，讓很多開發者對Cloud Foundry望而卻步。

性能和可伸縮性

PaaS最重要的特性之一是平臺自動調整的能力，就是基於即時流量需求增加或減少伺服器容量。 這要求平臺供應商在眾多伺服器之間對請求做負載均衡，監控各台伺服器的負載，適時啟動新伺服器。

所有PaaS供應商都在一定程度上支援自動調整。 但自動擴展遠比看上去困難。 對入門使用者而言，JAVA EE應用程式必須被配置為訪問中心化外部資料庫，而不是訪問部署在同一台伺服器上的資料庫。 所有PaaS供應商的程式設計范式和工具都要強制開發者遵循這種方式。

更大的問題是HTTP會話。 在JAVA應用伺服器上，HTTP會話的會話狀態預設是在記憶體裡管理的。 要構建能在不同伺服器之間負載均衡的應用程式，開發者必須使用以下的某個方法：

配置負載等化器支援「粘性會話」(sticky session)，負載等化器會檢查所有流入請求的會話ID，總是把同一會話的請求發給相同的伺服器。 這是最簡單的方法，不過也有自己的問題：負載等化器需要完成更多的工作，久而久之負載分發會變得不再均衡，而且在負載下降時，很難撤下擴上去的基礎設施，因為每台伺服器都有自己的會話。 出於這些原因，很少有PaaS供應商支援這一方法。

為記憶體中的HTTP會話配置一個共用的緩存。 如此一來，每時每刻所有伺服器都能在記憶體裡擁有全部HTTP會話。 但是，在集群中複製記憶體會話這項任務既耗費頻寬，又消耗計算資源。 它要求應用程式開發者配置共用緩存和複寫原則。

還可以配置應用程式，將所有HTTP會話持久化到外部關聯式資料庫中。

上述所有的PaaS平臺中，Google App Engine對這一問題的處理是最好的。 它在架構上就將單一伺服器的概念抽象了出來，會自動在不同的伺服器上創建資料存儲，並預設將HTTP會話保存到資料存儲中，這一過程對開發者是透明的。 但是，Google App Engine的問題是原生的性能太差，一個Web請求要花1至3秒才能完成一次對資料庫的訪問。

Heroku for JAVA的每個伺服器實例都封裝了一個自訂的Jetty實例，因此它也提供了跨伺服器實例自動共用會話的能力。 然而，Heroku並不提供透明的自動調整，你需要觀察儀錶盤，適時為應用添加資源。

剩餘的標準JAVA PaaS產品都強制要求開發者在專門的資料庫伺服器上創建資料表，這也是部署過程的一部分。 對於HTTP會話，Cloud Foundry在負載等化器中使用了粘性會話。 正如上文討論的那樣，這種做法為開發者帶來了便利，也有一些嚴重的問題。 其他PaaS產品雖然沒有明說，但都把會話管理的工作留給了應用程式開發者。

價格及其他商業考量

對開發者而言，PaaS產品的價格是十分重要的。 大多數服務提供者都有免費服務供開發者試用，這些免費服務對較小的JAVA Web網站來說就是很好的選擇。

但是，正如Google App Engine最近的漲價風波所反映的那樣，大型Web應用程式使用PaaS的成本還是很高的。

另一個要考慮的重要因素是支援。 Google App Engine和Amazon Web Services在支援方面表現糟糕。 開發者只能自己在論壇上尋找答案。 稍小的專注于JAVA的供應商提供了更好的技術支援，在公共論壇上亦是如此。 在我看來CloudBees提供的支援最為出色，很好地結合了付費問題單的支援和支援人員間的JAVA專業技術秘訣。

文中我們討論了JAVA PaaS領域的6個知名廠商，當然，現在還有一些稍小的或不那麼有名的供應商，比如：

Jelastic：它支援很多應用伺服器和資料庫的組合，包括MySQL資料庫的多個變種和NoSQL資料庫。

WSO2 StratosLive：它是構建于WSO2應用伺服器上的PaaS產品，WSO2是一款符合JAVA EE規範的應用伺服器。

CumuLogic：它提供的JAVA 應用服務PaaS可以運行于很多私有雲和公有雲解決方案上，包含CloudStack、 OpenStack和Eucalyptus。

我們會密切注意這些小廠商，因為它們很輕鬆地就能成長起來挑戰大廠商的市場份額和關注度。

JAVA PaaS在過去的12個月裡經歷了很多，各種產品仍在快速發展，這對那些尋找低價、可伸縮、甚至是免費託管解決方案的JAVA開發者來說是個天大的好消息。 對JAVA EE開發者而言，我相信CloudBes和OpenShift是目前市面上最好的產品，考慮到OpenShift仍處在Beta階段，所以CloudBees成為了這場比賽的贏家。 如果你願意嘗試一下JAVA專業戶以外的選擇，Heroku for JAVA和Cloud Foundry(Beta)是老牌Google App Engine的有力競爭對手。 查看英文原文： A JAVA Developer’s Guide to PaaS