Scale Up and Down

如果我们使用云平台，主要是出于可伸缩性的原因。我们希望能够根据负载增加和减少应用程序实例的数量。在OpenShift仪表板中，我们可以上下缩放吊舱的数量，如图5-5所示。

您还可以使用oc命令行设置副本的数量：

让我们创建Hello微服务的第二个实例。然后，等到第二个微服务正确启动(等待时间很烦人，但稍后我们会修复它)，然后返回浏览器中的hello-consumer 页面。你应该可以看到以下的：

如果您多次刷新，您将看到OpenShift服务平衡了两个实例之间的负载。你还记得我们禁用的“keep-alive”设置吗？当HTTP连接使用一个 keep-alive 的连接时，OpenShift将请求转发到相同的 pod ，从而提供连接的密切性。请注意，在实践中， keep-alive 是一个非常理想的头部，因为它允许重用connec-tions。

在前面的场景中，有一个小问题。当我们进行扩展时，OpenShift开始向新的 Pod 发送请求，而不检查应用程序是否准备好处理这些请求。因此，我们的消费者可能会调用一个一个还没有准备好的微服务，然后失败。有几种方法可以解决这一问题：

1.在微型服务中使用健康检查

2.准备好面对消费者代码的失败

Health Check and Failover

在OpenShift中，您可以声明两种类型的检查。准备状态检查用于在更新微服务时避免停机。在滚动更新中，openShift会等到新版本准备好后再关闭上一个版本。ping新的微服务的就绪状态检查端点，直到它准备好为止，并验证微服务是否已成功初始化。活性检查用于确定一个 Pod 是否还活着。OpenShift定期调用活性检查端点。如果 pod 没有正面回复检查，它将被重新启动.。活性检查的重点是微服务需要哪些关键资源才能正常工作。在下面的示例中，我们将对两个检查使用相同的端点。但是，最好使用两个不同的端点。

此示例的代码包含在OpenShift/hello-microservice-OpenShift-Health-Check目录中。如果打开verticle，您将看到HealthCheck处理程序验证HTTP服务器是否已经启动。

Fabric8Maven插件被配置为使用/健康来进行就绪和活性健康检查。一旦部署了这个版本的hellomicroservice，所有后续部署都将使用就绪检查来避免停机，如图5-6所示：

当 Pod 准备好后，OpenShift将请求路由到这个 Pod 并关闭旧的。当我们扩大规模时，OpenShift不会将请求路由到尚未准备好的 Pod。

原文地址：

https://developers.redhat.com/promotions/building-reactive-microservices-in-java/

有什么讨论的内容，可以加我微信公众号：