websphere中的Spring Restful服务答案

【问题标题】：Spring restful services in webspherewebsphere中的Spring Restful服务
【发布时间】：2018-09-25 15:06:05
【问题描述】：

我们在Websphere Application Server中的应用环境有3个集群 1. UI集群 2.服务集群 3. 集成集群

我们有大约 50 个战争文件（微服务）部署到服务集群。所有服务都基于 REST 并通过 SPRING API 公开。重新启动服务集群大约需要 30 分钟。这个时间对于生产中的实时事件至关重要。由于某些原因，如果需要重新启动服务集群，我们需要为所有最终用户提供 30 分钟的停机时间。我们正在寻求减少回收时间，请向我们提出任何解决方案。

有没有办法在应用程序启动之前加载所有基于 Spring 的 jar 文件？例如，有一个名为 xyz-1.0.war 的服务 war 文件，并且有基于 Spring 的 jar 文件作为 maven 依赖项。所有 50 个 WAR 文件都具有相同的依赖项集，我正在考虑是否可以在 websphere 服务器启动应用程序之前加载所有基于 Spring 的 jar。

请提出建议。

【问题讨论】：

为什么？只是为什么？ 1）拉里不需要另一个岛。 2) 这不是微服务架构。您不能开发 50 种不同的 Spring Boot Wars 并部署到应用程序服务器中并称其为微服务。如果这样做，您将获得微服务的所有痛点和零收益。

标签： rest websphere

【解决方案1】：

我不知道您可以在应用程序启动之前加载它们（类加载通常是按需加载的），但您可以通过为您的公共文件使用共享库来加快速度，所以它们' d 由单个类加载器加载，而不是从每个 WAR 的类加载器加载。它不会消除类加载活动，因为每个 WAR 仍然需要加载必要的类，但它会加速类加载的机制，因为共享库加载器将返回已经加载的类而不是搜索它类路径。

您可以采取两种不同的方法来解决这个问题。在这两种情况下，第一步是创建一个共享库，其中包含在应用程序之间共享的类。第二步的选项：

1) 在服务器上创建一个自定义类加载器，并将共享库与这个新的类加载器相关联。这将使共享库中的类对服务器上运行的所有应用程序可见。

2) 在共享库配置中，选择“为此共享库使用隔离类加载器”，然后将共享库与任何需要它的应用程序关联。如果共享类仅由某些应用程序需要，这将仅将它们提供给需要它们的应用程序。

注意几点：

如果您需要唯一的 Class 实例（例如，每个 WAR 唯一的静态值），此方法将不起作用，因为共享库加载器只会加载 Class 的一个实例。在这种情况下，您将不得不坚持使用 WAR 级别的打包。
如果您使用隔离类加载器解决方案，请注意这些加载器使用“最后一个父级”类加载，在这些加载器中它们在服务器类加载器之前被搜索。如果这些库中有任何与服务器提供的类冲突的内容，则可能会导致 ClassCastExceptions 或 LinkageErrors。
请注意，共享库加载器作为 WAR 加载器的父级运行，因此，库中的类将无法“看到”WAR 中的类。您需要确保这些库基本上是自包含的，这些方法才能成功。

【讨论】：

【解决方案2】：

如果您在做微服务，那么您的服务应该是可独立部署的，因此它们每个都应该在单独的集群中。传统的 WebSphere Application Server 对这个解决方案来说有点重（取决于您的节点上有多少资源），所以我建议您将服务集群迁移到 WebSphere Liberty，在这种情况下，您可以将每个服务分开集群。这将允许您在更短的时间内独立地重新启动每个服务。

如果您在做微服务，那么您的 UI 集群应该为任何服务不可用做好准备 - 这是做微服务时的入门，并向最终用户显示一些消息，该服务暂时不可用。

关于您当前的设置 - 您可以尝试“Rollout update”选项，该选项将按顺序重新启动您的服务器，因此服务应该可以在其他节点上使用。

so-random-dude 建议使用蓝/绿部署也非常好。您可以有 2 个单元，然后在重新部署后切换插件配置。如果您的服务以不同版本可以在更新期间并行运行的方式编写，您将不会有停机时间。

如果您想进一步减少停机时间并提高性能，您应该考虑使用 Java EE/Rest 服务而不是 Spring，因为它会显着减少您的应用程序的大小、要扫描的库数量、部署和启动时间。与 Spring 中必须包含的大量 jar 相比，它在 WebSphere Liberty 中的集成和支持要好得多。

【讨论】：

【解决方案3】：

我有一个简单的解决方案给你，只需放弃 Websphere 并将这 50 个“战争”部署为独立的 jars 并在其中嵌入 netty/undertow/tomcat/jetty。

恐怕您目前拥有的根本不是微服务架构。同意，不同的团队/顾问/组织对“微”服务有不同的解释。但这是一个极端，你应该不惜一切代价避免它；因为您拥有微服务的所有痛点和零优势（独立可扩展性/可部署性等优势）。

重新启动服务集群大约需要 30 分钟。这次是在生产中的实时事件中至关重要。出于某种原因，如果服务集群需要重新启动，我们需要有 30 分钟的停机时间所有最终用户

您是否查看过不同的部署策略，例如 Canary 部署/蓝绿部署？负载均衡器后面是否有多个实例？

【讨论】：

负载均衡器后面有 4 个实例。我们没有尝试不同的部署策略。
为什么不进行轮换部署以避免停机？（如果你非常喜欢支付oracle并保留websphere）