是的，我们是响应式，让我们来看看为什么。

我们所有的交互都是异步的。它们使用异步和非阻塞HTTP请求和响应。另外，由于OpenShift的service，我们将请求发送到一个虚拟地址，这使得我们的系统具有可伸缩性。该服务在一组pods中平衡负载。通过调整pod的数量或使用自动伸缩，我们可以轻松地上下伸缩。我们也有弹性。由于健康检查，我们有一个故障转移机制，确保我们总是有某个数量的pod在正确的运行着。在消费者端，我们可以使用各种弹性模式，如超时、重试或断路器来保护微服务免受故障的影响。因此，我们的系统能够在高负载和面对故障时及时处理请求:我们是可响应的了!

任何使用异步非阻塞HTTP的系统都能在提供负载均衡和一些弹性特性的云中变成响应式系统吗?是的，但是不要忘了代价。Veret.x使用一个事件循环来处理高级别的并发性，并使用最少的线程，显示了一种云原生性质。当使用依赖线程池的方式时，您需要1）调整线程池以找到正确的大小;2)处理代码中的并发性，这意味着调试死锁、竞态条件和瓶颈;和3)监视性能。云环境是基于虚拟化的，当你有许多线程的时候，线程调度可能成为一个主要问题。

这里有很多非阻塞技术，但不是所有的都使用相同的执行模型来处理异步性质我们可以将这些技术分为三类:

1.在后台使用线程池的方法——然后您将面对一个调优、调度和并发性的挑战，将负担转移到ops。

2.为回调使用另一个线程的方法——您仍然需要管理代码的线程安全，同时避免死锁和瓶颈。

3.如Vert.x使用相同的线程的方法——您使用少量的线程，并从调试死锁中解放出来。

我们是否可以在云中使用消息传递系统来实现响应式微服务系统?当然可以。我们可以使用Vert.x 的事件总线在OpenShift中构建我们的响应式微服务。但它无法证明由OpenShift提供的service virtual address和负载均衡，因为它可能是由Vert.x自身处理的。在这里，我们决定使用HTTP，毕竟HTTP也是无数的选择。以你想要的方式塑造你的系统!