【发布时间】：2011-12-03 21:08:56
【问题描述】：
我们有一个计算密集型服务，用于执行许多转换。它在很大程度上受计算限制（CPU 限制）的过程。本质上，我们有一个消息代理，它通过 Thrift 将消息发送到处理服务。
现在我们有多个不同的处理服务，它们运行不同的算法来处理消息 - 这些消息被路由到一个或多个处理算法。我们的消息量是可变的，处理算法的需求也是可变的（即，我们可以获得许多包含 XYZ 的消息，然后发送到算法 1，否则发送到算法 2）。
我们希望将其扩展为可水平扩展的东西。所以我们有多个节点正在运行处理算法。现在根据消息负载，我们的 Thrift 请求应该被发送到不同的服务器（假设所有服务都在运行每个处理 Algo1 到 3 的实例）。例如，我们要在算法 1 上处理大量消息，然后我们有两台服务器运行算法 1，第三台服务器负责其他两个算法（算法 2 和 3）的请求。
所以系统看起来像这样：
Client ----Request-------|
-----------|--------------------
| Coord & Load Balancer Service | ... like zookeeper
--------------------------------
<--|-->
| Route messages to servers...
Server1: Server2: Server 3:
Algo1 instance Algo1 instance Algo2 instance
Algo3 instance
所有进程都是用 Java 编写的。
那么使用 Zookeeper 设置这样的事情是多么容易。我知道当我们添加或更改算法时，我们可以轻松地使用 Zookeeper 来处理配置方面的事情（即服务器侦听算法更新或添加并按照配置提供服务）但是我们如何管理负载平衡方面呢？
干杯！
【问题讨论】：
-
嗨，这个问题你解决了吗？我能问一下你是怎么做到的吗？我现在正在研究同样的问题（可扩展的自我维护的节俭服务部署），任何经验或建议都会很高兴;-)
-
@Sergey Vasilyev，我们以与 Norbert 做事的方式类似的方式实现了自己的解决方案，即顶级 ZooKeeper（功能更少）。如果有空闲时间，可以考虑实施 Norbert，非常漂亮的项目。 IMO 不做我们所做的，看看下面乔纳斯的回答。如果您还想了解有关我们 impl 的更多信息，请告诉我。
-
是的，类似于 Norbert，除了我使用 Python 和 PHP（已经）并且将来将使用 Java 和 C/C++（最近或足够远——尚未决定）。这就是我选择 Thrift 作为 RPC 解决方案的原因。唯一剩下的就是负载平衡和集群管理。 ZooKeeper 看起来不错，但我正在寻找特定的架构解决方案。诺伯特，正如那张照片所见，是我正在寻找的基本概念。那么，它好吗？稳定吗？容易管理吗？或者你能描述一下你是如何解决这个问题的吗？我的 Jabber 是“nolar@nolar.info”，Skype 是“nolar.info”。谢谢:)
-
PS：当我问“好不好”等时，我指的是概念，而不是 Norbert 本身:-)
-
真的取决于你的用例，马适合课程。对我们（分布式分类）来说，这很有意义。实际上，对于您希望避免使用集中式负载均衡器的任何应用程序，它都是有意义的。然而，有几点需要注意，主要是关于信任；即我们的客户负责负载平衡这一事实。恶意客户端可能会攻击加载的服务器以创建 DOS 情况。使用透明的集中式负载均衡器，这不是什么大问题。因此，如果您在设计基础架构时考虑到这一点，那么它是一个很好的解决方案。
标签： java load-balancing distributed-computing thrift apache-zookeeper