(2009年10月15日更新) 从里程碑 M5 开始，dm Server 2.0 采用 区域 来将内核与用户应用程序隔离开来。这意味着内核实现对应用程序和应用程序管理来说几乎完全不可见。

同样在里程碑 M5 中，对克隆的支持被完全移除。区域隔离及其之间的范围计划为克隆旨在解决的最常见问题提供了大大简化且更易于管理的解决方案。

在接下来的两节中，我将概述这些变更以及我们进行这些变更的原因。

区域新闻

一个 区域 就像一个 OSGi 框架一样——它是应用程序安装、解析和运行的地方。

dm Kernel 创建了一个单一的 用户区域 用于运行应用程序，并且所有应用程序（包括 dm Server 提供的——Splash、Admin、Web 和 Hosted Repository）都部署到 用户区域 中。

Kernel bundles 未安装在用户区域中（除了少数区域管理所需的）。支持内核的必要功能在 OSGi 框架中运行，但用户区域的应用程序无法看到它，除非是正常提供的服务。应用程序与内核实现是隔离的。

这种隔离有很多好处：例如，内核和用户应用程序不再需要使用相同版本的 Spring Framework。（事实上，内核没有安装全部的 Spring Framework——它也不需要。）如果内核更新，应用程序需要升级或调整来适应它的可能性会大大降低。因此，内核实现更加稳定和有弹性，并且应用程序更有可能在版本之间的内核升级中存活下来。

区域带来的好处

• 使用 Shell 或 Admin Console，您只能看到用户区域——内核实现 bundles 是不可见的，这简化了管理视图。[2009年10月15日补充说明：少量内核 bundles 仍然在用户区域中可见，因为内核已将其安装在那里用于区域管理。]
• 该设计完全能够在未来的版本中扩展以支持多个用户区域；管理一个区域的开销很小且固定——实现是可伸缩的。
• 用户区域的基本初始化是可配置的，并且完全独立于内核。
• 区域的实现是完全通用的——它不以任何方式依赖于 Spring 或 Spring DM。如果需要，一个用户区域可以配置为完全不支持 Spring，如果这是您所需要的。

克隆的终结

Rob 在四月份的 dm Server 路线图中描述了克隆。克隆是一种分离两个应用程序依赖关系的方式，否则它们会要么共享不应该共享的构件，要么尝试共享不能共享的构件。

例如，共享带有静态状态的 bundles 可能不是理想的，而能够拥有这样一个 bundle 的副本（克隆）意味着不同的应用程序可以使用不同的克隆（应用程序作用域机制允许我们在框架中以不同的名称安装多个副本）。在另一种情况下，当下层 bundle 通过一个共同的中间件（通常是 Spring Framework 的一部分）被依赖锁定（pinned）时，克隆这个中间件允许克隆依赖于不同的下层 bundle，从而使克隆能够满足原始中间件无法满足的传递性约束。

在 dm Server 2.0 的里程碑版本（直到 M4）中，克隆支持（包括手动和自动）一直可用。我们从这个实现中收到了很多反馈和经验，并且作为一项实验，它证明是富有成效的。然而，时间和经验表明，这还没有准备好用于生产环境，因此克隆已从 M5 中移除，并且不会是最终 2.0 版本的一部分。区域隔离结合范围计划，可以用来管理克隆旨在解决的最常见问题。这些解决方案更容易理解，并且在生产环境中大大更容易支持。

克隆的问题

移除克隆的最重要原因是自动克隆太脆弱且不可预测。

• 它工作时很棒，但通常需要很长时间（才能失败或成功）。
• 要理解发生了哪些克隆以及为什么发生，是极其困难的，并且不能保证对于部署相同的构件，每次都会获得相同的克隆解决方案。

这些特性不是大多数系统管理员希望用于生产系统的（尽管它们有时在开发中很方便）。在生产环境中，我们需要一个可预测的配置，可以信赖它每次都以相同的方式工作（否则会快速失败）。

手动克隆相对稳定，但即使是手动克隆也存在问题。

• 在锁定（pinning）的情况下（如上所述），可能需要克隆相当多的中间件。
• 事先确定需要哪些克隆并非易事。（正是这种困难使得自动克隆难以做好并且效率低下。）

两种克隆解决方案也依赖于作用域（scoping），并且这些解决方案不适用于无作用域（unscoped）的应用程序。

最后，克隆实现必须将 Spring 依赖作为特例包含进来才能高效工作。Spring DM extender 也引入了特例：这些对于其他 extender 和其他库完全没有通用性。它太过于特定于 Spring 了。

总的来说，尽管克隆和自动克隆的一些成果令人印象深刻，但这项功能在现场根本不够稳定，因此为了整体质量和稳定性而被移除。

最重要的问题可以通过区域隔离和显式作用域来解决。

总结

尽管可能会有人为克隆支持的移除感到惋惜（编写它很有趣，尽管调试时并非如此），但区域隔离和现有的范围应用程序（和计划）为常见的依赖问题提供了更简单、更强大的解决方案。

锁定（pinning）问题几乎都产生于 Spring Framework，因此用户区域的隔离为解决这些问题提供了解决方案。

其他常见情况可以通过适当使用范围应用程序来解决，这实际上是管理服务器中安装构件的一种更可控、更易于支持的方式。范围计划使得创建所需的作用域变得容易，并且在框架上下文更改时，解析布线在生产过程中保持稳定。