在基础结构原语的上下文中，工作人员和服务之间的差异

Question

我正在构建基础结构原语以支持工作程序和http服务。

 - workers are standalone
 - http services have a web server and a load balancer

按照我的理解，当服务处理入站请求并与上游服务进行对话时，工作人员通常会从外部资源中提取任务来使用任务。

Celery是明显的工作人员，而Web应用是明显的服务。线条可能会变得模糊，我不确定最好的方法是：

  - Is the worker/service primitive a good idea?
  - What if there's a service that consumes tasks like a worker but also handles some http requests to add tasks? Is this a worker or a service?
  - What about services that don't go through nginx, does that mean a third "network" primitive with an NLB is the way to go?
  - What about instances of a stateful service that a hub service connects to? The hub has to know the individual instances so we cannot

将它们隐藏在LB后面。您将如何表示呢？

Answer 1

• 工作者/服务原语是个好主意吗？

IMO，服务与工人之间的主要区别在于，工人只能指定一个任务，而服务可以执行多个任务。服务可以利用一个或多个工作人员来处理用户请求。

• 如果有一项服务像工作人员一样消耗任务，但又处理一些添加任务的http请求，该怎么办？

服务可以采用不同形式，例如Web服务，FTP服务，SNMP服务或加工服务。除非采用工作程序的形式，否则在服务中编写处理逻辑可能不是一个好主意。

• 不经过nginx的服务该怎么办，这是否意味着第三个带有NLB的“网络”原语是可行的方式？

我相信您假设服务仅基于HTTP，但是正如我在前面的答案中提到的那样，服务可以是不同的类型。是的，您可以为特定协议实现编写TCP服务，该服务可以附加在NLB后面]

• 中心服务连接到的有状态服务的实例如何？集线器必须知道各个实例，因此我们不能将它们隐藏在LB后面。

不确定在这里所说的集线器是什么意思？但是，可伸缩体系结构的良好做法是在后面使用无状态服务器/服务。会话状态不应存储在服务内存中，而应序列化到DynamoDB之类的数据存储。