响应式微服务 in java 译 <十七> Deploying a Microservice in OpenShift

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/

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