假设
- 我正在构建一个无状态的微服务，它公开了一些简单的API端点(例如，一个read-through缓存，将一个条目保存到数据库(
- 我使用的是非阻塞数据库客户端，例如mysql或redis和
- 我一直希望我的微服务通过HTTP相互通信(通过将EC2实例放在负载均衡器后面(
问题
- 我什么时候想使用1个以上的标准verticals(即，将整个微服务写为一个vertical，并部署n个实例(n=事件循环线程数((？。增加更多的垂直领域不会只增加序列化和上下文切换成本吗
- 比方说，我将微服务划分为多个标准垂直领域(无论出于何种原因(。部署每个实例的n个(n=num个事件循环线程(实例不会总是比部署不同比例的实例提供更好的性能。由于每个垂直线程只是一个地址上的侦听器，这意味着每个事件循环线程都可以处理各种消息，并且它们已经实现了负载平衡
- 我想什么时候在集群模式下运行我的应用程序？基于文档，我觉得只有当你有多个垂直领域时，集群模式才有意义，当你有集群的实际用例时，也有意义。例如，不同的EC2实例处理不同用户的请求，以帮助实现数据本地化(比如使用点火(
p.S.，如果您能回答上述问题之一，请提供帮助。
我一直希望我的微服务通过HTTP(通过将EC2实例放在负载均衡器后面(相互通信
如果你已经采用了这种过于复杂的方法，那么使用Vertx并没有多大意义。Vertx使用事件总线进行集群内通信，消除了对HTTP和LB的需求。
答案：
-
为什么要这样？如果垂直线之间没有通信，那么序列化开销应该发生在哪里？
-
如果你的垂直应用程序使用非阻塞调用(因此是多线程的(，你不会看到同一台机器上的1个或N个实例之间有任何区别。此外，如果您的vertical在某个端口上启动了一个(HTTP(服务器，那么所有实例都将在所有线程上共享该服务器(vertx在这里进行了一些神奇的重新路由(
-
集群模式是我在开头提到的。这是分发和扩展微服务的正确方式。
-
垂直线是构建代码的一种方式。所以，当你的主垂直线变得太大时，你可能会想要另一种类型的垂直线。有多大？这取决于你的喜好。我尽量把它们保持得很小，最多200 LOC左右，做一件事。
-
不一定。不同的垂直行业可以以不同的速度执行非常不同的任务。拥有所有这些实例的N个实例并不一定是坏的，而是多余的。
-
可能永远不会。集群模式是微服务之前的事情。使用它会增加另一个级别的复杂性(集群管理器，例如Hazelcast(，这也意味着你不能像精通多种语言一样。