有关 microservice 的 pipeline 处理

[v2byy]

在微服务中，一般一个服务承担一种职责。如果各个微服务之间是流水线处理，即一个微服务的 output 是另外一个微服务的 input ，对于一个任务来说，需要依次被这些微服务处理。

应该如何设计比较好？

如果是 RESTful API ，则需要一个中心的类似 dispatcher 一类的微服务，这样问题是一些微服务处理事件比较长，则 HTTP 等待的事件也比较长，容易形成瓶颈。

如果是 EDA(Event Driven Architecture)，则每个微服务都使用 message queue 连接，似乎也不太合理，因为任务可以认为是串行的。微服务多，那 queue 的层级也比较多。

或者将这两种方式综合起来？

大家在微服务中有什么 best practice 吗？

[T0m008]

微服务的意义就在于把不需要紧密依赖的模块剥离出去，你这微服务之前相互依赖就失去了微服务的意义了。

[casparchen]

pub/sub

[arloor]

把 microservice 去掉吧
跟这没啥关系
就一分布式流处理啊。用 mq 哪里不好

[Chad0000]

op 了解一下 dapr

[v2byy]

@T0m008 微服务之间肯定需要通信。如果紧密依赖的话，相关逻辑整合成一个微服务？

[v2byy]

@casparchen
@arloor

看了一下 AMQP 协议中的 message model 中的 direct exchange 方式，貌似可以符合这个的场景。可以使用 routing key 来确定 broker 分发到哪个 queue 中。但是我们准备用托管的 message queue ，比如 azure 的 service bus 等，这种假设要新增一个微服务组件，需要提前建立新 queue （需要动 infra ）。

我上面说的 queue 的层级太多，有点像是这篇文章中的第二种情况:

https://dzone.com/articles/7-microservices-best-practices-for-developers

Chained asynchronous communication between microservices

[v2byy]

@Chad0000 多谢，简单了解了一下，是通过给每个 pod 一个 side-car 的方式。这样会不会有很大的 overhead 呢？我们现在一个 pod 都是一个 container

[Chad0000]

@v2byy #7
Dapr 是用 Go 开发的，Sidecar 比较小。至于对于性能的影响，官方的说法是 1000/s 的请求只需 0.5 核 CPU 。使用微服务本身就是进一步隔离不同服务但同时降低了单个服务实例的性能。我选 Dapr 主要是它将分布式开发所需模块都集成，比如服务发现、状态存储、事件等等。它还有自动重试以及保证到达，Actor 模型等有用的功能。以及切换中间件都无需修改代码，大大简化了微服务的开发。

至于性能影响还是以实际测试为主，比如测试一下带不带 Sidecar 的影响。我们现在都没上微服务，准备将一个传统应用迁移到 Dapr 。

[Chad0000]

@v2byy 而且我这边是海外公司，To B ，数据量大但用户访问量没那么大。我们做了大量第三方对接，都在一个项目直接引用难以管理。将每个对接方独立成服务使用 Dapr 隔离开，是一个很不错的方案。

[aitaii]

Spring Cloud 的话，我们用过 dataflow ，看你的描述蛮符合的

[dayeye2006199]

https://temporal.io/

[xuanbg]

OP 你的微服务的边界定义有问题。哪有把不同服务串成流水线的。。。

[nothingistrue]

pipeline 的话，风格已经从业务，变成数据流了。数据流适合处理流程化、大量，但是批量集中的场景，这时候在用微服务不合适——流程化、大量，甚至批量都好说，但是集中处理，微服务与之犯冲。此外，如果流程的异常、反向分支很多的话，这时候用数据流也不合适。

你这个需求可能应当考虑的是长时处理过程，而不是“流”，可以参考： https://www.jdon.com/49216

[T0m008]

@v2byy 对，紧密依赖就应该放到一个微服务里面，微服务并不是一个服务承担一种职责。