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

最新推荐文章于 2021-02-27 04:58:17 发布

weixin_33714884

最新推荐文章于 2021-02-27 04:58:17 发布

阅读量83

点赞数

原文链接：https://my.oschina.net/u/2277632/blog/1633377

版权

2019独角兽企业重金招聘Python工程师标准>>>

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服务器是否已经启动。