(十九)——运行重构模式.pdfVIP

（⼗九）——运⾏重构模式 云计算设计模式 （⼗九）——运⾏重构模式 设计应⽤程序，使得它可以在不需要重新部署或者重新启动应⽤程序重新配置。这有 助于 持可⽤性并减少停机时间。 背景和问题 ⼀个主要⽬的为重要的应⽤，如商业和企业⽹站是尽量减少停机时间以及由此引发的 中断给客户和⽤户。但是，有时有必要重新配置应⽤程序改变特定⾏为或设置，⽽在 部署和使⽤。因此，它是⽤于该应⽤程序被设计成这样⼀种⽅式，以允许在运⾏时要 应⽤这些配置的变化，并为应⽤程序，以检测所述变化并且尽快地应⽤它们的部件的 优点。 该种要应⽤可能被调整记录，以协助与应⽤程序调试问题，交换使⽤不同数据存储的 连接字符串，或者打开或关闭特定的部分或应⽤程序的功能的粒度配置变化的例⼦。 解决⽅案 为实施这⼀模式的解决⽅案依赖于应⽤程序托管环境中可⽤的功能。典型地，应⽤程 序代码将响应于由检测到的变化对应⽤程序配置时，主机基础设施提出的⼀个或多个 事件。这通常是上载新的配置⽂件，或响应于改变通过管理门户的配置或者通过访问 的API的结果。 码处理的配置变化事件可以检查变化，并将其应⽤到该应⽤程序的组件。有必要对这 些部件进⾏检测和反应的变化，因此它们的值通常会被公开为可写的属性或⽅法，在 事件处理程序的代码可以设置为新值，或执⾏。从这⼀点来说，该部件应使⽤新的 值，以便在需要改变应⽤程序的⾏为发⽣。 如果这是不可能的部件，以应⽤更改在运⾏时，这将是必要的，重新启动该应⽤程 序，从⽽当应⽤程序启动时再次这些更改应⽤。在⼀些托管环境中它可能会检测到这 些类型的变化，并指出对环境的应⽤程序必须重新启动。在其他情况下，可能有必要 执⾏该分析的设置更改，并强制必要的应⽤程序重新启动时的代码。 图1⽰出了本模式的概述。 图1 - 此模式的基本概述 ⼤多数环境中暴露响应配置更改引发的事件。在那些不这样做，定期检查更改配置并 应⽤这些变化将是必要的轮询机制。它也可能有必要重新启动应⽤程序，如果变化不 能在运⾏时被应⽤。例如，有可能以⽐较在预设的时间间隔⼀个配置⽂件的⽇期和时 间，并运⾏代码以应⽤更改时的较新版本中找到。另⼀种⽅法是，其中包含⼀个控制 中的应⽤程序的管理⽤户界⾯，或使⼀个安全端点可以从应⽤程序外部进⾏访问，其 执⾏读取，并应⽤更新的配置的代码。 或者，该应⽤程序可以反应以在环境中的⼀些其他变化。例如，发⽣于特定的运⾏时 错误可能会改变⽇志配置⾃动收集更多的信息，或者代码可以使⽤当前⽇期读取和应 ⽤主题，反映了季节或特殊事件。 问题和注意事项 在决定如何实现这个模式时，请考虑以下⼏点： 配置设置必须存储在部署的应⽤程序之外，使得它们可以在不需要整个包被重 新部署更新。典型的设置被存储在配置⽂件中，或者在外部存储库中，如⼀个 数据库或⽹络存储。访问运⾏时配置机制，应严格控制，以及使⽤时的严格审 核。 如果托管的基础设施不会⾃动检测配置更改的事件，揭露这些事件对应⽤程序 代码，您必须实现⼀种替代机制来检测和应⽤更改。这可以是通过轮询机制， 或者通过暴露交互式控制或端点发起更新过程。 如果您需要实现⼀个轮询机制，考虑如何经常检查更新的配置应该发⽣。长轮 询间隔将意味着变化可能不被应⽤了⼀段时间。短的间隔可能会产⽣不利影 响，通过吸收现有的计算和I / O资源的操作。 如果是应⽤程序的多个实例，附加的考虑因素，这取决于如何变化进⾏检测。 如果改变是通过由宿主基础结构引发的事件⾃动检测到，这些变化可能不被同 时应⽤的所有实例进⾏检测。这意味着，某些情况下，将要使⽤的原始配置为 ⼀个周期，⽽有些则使⽤新的设置。如果该更新是通过轮询机制检测到，这必 须以 持⼀致性通信改变到所有实例。 ⼀些配置的变化可能要求应⽤程序重新启动，甚⾄要求托管服务器重新启动。 您必须确定这些类型的配置设置和执⾏的每⼀个相应的操作。例如，要求应⽤ 程序重新启动的变化可能会⾃动执⾏此操作，或者它可能是管理员负责发起重 新启动在适当的时间时，应⽤过⼤的负荷和应⽤程序可以处理的其他实例下是 不的负载。 更新并确认他们是成功的，⽽更新的应⽤程序实例正在执⾏正确，将更新应⽤ 到所有实例之前的分阶段部署计划。由此，能够防⽌应发⽣错误的应⽤程序的 总的中断。凡更新需要重新启动或应⽤程序的重