IBM MobileFirst Platform Foundation Server 中的 Ad-hoc Artifact 部署

Posted 2023-02-25

【中文标题】IBM MobileFirst Platform Foundation Server 中的 Ad-hoc Artifact 部署

【英文标题】：Ad-hoc Artifact deployment in IBM MobileFirst Platform Foundation Server

【发布时间】：2017-06-30 06:18:23

【问题描述】：

1)当需要部署 正常生产过程中的工件

2) 是否有任何可能需要小心的特定工件 在正常生产期间部署时的考虑

3) 在运行时系统行为会发生什么变化 工件部署发生，例如同步、事务失败、内存 使用增加等，并尽可能将它们列出来，以便我们 可以注意它

4) 作为上述 3 的一部分，在这种情况下采取什么适当的行动 失败，例如

4.A) 当由于某种原因同步失败时该怎么办 - 服务器重启 等等？

4.B) 当交易因新工件而失败时该怎么办 部署 - 建议任何包含 minitor 的客户端代码更改 失败回调并通过有意义的消息通知用户或 自动重试？

【参考方案1】：

1)当需要部署 正常生产过程中的动态工件

每当需要部署新的工件时，环境都会有一小段停机时间，并且会阻塞到环境的流量。工件已更新。 如果需要，重新启动服务器。打开应用程序的流量。 停机时间通常在应用程序的非高峰时间进行。

2) 是否有任何可能需要小心的特定工件 在正常生产期间部署时的考虑

唯一更新的工件是运行时 WAR 文件， 适配器和 wlaps。

如果有 iFix 升级，通常会更新 WAR 文件。 （需要一个 停机时间）。

wlapp 可以是 2 种类型。

wlapp 适用于新版本。 （不需要停机，因为没有 新版本的流量）。 wlapp 升级现有的混合应用程序。 （建议 停机时间作为直接更新将立即在所有设备上触发 连接）。

适配器已更新以修复功能。 （建议停机时间为 敏感的交易流被中断）。

适配器是新的。 （无需停机）。

3) 在运行时系统行为会发生什么变化 工件部署发生，例如同步、事务失败、内存 使用增加等，并尽可能将它们列出来，以便我们 可以注意它

这完全取决于应用程序逻辑。同步失败 WAR 文件更新时可能会发生。但是当 WAR 文件更新时 ，无论如何建议重新启动应用程序服务器。交易失败是应用程序逻辑 依赖，所以它们是未定义的。内存使用还取决于 应用程序逻辑已更改。除非变化很大，否则它们应该 工作正常。

4) 作为上述 3 的一部分，在这种情况下采取什么适当的行动 失败，例如

4.A) 当由于某种原因同步失败时该怎么办 - 服务器重启 等等？

需要与 WebSphere 支持团队核实同步失败的原因。这 服务器重启应该足以解决任何同步问题。但是如果 跨集群的同步失败是常见的，请收集日志 并打开 PMR 以供 WAS 支持人员审核

4.B) 当交易因新工件而失败时该怎么办 部署 - 建议任何包含 minitor 的客户端代码更改 失败回调并通过有意义的消息通知用户或 自动重试？

应用程序逻辑应处理事务失败。适配器代码 应该优雅地发送有意义的消息并请求用户尝试 再次。