支持由多个团队管理的多个工作流的服务器设计建议

Question

寻找设计问题的输入。我们正在重新设计我们现有的服务器，该服务器目前运行良好，但未来不会扩展。

当前设计：它是一台服务器（我们运行同一台服务器的多个实例），它有许多工作流。让我们将这些工作流称为在服务器内部处理的 A、B、C、D。到目前为止，我们有一个开发团队在这个服务器上工作，这使得处理版本变得容易。性能也不错，因为我们利用了内存缓存。

未来设计：我们现在有多个团队（每个团队处理一个工作流程，A 团队处理工作流程 A，B 团队处理工作流程 B，等等）。有了这种新的团队结构和当前的设计，我们无法扩展我们的发布（因为它只有一台服务器，我们在任何给定时间只有一个团队发布，从而降低了整体团队效率）。需要隔离，以便团队可以相互独立地发布对工作流的更改。此外，我们希望在此服务器中加入更多工作流。

关于我们如何解决这个不断增加的工作流程问题的任何设计想法

我当前的解决方案：将服务器拆分为 4 台服务器，以便每个团队可以单独管理工作流程。这种方法的缺点是代码管理。这些工作流程中的大多数共享通用代码库。此外，拆分服务器会导致我们丢失缓存（这不是当前设计的问题）

期待听到您的建议。

Answer 1

根据不同的团队分成不同的工作流程是完全合理的。想到的一些优点是：

1. 您提到的独立版本。
2. 工作流 A 的崩溃/内存泄漏/资源占用不会影响工作流 B
3. 每个工作流服务器都可以独立扩展。一个流行的工作流 A 可以扩展为更多的服务器，而一个很少使用的工作流 B 可以只使用 1 个服务器。

可能还有更多，只是指出支持分裂的明显因素。

如何处理缺点 - 让我们尝试以图书馆管理系统的例子来理解。假设我们需要会员借书、会员还书、注册新会员的工作流程。

Most of these workflow share common code base

为了解决这个问题，我们确定了核心公共部分，在我的示例中，我将定义 book(id, name, field), member(id, name, email)。除了定义之外，我还可以使用常用函数，例如序列化器、解析器、验证器。

现在我的工作流程将依赖这个公共回购。借书工作流程将与添加成员工作流程完全不同，但它们将使用相同的构建块。

the server causes us to lose out on cache

究竟什么需要缓存，缓存的行为是什么非常重要。

可以在像 redis 这样的分布式缓存上设置一个相当静态的缓存（比如成员缓存）。假设有一个工作流程可以确定借书的截止期限并向这些成员发送提醒电子邮件。一旦识别出成员 ID，就可以在 redis 缓存中查找他们的电子邮件。

工作流也可以有个性化的缓存。例如在图书馆中搜索具有名称的书籍时，结果可以缓存在工作流服务器中，仅在内存中具有 TTL，并且可以在不久的将来询问相同的查询时提供。

总而言之，您的缺点只不过是设计挑战。我希望通过这个随机的例子，我能给你一些值得思考的问题。根据您的实际用例，我的回答可能完全无关紧要。如果是这样，真诚的道歉。 :)