Java 多租户简介

最新推荐文章于 2025-06-09 10:56:31 发布

转载最新推荐文章于 2025-06-09 10:56:31 发布 · 5.4k 阅读

Java 同时被 3 个专栏收录

2 篇文章

订阅专栏

将博客搬至优快云

2 篇文章

订阅专栏

JVM

0 篇文章

订阅专栏

Graeme Johnson 和 Michael Dawson
2013 年 11 月 21 日发布/更新: 2014 年 9 月 25 日

Weibo Google+用电子邮件发送本页面

云供应商必须权衡运行系统和提供服务所需的基础架构的成本与供应商所获得的效益。这些成本效益考虑因素促使供应商考虑应采用多种架构。他们的选择范围涵盖从无共享 架构到共享多租户 架构的一系列架构。在无共享架构中，供应商提供了完全专用于每个客户的硬件、软件和应用程序。在共享多租户的架构中，可以使用单个应用程序支持多个客户的应用程序，而且所有底层的硬件和软件都是共享的。

沿着这个架构系列进行发展时的主要权衡因素是隔离和密度。密度是由一组特定的硬件和软件交付的系统和服务的数量。共享的资源越多，密度就越高。密度越高，供应商的成本也就越低。同时，更多共享可以降低租户之间的隔离水平，这里的租户指的是所提供的单独系统或服务。隔离是一个租户对其他租户的活动和数据的影响程度。

对于基于 Java 的租户，在架构系列中的定位包括共享或不共享 JVM。在共享顶层应用程序的任何架构中，必须共享 JVM。共享 JVM 既能节省内存，又能节省处理器时间。但是，如果使用传统的 JVM 技术，那么共享 JVM 通常会从基础架构层中删除所有剩余的隔离，顶层应用程序被要求自身提供这种隔离。在 IBM 的 7 R1 版中，以技术预览的形式提供了对本文介绍的多租户功能的试用（请参阅参考资料）。此特性使得用户可以通过部署获得共享 JVM 的优点，尽管与共享传统 JVM 时获得的隔离水平相比，该特性可以提供更高水平的隔离。

多租户 JVM 的成本和效益

使用多租户 JVM 的主要优势是，可以通过部署来避免通常与使用多个标准 JVM 有关的内存消耗。此开销是由以下几个原因造成的：

Java 堆消耗数百 MB 的内存。即使对象是相同的，JVM 之间也无法共享堆对象。此外，JVM 往往会使用分配给它们的所有堆，即使它们只在很短的时间内需要峰值量。
即时（JIT）编译器占用了几十 MB 的内存，因为生成的代码是私有的，所以它会占用内存。生成代码也需要大量的处理器周期，这会从应用程序中窃取时间。
类的内部构件（其中的许多构件，比如 String 和 Hashtable，都存在于所有应用程序中）占用了一些内存。每个 JVM 都存在所有这些构件的一个实例。
在默认情况下，每个 JVM 都有垃圾收集器辅助线程（一个核心一个），还有多个编译线程。编译或垃圾收集活动可以同时出现在一个或多个 JVM 中，这可能是次优方案，因为 JVM 会竞争有限的处理器时间。

除了降低内存和处理成本之外，与在单一传统 JVM 中运行多个应用程序相比，多租户 JVM 提供了更好的隔离。

另一个好处是，从共享 JVM 的第一租户开始，后续的应用程序需要更少的时间来启动，因为 JVM 已经在运行。减少启动时间对于短期运行的应用程序特别有用，这些应用程序通常用于脚本。

使用多租户 JVM 的主要成本是，相对于在单独的 JVM 中运行的多个应用程序，租户的隔离水平较低。例如，多租户 JVM 中的本机崩溃会影响所有租户。

另外，JVM 为了实现多租户扩展而必须做的一些工作会导致微小的性能下降。不过，这种性能影响会随着租户数量的增加而降低，因为在同一系统中运行多个 JVM 可以避免增加处理器和内存成本。

使用多租户 JVM

为了选择与其他租户共享一个运行时，当启动应用程序时，应用程序用户在命令行中添加一个 -Xmt 参数。例如：

1	`java -Xmt -jar one.jar`

其结果是，应用程序的行为（由于我们在本文稍后描述的限制）就好像它在一个专用 JVM 上运行一样。但在现实中，它是与其他应用程序并行运行的。多租户 JVM 中的扩展支持这种方式的启动，并提供了共享 JVM 的租户之间的隔离。

当租户启动时，JVM 启动程序要么会定位现有的共享 JVM 守护进程 (javad) ，要么会启动它（如有必要），如图 1 所示：

图 1. JVM 启动程序自动定位了共享的 JVM 守护进程（如果有必要，还会启动它）

屏幕截图和图表显示了自动定位和启动共享的 JVM 守护进程 (javad) 的 JVM 启动程序

当第二个租户启动时，租户会发现现有的共享 JVM 守护进程，并在该 JVM 内运行，如图 2 所示：

图 2. JVM 启动程序被定位并连接到现有的 JVM 守护进程

屏幕截图和图表显示了定位并连接到现有的 JVM 守护进程 (javad) 的 JVM 启动程序

结果，javad 进程中存在两个租户共用的引导代码的一个副本。这样的安排使得租户可以共享大部分运行时结构。

使用多租户 JVM 运行现有的应用程序很容易，因为只需更改有限的命令行即可。

实现隔离

在相同的（常规） JVM 中运行的两个或两个以上的应用程序通常不会彼此隔离。每个应用程序的活动都会影响另一个应用程序的结果。此外，通过静态字段共享的数据也可以供所有应用程序访问。多租户 JVM 有两种解决这些问题的方法：静态字段隔离 和资源限制。

静态字段隔离

在多租户 JVM 中，各租户之间共享类的不变的部分。这些部分包括编译后的方法代码、JVM 使用的数据结构，以及其他类似的构件。此分享可以节省内存，因为不必在使用多个 JVM 的情况下提供独立的副本。然而，多租户 JVM 为每个租户提供了它们自己的静态字段副本。由于静态字段隔离（以及每个租户通常只能访问自己创建的实例的对象这个事实），每个租户只能访问与自身有关联的数据。其结果是租户之间的数据隔离。

资源限制：应对不良行为

在一个完美的世界中，租户能够以适当的方式共同运营和使用共享资源。然而，在这个不完美的世界中，程序错误和恶意行为都有可能出现。多租户 JVM 提供了可配置的控制，以便限制租户执行错误操作和以影响其他租户的方式使用资源的能力。可以控制的值包括：

处理器时间
堆大小
线程数量
文件 I/O：读带宽和写带宽
套接字 I/O：读带宽和写带宽

可以在 -Xmt 命令行中指定这些控制。例如：

-Xlimit:cpu=10-30 （最小 10％的 CPU，最大 30％）
-Xlimit:cpu=30（最大 30％的 CPU）
-Xlimit:netIO=20M（最大带宽为 20 Mbps）
-Xms8m-Xmx64m（初始的堆大小为 8 MB，最大值 64 MB）

Java 7 R1 文档包括所有可用选项的信息（请参阅参考资料）。

性能和内存占用

为了比较无共享 JVM 和多租户 JVM 上的应用程序性能和内存占用，在该测试中，我们将应用程序添加到每个 JVM 配置，直到执行系统置换（system swap）。（当系统置换时，我们认为该系统是 “满的”。）在无共享的情况下，我们在单独的 JVM 中运行应用程序，并为每个额外的应用程序启动一个新的 JVM。在多租户的情况下，我们在单一的多租户 JVM 中将应用程序作为另一个租户运行。

表 1 和表 2 显示了我们使用一台配置了 1 GB 内存的计算机和一个 64 位 JVM（在所有情况下，都使用了压缩的引用 JVM 和均衡的垃圾回收策略）所得到的结果。在两个表中的 “手工调整” 列显示了我们手工调整了命令行选项，以尽量达到最佳密度（表 1）或启动时间（表 2）后，从常规 JVM 获得的结果。“默认” 列显示使用常规 JVM 与默认选项的结果。

多租户 JVM 实现了无共享 JVM 的 1.2 倍至 4.9 倍的密度（该值根据不同的应用而有所不同），如表 1 所示：

表 1. 并发应用程序的最大数量

应用程序	描述	多租户	手工调整	默认	通过多租户 JVM 实现的提高
Hello World	打印 “HelloWorld” 然后进入睡眠状态	309	73	63	4.2 倍到 4.9 倍
Jetty	启动 Jetty 并等待请求	34	-	18	1.9 倍
Tomcat	启动 Tomcat 并等待请求	28	-	13	2.1 倍
JRuby	启动 JRuby 并等待请求	32	26	15	1.2 倍到 2.1 倍

更高的密度来自关键构件的共享，这些构件包括：

通过引导和扩展类来加载器加载的类和相关构件、加载器加载的每个类的堆 Class 对象，以及可以安全地跨租户共享的堆对象（例如，实习 String）。
JIT 编译的代码和 JIT 编译的类的元数据。
堆：如果其他租户不需要使用堆中的可用空间，那么租户可以使用这些空间。

表 2 显示，我们通过多租户 JVM 实现了快 1.2 倍到 6 倍的平均启动时间：

表 2. 启动时间（第一个/平均）

应用程序	描述	多租户	手工调整	默认	通过多租户 JVM 实现的提高
Hello World	打印 “HelloWorld” 然后进入睡眠状态	5709/138ms	514/400ms	3361/460ms	3.3 倍
Jetty	启动 Jetty 并等待请求	7478/2116ms	-	6296/12624ms	6 倍
Tomcat	启动 Tomcat 并等待请求	9333/6005ms	-	7802/7432ms	1.2 倍
JRuby	启动 JRuby 并等待请求	12391/3277ms	14847/4101ms	7849/6058ms	1.25 倍到 1.8 倍

从表 2 中可以看到，多租户 JVM 上的第一个应用程序实例的启动时间通常比标准 JVM 上的慢。这是预料之中的结果，因为多租户扩展会造成额外的路径长度，导致第一个实例出现一些额外的启动延时。后续实例的启动时间始终是多租户 JVM 表现更好一些。

这些早期的结果是因为使用开发 JVM 而产生的，有可能会获得更大的改进。此外，这些示例并不影响当应用程序在不同时间需要资源时进行的共享。在一个典型的 JVM 中，在整个生命周期中，每个 JVM 需要的内存占用往往会不断增大。在标准 JVM 中，这种内存占用不是共享的。如果使用多租户 JVM，在资源需求不重叠时，可以更容易地共享堆的内存和本机构件。

限制

多租户 JVM 的一个目标是无需修改就能运行所有 Java 应用程序。这在目前是不可能实现的，原因是 Java 规范方面的一些限制以及我们目前的实现中的一些限制。关键的已知限制包括：

Java Native Interface (JNI) natives：多租户 JVM 没有为 JNI natives 提供隔离。如果使用多租户 JVM，运行包含用户提供的 JNI natives 的应用程序可能是不安全的。此类应用程序可能会影响整体 JVM 操作和其他租户对数据的访问。在需要对 natives 有足够 “信任” 的情况下（例如，知名的中间件），风险可能是可以接受的。此外，操作系统允许共享的 JVM 进程只加载一个共享库副本，即 natives 所在的位置。其结果是，如果多个租户在同一个共享库中，那么他们将无法加载相同的 natives。
Java Virtual Machine Tool Interface (JVMTI)：因为调试和分析活动会影响共享 JVM 服务器的所有租户，所以目前多租户 JDK 不支持这些特性。这是我们计划投入更多工作的一个领域。
GUI 程序：SWT 等库在原生层保持全局状态，因此在多租户 JDK 中也不支持它们。