响应式微服务 in java 译 <十一> Are We Reactive Now?

 Are We Reactive Now?

咱们以前写的这段代码和基于 HTTP 微服务很是接近，区别就是咱们用了 event bus 取代了 HTTP，这个能够改变个人响应式服务吗？是的，咱们来看看为何。

Elasticity

弹性的分布式是以前的 HTTP 版本作不到的，由于 microservice 调用服务的时候用了一个固定的 URL，没有提供咱们须要的分布式（固然改进经过其余技术仍是能够的），可是如今咱们使用消息发送到某个地址，改变了这个游戏，让咱们看看这个微服务系统怎么行为吧。

你还记得以前执行的输出，返回的JSON 显示了 verticle 计算的输出，输出显示老是同一个 verticle，消息也是显示是同一个实例，由于咱们只有一个实例在运行，而后咱们运行两个实例会发生什么。

中止 Hello microservice 的执行，而后运行下面的命令：

而后，打开两个终端在 hello-microservice 消息目录，执行如下命令（在每个终端）：

这样启动了两个 hello microservice 的实例，回到浏览器，刷新页面，你可能看到以下的结果：

咱们使用了来给你个 Hello 实例，Vert.x 集群链接了不一样的节点，event bus 也是一个集群，得益于 event bus 的 round-robin ，Vert.x event bus 分发消息到不一样的可执行的实例，并且作了负载均衡的事情。

所以用了 event bus ，咱们有了须要的弹性分布式特性。

Resilience

关于快速恢复（失败）呢？在如今的节点里，若是hello microservice 失败了，咱们获得一个 failure 和执行下面的代码：

即便用户获取到一个 error mesage，咱们没有崩溃，也没有限制了拓展性，咱们仍然能够处理这个请求。而后，为了改善咱们的用户体验，咱们应该老是及时回复给用户，即便咱们没有从service获取响应，为了实现这个逻辑，咱们可使用超时的代码。

为了说明这一点，让咱们修改hello microservice 注入故障和问题行为。这段代码在microservices/ hello-microservice-faulty 文件下。

这个start 方法随机从三种启动策略中选好一种：1.响应失败，2.忘记响应（调用方超时），3.发送正确的结果

从新打包和启动这两个 hello microservice 的实例。

由于注入了失败的状况，因此咱们改进消费房错误的容忍度，实际上，消费方可能获取一个超时或者失败的状况，在 hello consumer microservice 中，咱们改变代码调用方式：

代码位于microservices/hello-consumer- microservice-timeout 文件夹下，超时的方法在给定时间内没有获取服务的回应就会提出失败，重试的方法将会执行重试，在响应失败或者超时的状况下。subscribeon方法指出哪一个线程调用须要作，咱们使用event bus loop 调用 callbacks。若是没有这个，方法将会执行默认Rxjava 线程池，打破了 Vert.x 线程模型。Vert.x 提供的 RXHelper 类盲目尝试调用服务并非一个很聪明的容错策略。它甚至能够是有害的，下一章详细介绍了不一样的方法。

如今你能够从新载入这个页面，你老是会获取一个结果，即便是失败或者超时，当调用服务的时候线程没有被阻塞，所以你能够继续接收请求，而且即便响应，因此这里实现的超时重试形成的伤害大于好处，咱们将在下一章接续讨论。

Summary

在这个章节中，咱们先是用HTTP实现微服务，URL使用硬编码打破了响应式编程的其中一个特性，所以接下来咱们使用了消息机制，看到 event bus 怎么帮助咱们实现响应式服务。

咱们构建了响应式服务，可是这里还有一些短板咱们须要关注。若是咱们仅仅使用HTTP 服务呢？咱们怎么避免硬编码呢？关于快速恢复？咱们在这里看到了超时和重试，可是断路器，失效备援，隔离呢？让咱们继续以后的学习。

 

原文地址：

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

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