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

huangapple go评论73阅读模式
英文:

Server design suggestions to support multiple workflows managed by multiple teams

问题

寻找解决设计问题的输入。我们正在重新设计我们现有的服务器,目前已经运行良好,但在未来将无法扩展。

当前设计: 这是一个服务器(我们运行多个相同服务器的实例),拥有许多工作流程。让我们称这些工作流程为A、B、C、D,在服务器内部处理。到目前为止,我们有一个开发团队在这个服务器上工作,这使得发布工作变得容易。性能也相当不错,因为我们利用了内存缓存。

未来设计: 现在我们有多个团队(每个团队处理一个工作流程,团队A处理工作流程A,团队B处理工作流程B等等)。有了这个新的团队结构和当前的设计,我们无法扩展我们的发布(因为只有一个服务器,每次只有一个团队发布,从而降低了整体团队效率)。有必要进行隔离,以便团队可以独立发布其对工作流程的更改。此外,我们预计将有更多的工作流程加入到这个服务器中。

对于如何解决不断增加的工作流程问题,有什么设计思路吗?

我目前的解决方案: 将服务器分成4个服务器,以便每个团队可以单独管理工作流程。这种方法的缺点是代码管理。大多数这些工作流程共享共同的代码库。此外,分割服务器会导致我们失去缓存(这在当前设计中不是问题)。

期待听到您的建议。

英文:

Looking for inputs to a design problem. We are redesigning our existing server which has served well so far but won't scale in the future.

Current design: It is one server(we run multiple instances of the same server) which has many workflows. Lets call these workflows A,B,C,D handled inside the server. Until now, we have one development team working on this server which made handling releases easy. Performance is also decent because we leverage in memory caching.

Future design: We now have multiple teams(each team handling one workflow, Team A handling workflow A, Team B handling workflow B and so on). With this new team structure and current design, we are unable to scale our releases(Since its one server, we have only one team releasing at any given time thus reducing overall team efficiency). There is a need for isolation so teams can release their changes to workflows independent of each other. Also, we expect more workflows to be on-boarded into this server.

Any design ideas on how we can solve this problem of ever increasing workflows

My current solution: Split the server into 4 servers so each team can manage the workflows individually. The disadvantage with this approach is the code management. Most of these workflow share common code base. Also, splitting the server causes us to lose out on cache(which is not an issue with current design)

Look forward to hearing your suggestions.

答案1

得分: 2

按照不同团队划分为不同工作流程是有道理的。一些可能的优势包括:

  1. 像你提到的那样,独立的发布。
  2. 工作流程A中的崩溃/内存泄漏/资源占用不会影响工作流程B。
  3. 每个工作流程服务器可以独立扩展。一个受欢迎的工作流程A可以扩展到更多的服务器,而很少使用的工作流程B可以仅使用1台服务器。

可能还有更多的优势,只是指出了显而易见的支持分割的一些。

如何处理劣势 - 让我们尝试通过图书管理系统的示例来理解。假设我们需要为会员借书、会员还书和注册新会员的工作流程。

大多数这些工作流程共享相同的代码库

为了解决这个问题,我们需要识别共同部分的核心部分,在我的示例中,我将采用书籍(id、名称、领域)和会员(id、名称、电子邮件)的定义。除了定义之外,我还可以有在它们上工作的通用函数,如序列化器、解析器、验证器。

现在,我的工作流程将依赖于这个共同的代码库。借书工作流程将与添加会员工作流程完全不同,但它们将使用相同的构建模块。

服务器导致我们失去了缓存

确切地说,需要缓存什么以及缓存的行为非常重要。

一个相当静态的缓存(比如会员缓存)可以在分布式缓存中设置,比如Redis。假设有一个工作流程,它将识别借出书籍的截止日期,并向那些会员发送提醒电子邮件。一旦会员ID被识别出来,它们的电子邮件可以在Redis缓存中查找。

工作流程还可以拥有个性化的缓存。例如,在图书馆中搜索书籍时,结果可以仅在工作流程服务器内存中缓存,并且带有TTL,如果在不久的将来提出相同的查询,可以提供服务。

总之,你所面临的劣势只不过是设计挑战。我希望通过这个随机示例,我能给你一些值得思考的观点。根据你的实际用例,我的答案可能完全不相关。如果是这样,请接受我的诚挚道歉。 服务器设计建议,以支持由多个团队管理的多个工作流程。

英文:

Splitting into different workflow according to different teams makes complete sense. Some advantages that come to mind are:

  1. Independent releases like you mentioned.
  2. Crashes/Memory leaks/resource hogging from workflow A won't affect workflow B
  3. Each Workflow server can be scaled independently. A popular workflow A could be scaled to say more servers while a rarely used workflow B could be working with just 1 server.

There could be more, just pointing out the obvious ones supporting the split.

How to handle disadvantages - let us try to understand with the example of Library Management System. Let us say we need workflows for member borrowing a book, member returning a book, registering a new member.

Most of these workflow share common code base

To resolve this we identify the core common part, in my example I will take definition of book(id, name, field), member(id, name, email). Besides the definitions, I can also have common functions that work on them, like serialisers, parsers, validators.

Now my workflow/s will depend on this common repo. The borrow book workflow will completely be different from add a member workflow, but they will use the same building blocks.

the server causes us to lose out on cache

Exactly what needs to cached and what is the behaviour of the cache is very important.

A fairly static cache(say member cache) can be setup on distributed cache like redis. Say there is a workflow which will identify the close deadlines for the borrowed books and send reminder emails to those members. Once the member ids are identified, their emails could be looked up in the redis cache.

A workflow can have a personalised cache as well. For example during searching for books in the library with the name, the result can be cached in the workflow server only in memory with a TTL, and can be served if same query is asked in near future.

To conclude, the disadvantages you have are nothing but design challenges. I hope that with this random example I was able to give you a few points to wonder upon. Depending on your actual use case, my answer might completely be irrelevant. If so, sincere apologies. 服务器设计建议,以支持由多个团队管理的多个工作流程。

huangapple
  • 本文由 发表于 2020年8月4日 19:36:33
  • 转载请务必保留本文链接:https://go.coder-hub.com/63246064.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定