Java開發者PaaS指南
PaaS（Platform-as-a-Service）是云服務的一種，服務提供商不僅提供按需索取的硬件和操作系統服務，還提供了應用程序平臺和解決方案棧。對開發者而言，PaaS極大程度上減少了IT部署的開銷和痛苦，按需為應用程序提供資源，讓其更易伸縮。
</span>
JVM、應用服務器和部署包（例如，WAR和EAR）為Java應用程序提供了天然的隔離，允許不同開發者在同一套基礎設施中部署應用程序，因此Java 平臺十分適合PaaS。但是，過去幾年里，大多數PaaS產品都圍繞著Ruby和Python這樣的平臺，當時Google App Engine是唯一為Java開發者提供PaaS服務的。幸運的是，現在的情況已經大為改善了。
差不多從去年開始，多家商業服務商進入了Java PaaS領域。這一舉動很有意義，因為Java開發者差不多有1000萬之多，也許是世界上最大的開發者群體之一。本文中，我們將從開發者的角度來比較這些服務提供商。特別要說明一下，具體比較以下4個方面：
- 對技術平臺和技術棧的支持。
- 對開發者生產力和開發過程的支持。
- 性能和可伸縮性。
- 價格和其他商業考量。
</ul>
文中我們會比較以下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支持。
</ul>
支持的技術平臺和技術棧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 的消息隊列，這是基于 </span>AMQP 標準的。但它對其他Java框架（例如Java EE）的支持很弱。</span>
| |
Amazon Beanstalk
|
CloudBees
|
Cloud Foundry
|
Google App Engine
|
Heroku for Java
|
OpenShift
|
</tr>
Tomcat
|
是
|
是
|
是
|
否
|
否
|
是
|
</tr>
Java SE
|
是
|
是
|
是
|
否
|
是
|
是
|
</tr>
Java EE
|
否
|
是
|
否
|
否
|
否
|
是
|
</tr>
支持標準 Java庫
|
是
|
是
|
是
|
否
|
是
|
是
|
</tr>
文件系統訪問
|
是
|
是
|
是
|
否
|
是
|
是
|
</tr>
線程訪問
|
是
|
是
|
是
|
否
|
是
|
是
|
</tr>
對外網絡連接
|
是
|
是
|
是
|
受限
|
是
|
是
|
</tr>
MySQL
|
RDS
|
是
|
是
|
付費方案
|
是
|
是
|
</tr>
商業關系型數據庫
|
RDS
|
外置
|
外置
|
否
|
外置
|
外置
|
</tr>
Big Data支持
|
SimpleDB
|
外置
|
外置
|
BigTable
|
外置
|
外置
|
</tr>
部署時無需特殊框架
|
是
|
是
|
否
|
否
|
是
|
是
|
</tr>
方便遷移現有應用
|
是
|
是
|
否
|
否
|
否
|
是
|
</tr>
應用可移植性
|
高
|
高
|
中
|
低
|
低
|
高
|
</tr>
可用于生產環境
|
是
|
是
|
Beta階段
|
是
|
Beta階段
|
Beta階段
|
</tr>
</tbody>
</table>
對開發者生產力和開發過程的支持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年。目前已經有了更多的文檔——比如 </span>這篇 ，但它們不該這么難找。</span>
另一個重要的問題，Cloud Foundry允許開發者配置自己的云環境，部署Micro Cloud可比僅僅安裝一套SDK麻煩多了。這也是一個障礙，讓很多開發者對Cloud Foundry望而卻步。
| |
Amazon Beanstalk
|
CloudBees
|
Cloud Foundry
|
Google App Engine
|
Heroku for Java
|
OpenShift
|
</tr>
IDE工具
|
是
|
是
|
是
|
是
|
否
|
是
|
</tr>
命令行工具
|
是
|
是
|
是
|
是
|
是
|
是
|
</tr>
基于Web的控制臺
|
是
|
是
|
否
|
是
|
否
|
是
|
</tr>
開發機上進行測試
|
簡單
|
簡單
|
困難
|
困難
|
是
|
簡單
|
</tr>
構件時無非標準依賴
|
是
|
是
|
否
|
否
|
否
|
是
|
</tr>
源碼控制集成
|
否
|
是
|
是
|
否
|
否
|
部分
|
</tr>
集成構建
|
否
|
是
|
否
|
否
|
否
|
是
|
</tr>
集成測試
|
否
|
是
|
否
|
否
|
否
|
否
|
</tr>
通過Web訪問日志
|
否
|
是
|
是
|
是
|
是
|
是
|
</tr>
第三方開發者/測試服務
|
否
|
是
|
否
|
否
|
否
|
否
|
</tr>
API訪問
|
是
|
是
|
否
|
否
|
是
|
否
|
</tr>
文檔
|
好
|
好
|
差
|
好
|
好
|
好
|
</tr>
</tbody>
</table>
性能和可伸縮性PaaS最重要的特性之一是平臺自動伸縮的能力，就是基于實時流量需求增加或減少服務器容量。這要求平臺提供商在眾多服務器之間對請求做負載均衡，監控各臺服務器的負載，適時啟動新服務器。
所有PaaS提供商都在一定程度上支持自動伸縮。但自動擴展遠比看上去困難。對入門用戶而言，Java EE應用程序必須被配置為訪問中心化外部數據庫，而不是訪問部署在同一臺服務器上的數據庫。所有PaaS提供商的編程范式和工具都要強制開發者遵循這種方式。
更大的問題是HTTP會話。在Java應用服務器上，HTTP會話的會話狀態默認是在內存里管理的。要構建能在不同服務器之間負載均衡的應用程序，開發者必須使用以下的某個方法：
- 配置負載均衡器支持“粘性會話”（sticky session），負載均衡器會檢查所有流入請求的會話ID，總是把同一會話的請求發給相同的服務器。這是最簡單的方法，不過也有自己的問題：負載均衡器需要完成更多的工作，久而久之負載分發會變得不再均衡，而且在負載下降時，很難撤下擴上去的基礎設施，因為每臺服務器都有自己的會話。出于這些原因，很少有PaaS提供商支持這一方法。
- 為內存中的HTTP會話配置一個共享的緩存。如此一來，每時每刻所有服務器都能在內存里擁有全部HTTP會話。但是，在集群中復制內存會話這項任務既耗費帶寬，又消耗計算資源。它要求應用程序開發者配置共享緩存和復制策略。
- 還可以配置應用程序，將所有HTTP會話持久化到外部關系型數據庫中。
</ul>
上述所有的PaaS平臺中，Google App Engine對這一問題的處理是最好的。它在架構上就將單一服務器的概念抽象了出來，會自動在不同的服務器上創建數據存儲，并默認將HTTP會話保存到數據存儲中，這一過程對開發者是透明的。但是，Google App Engine的問題是原生的性能太差，一個Web請求要花1至3秒才能完成一次對數據庫的訪問。
Heroku for Java的每個服務器實例都封裝了一個自定義的Jetty實例，因此它也提供了跨服務器實例自動共享會話的能力。然而，Heroku并不提供透明的自動伸縮，你需要觀察儀表盤，適時為應用添加資源。
剩余的標準Java PaaS產品都強制要求開發者在專門的數據庫服務器上創建數據表，這也是部署過程的一部分。對于HTTP會話，Cloud Foundry在負載均衡器中使用了粘性會話。正如上文討論的那樣，這種做法為開發者帶來了便利，也有一些嚴重的問題。其他PaaS產品雖然沒有明說，但都把會話管理的工作留給了應用程序開發者。
| |
Amazon Beanstalk
|
CloudBees
|
Cloud Foundry
|
Google App Engine
|
Heroku for Java
|
OpenShift
|
</tr>
內建負載均衡器
|
是
|
是
|
是
|
是
|
是
|
是
|
</tr>
負載均衡器自定義域名
|
是
|
是
|
否
|
Google Apps
|
是
|
是
|
</tr>
自動伸縮應用服務器
|
是
|
是
|
計劃支持
|
是
|
否
|
是
|
</tr>
自動伸縮數據庫
|
否
|
否
|
否
|
是
|
否
|
否
|
</tr>
用戶定義性能標準
|
是
|
是
|
計劃支持
|
否
|
否
|
是
|
</tr>
基于Web的監控儀表盤
|
是
|
是
|
計劃支持
|
是
|
是
|
是
|
</tr>
集群HTTP會話
|
手工
|
手工
|
手工
|
自動
|
自動
|
手工
|
</tr>
</tbody>
</table>
價格及其他商業考量對開發者而言，PaaS產品的價格是十分重要的。大多數服務提供商都有免費服務供開發者試用，這些免費服務對較小的Java Web站點來說就是很好的選擇。
但是，正如Google App Engine最近的漲價風波所反映的那樣，大型Web應用程序使用PaaS的成本還是很高的。
另一個要考慮的重要因素是支持。Google App Engine和Amazon Web Services在支持方面表現糟糕。開發者只能自己在論壇上尋找答案。稍小的專注于Java的提供商提供了更好的技術支持，在公共論壇上亦是如此。在我看來CloudBees提供的支持最為出色，很好地結合了付費問題單的支持和支持人員間的Java專業技術秘訣。
| |
Amazon Beanstalk
|
CloudBees
|
Cloud Foundry
|
Google App Engine
|
Heroku for Java
|
OpenShift
|
</tr>
是否有免費服務
|
是
|
是
|
N/A
|
是
|
是
|
免費
|
</tr>
低流量入門級Web應用成本
|
高
|
免費
|
免費
|
免費
|
免費
|
免費
|
</tr>
跨云提供商
|
否
|
否
|
計劃支持
|
否
|
否
|
計劃支持
|
</tr>
私有云
|
否
|
Beta階段（OpenStack或vSphere）
|
是
|
否
|
否
|
計劃支持
|
</tr>
支持
|
論壇
|
電子郵件和電話
|
論壇 / Web支持問題單
|
論壇
|
電子郵件和電話
|
論壇
|
</tr>
支持質量
|
差
|
好
|
好
|
差
|
一般
|
好
|
</tr>
</tbody>
</table>
下一步文中我們討論了Java PaaS領域的6個知名廠商，當然，現在還有一些稍小的或不那么有名的提供商，比如：