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
[1] [2] 下一页
（出处：http://www.sheup.com）
上一页 [1] [2]