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

同样在里程碑 M5 中，对克隆的支持已完全移除。区域隔离和它们之间的作用域计划提供了更简单、更易于管理的解决方案，以解决克隆旨在解决的大多数常见问题。

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

区域新闻

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

dm Kernel 创建一个单一的**用户区域**来运行应用程序，所有应用程序（包括 dm Server 提供的应用程序——Splash、Admin、Web 和托管存储库）都部署到**用户区域**中。

内核捆绑包**不会**安装在用户区域中（除了少数用于区域管理的捆绑包）。支持内核的必要功能在 OSGi 框架中运行，但用户区域应用程序看不到它，除了通常提供的服务。应用程序与内核实现是隔离的。

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

值得高兴的区域

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

克隆登场

克隆在四月由 Rob 在dm Server Roadmap中进行了描述。克隆是一种分离两个应用程序依赖项的方法，否则这两个应用程序将**要么**共享不应该共享的构件，**要么**尝试共享无法共享的构件。

例如，共享具有静态状态的捆绑包可能并不理想，能够拥有此类捆绑包的副本（克隆）意味着不同的应用程序可以使用不同的克隆（应用程序作用域机制允许我们在框架中以不同的名称安装多个副本）。在另一种情况下，当较低级别的捆绑包通过公共中介（通常是 Spring Framework 的一部分）通过依赖项固定时，克隆中介允许克隆依赖于不同的较低级别捆绑包，从而释放克隆来满足原始中介无法满足的传递约束。

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

谨慎的克隆者

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

• 它在有效工作时很出色，但通常需要很长时间（才能失败或成功）。
• 极其难以理解发生了什么克隆以及原因，并且不能保证每次部署相同的构件时都能获得相同的克隆解决方案。

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

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

• 在固定情况下（如上所述），可能需要克隆大量中介。
• 预先确定需要哪些克隆并非易事。（正是这种困难使得自动克隆难以很好且高效地完成。）

两种克隆解决方案也都依赖于作用域，而这些解决方案不适用于非作用域应用程序。

最后，克隆实现必须包含 Spring 依赖项作为特例才能高效工作。Spring DM 扩展程序也引入了特例：这些特例根本无法很好地推广到其他扩展程序和其他库。它只是太特定于 Spring 了。

总的来说，尽管克隆和自动克隆的一些成就令人印象深刻，但该功能 simply 不够稳定，无法在现场支持，因此为了整体质量和稳定性而被移除。

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

高音和低音

尽管有些人可能会对克隆支持的消失感到惋惜（虽然编写起来很有趣，但调试起来却并非如此），但区域隔离和现有作用域应用程序（和计划）为常见的依赖项问题提供了更简单、更强大的解决方案。

几乎所有固定问题都是通过 Spring Framework 产生的，因此用户区域的隔离为大多数这些问题提供了解决方案。

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