Linux 平台和 Java 平台有著久遠的但有經常經歷曲折的關系。構建高性能虛擬機的同時又要跟上日益增長的核心 Java API 集合，這樣做所帶來的復雜性在很大程度上使開發 Java 平台的開放源碼“淨室”實現的早期行動困難重重。Java 技術的特許實現最終可用於 Linux，但這些實現並不是開放源碼。因此，大多數 Linux 分發版沒有包含該特許實現。 盡管有這些困難，Java 平台還是提供了許多好處，從而導致在 Linux 上越來越多地使用該特許實現，尤其是對於服務器應用程序。在本文中，我回顧了 Java 平台給服務器應用程序帶來的優點，然後研究了在 Linux 上簡單且安全地部署 Java 服務所涉及的問題。作為一個實際示例，我將討論設置 Apache Software Foundation 的廣泛使用的 Tomcat Java servlet 引擎的詳細信息以用於獨立操作。 為什麼使用 Java 平台？ 有許多原因可以解釋為什麼 Java 平台成為基於服務器的商業應用程序的廣為接受的選擇。我將主要討論我認為對於該環境至關重要的三個原因：跨平台兼容性、受管運行時環境和易於開發。 Java 應用程序提供了跨多種操作系統和硬件平台的二進制兼容性。對於非 GUI 服務器應用程序尤其是這樣，在此類應用程序中，通常在實際目標系統中需要執行非常少的測試。開發人員可以在任何他們喜歡的平台上進行編碼和調試，同時仍可以將這些應用程序部署到他們也許不能直接控制的環境中。 Java 虛擬機（Java Virtual Machine，JVM）環境的運行時特性以幾種方式來加強程序安全性。最顯著的方面之一是嚴格的類型檢查、數組邊界檢查和自動垃圾收集的組合徹底防止了最具破壞性形式的服務器代碼攻擊：緩沖區溢出、重復釋放的錯誤和游離的指針。Java 語言早期用於 applet，經過不斷發展，該語言還有一個完善的系統，用於對那些已確信存在安全性風險的設施進行細顆粒度的訪問控制。這些方法可供獨立應用程序選擇使用，但它們已構建在許多 Java 服務的框架中。 這些運行時程序安全特性還提供了用 Java 語言開發的便利性。要對便利性這類問題作任何精確測量是困難的，但大多數具有諸如 C 和 C++ 之類語言背景而轉向 Java 編程的開發人員都承認在轉變之後他們的生產力提高了。其中部分是因為在編譯時和運行時嚴格執行類型確定，以及自動內存管理的簡單性。另一個因素是為 Java 平台開發的標准 API 擴展的集合。這些 API 對於新的開發人員可能是一個重大挑戰，但是一旦學會了，API 會為各種企業需求提供優秀的跨平台支持。 當然，對於某些應用程序而言，Java 平台可能是一個糟糕的選擇。盡管 JVM 體系結構在持續改進，但 Java 應用程序通常會比使用相同算法的 C 或 C++ 應用程序運行得稍微慢一點。根據我的經驗和測試，我估計這個速度差異對於在特許 JVM 上運行的大多數服務器應用程序來說大約是在 20％ 到 50％ 的范圍內，然而這很大程度上取決於代碼的質量。與獨立程序相比，在這些 JVM 上運行的 Java 應用程序還忍受著比較慢的啟動，但是這對於長時間運行的服務器應用程序通常並不是一個重大問題。在大多數情況中，降低的性能和較慢的啟動只是為獲得 Java 平台的增強的安全性和更快速的開發優點所付出的微小代價。 開放源碼替代選擇 除了標准特許 JVM（免費使用，但是源碼受到限制；可用於 Sun、IBM、BEA 和 Blackdown 組織的 Linux）之外，對於 Linux 還有其它幾個替代選擇。這些選擇包括“淨室”開放源碼 JVM 實現，其中使用最廣泛的可能是 Kaffe（在許多 Linux 分發版中都包含它）。Kaffe 是一個非常有意義的項目，它已經完成了一些令人驚訝的工作，但它只能提供與當前特許 JVM 有限的兼容性。因此，它通常不可用於本文所關注的企業類型的服務器應用程序。 用於 Java 程序的本機代碼編譯器的開放源碼工作也有幾個替代選擇。這裡最重要的項目是 GNU 編譯器集（GNU Compiler Collection）的 GCJ。使用諸如 CGJ 之類的本機代碼編譯器會將獨立於平台的 Java 字節碼在其執行之前轉換成特定於平台的代碼（這與在 JVM 中執行成對比，在 JVM 中執行通常在運行時將字節碼轉換成特定於平台的代碼）。 本機代碼編譯顯示出它極有可能成為一種避免在 JVM 中運行的 Java 應用程序啟動較慢的方法。但是，使用這種方法的編譯器通常都不能與當代特許 JVM 的穩定狀態性能相匹配。如果 Java 應用程序使用 Java 平台的動態特性（如使用反射來訪問字段或裝入在運行時選擇的類），這種情況尤其突出。根據所使用的實現和編譯選項，本機代碼編譯也許還會削弱 Java 平台的許多運行時安全特性。最後，由於許可證問題，許多 Java API 不能與已編譯的本機代碼一起使用。由於這些限制，本機代碼編譯目前還不是 Java 平台服務器應用程序的一個好選擇。 C# 怎麼樣？ 與 Java 運行時環境有許多共同點的一個替代方法是 Microsoft 的 C# 語言和相關的公共語言運行時（Common Language Runtime，CLR）。C# 是 Java 語言的關系緊密的衍生物，CLR 可能允許 C# 在許多平台上使用。CLR 還提供了 JVM 的許多運行時安全特性（盡管有嚴重削弱安全保證的逃離出口）。Microsoft .Net 實現還支持預編譯成本機代碼的選項以獲得更快速啟動，這與 GCJ 對 Java 字節碼所做的工作相同。當然，Linux 用戶並不能直接使用這項功能，因為 .Net 只適用於 Windows 系統。 Mono Project 正致力於為多種 Linux 產品構建“淨室”開放源碼 C# 和等價於 CLR 的產品。現在，該項目中的 C# 編譯器已開發完成，而且還完成了大部分的 CLR，Microsoft 已發布將它用於標准化。但是，無論從性能還是功能角度來看，在它成為合理的 Java 平台替代選擇之前還有許多工作要做。CLR 只包含了與 Java 核心類庫等價的基本內容。在可以將它看作是企業軟件開發的合理選項之前，還需要用許多附加的 API 來補充它。 Mono Project 正在致力於開發 CLR 以外的 .Net 其它部分的移植，如果這些移植成功了 — 並且如果 Microsoft 不對 .Net 的這些部分強加它的專利權 — 那麼它們會有助於滿足 C# 成為 Linux 上服務器軟件開發的可靠平台的需要。但要使那些假設成為現實，還需要做很多工作，同時，Java 程序的本機代碼編譯器和開放源碼 JVM 向那些確實想要避免使用特許 JVM 並可以忍受有限功能性的用戶提供了比較穩定的替代選擇。 Apache Tomcat 最普遍存在的 Java 平台服務器應用程序之一是 Apache Tomcat。Tomcat 是基於最初由 Sun 捐贈的源代碼的開放源碼項目。它是一個 HTTP 服務器，是 Sun 通過 Java Community Process 開發的、對廣泛使用的 servlet 和 JavaServer Page（jsp）技術的正式參考實現。我將在本文中使用 Tomcat 作為樣本 Java 應用程序，將其部署成 Linux 上的一個服務。如果您想要嘗試自己運行 Tomcat，那麼您將需要在系統上安裝 Java 開發工具箱（Java Development Kit，JDK），而不是安裝更小的 Java 運行時環境（Java Runtime Environment，JRE）。 servlet 和 JSP 技術用於構造 HTTP 服務器應用程序。雖然 servlet 技術中添加了許多特性（包括訪問安全性、會話管理和線程控制），但它本身只是粗略地等價於為快速直接的 Java 語言調用而定制的 CGI 接口。JSP 技術提供了一種處理動態生成的 Html 頁面的簡便方法，這些 HTML 頁面被直接編譯成 servlet 以用於快速運行時操作。 在這兩種技術之外，Tomcat 還提供了其它許多特性。憑它本身的性能，它實際上是全功能 Web 服務器，但它通常在 Linux 系統上與 Apache Web 服務器前端共同使用。Apache 向 Tomcat 提供了許多高級性能以適合靜態內容。對於靜態內容所占比例比較高且使用率很高的 Web 應用程序，Apache 前端非常有用。但對於許多簡單的 Web 應用程序，就沒必要使用它了，當更易於配置和管理時，單獨運行 Tomcat 就可提供足夠的性能（至少對於以前沒有使用過 Apache 的開發人員來說是這樣）。 端口難題 單獨運行 Tomcat 的一個大問題是它不能訪問標准 HTTP 端口 80，除非是作為 root 用戶運行。作為 root 用戶運行服務器應用程序的想法通常並不是上流公司所討論的問題，因此我將完全放棄這個想法！使用除 80 以外的端口是一個更好的選擇（例如，Tomcat 缺省端口 8080）。這通常適用於測試，但當用戶正在訪問服務時，它會導致雜亂的 URL，因為需要在請求中清楚地說明端口號。使用非標准端口還意味著如果需要外部訪問，就需要重新配置所有的防火牆。 xinetd 解決方案 幸好，Linux 支持一些利用 Tomcat（或任何其它用戶方式應用程序）處理端口 80 請求的簡便方式。一種常用方式是通過 xinetd。xinetd 是帶有廣泛訪問控制和日志記錄支持的因特網服務守護程序，它還擁有方便的重定向特性。重定向讓您將系統配置成接受一個端口上的進入請求，然後將請求傳遞到另一個端口或者甚至另一個 IP 地址進行處理。 如果您想要在系統上設置 Tomcat 以處理端口 80 請求，就需要添加 xinetd 配置文件來實現這一目的。假設按常規在缺省路徑上安裝了 xinetd，那麼您可以通過對 /etc/xinetd.d 目錄添加一個文件（以 root 用戶身份）來執行這一操作。清單 1 提供了用於 Tomcat 的一個樣本配置文件。 清單 1. xinetd 重定向配置 # Redirects any requests on port 80 # to port 8080 (where Tomcat is listening) service tomcat { socket_type = stream protocol = tcp user = root wait = no port = 80 redirect = localhost 8080
