有关 microservice 的 pipeline 处理

v2byy 会员 2022年5月24日 14:28 发表

• 

  T0m008 会员

  2022年5月24日 18:26
  微服务的意义就在于把不需要紧密依赖的模块剥离出去，你这微服务之前相互依赖就失去了微服务的意义了。
  0 0
  评论

• 

  casparchen 会员

  2022年5月24日 18:26
  pub/sub
  0 0
  评论

• 

  arloor 会员

  2022年5月24日 18:57
  把 microservice 去掉吧 跟这没啥关系 就一分布式流处理啊。用 mq 哪里不好
  0 0
  评论

• 

  Chad0000 会员

  2022年5月24日 20:56
  op 了解一下 dapr
  0 0
  评论

• 

  v2byy 会员 (楼主)

  2022年5月25日 00:28
  微服务之间肯定需要通信。如果紧密依赖的话，相关逻辑整合成一个微服务？
  0 0
  评论

• 

  v2byy 会员 (楼主)

  2022年5月25日 00:28
  @ 看了一下 AMQP 协议中的 message model 中的 direct exchange 方式，貌似可以符合这个的场景。可以使用 routing key 来确定 broker 分发到哪个 queue 中。但是我们准备用托管的 message queue ，比如 azure 的 service bus 等，这种假设要新增一个微服务组件，需要提前建立新 queue （需要动 infra ）。 我上面说的 queue 的层级太多，有点像是这篇文章中的第二种情况: Chained asynchronous communication between microservices
  0 0
  评论

• 

  v2byy 会员 (楼主)

  2022年5月25日 00:28
  多谢，简单了解了一下，是通过给每个 pod 一个 side-car 的方式。这样会不会有很大的 overhead 呢？我们现在一个 pod 都是一个 container
  0 0
  评论

• 

  Chad0000 会员

  2022年5月25日 00:56
  #7 Dapr 是用 Go 开发的，Sidecar 比较小。至于对于性能的影响，官方的说法是 1000/s 的请求只需 0.5 核 CPU 。使用微服务本身就是进一步隔离不同服务但同时降低了单个服务实例的性能。我选 Dapr 主要是它将分布式开发所需模块都集成，比如服务发现、状态存储、事件等等。它还有自动重试以及保证到达，Actor 模型等有用的功能。以及切换中间件都无需修改代码，大大简化了微服务的开发。 至于性能影响还是以实际测试为主，比如测试一下带不带 Sidecar 的影响。我们现在都没上微服务，准备将一个传统应用迁移到 Dapr 。
  0 0
  评论

• 

  Chad0000 会员

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

• 

  aitaii 会员

  2022年5月25日 00:56
  Spring Cloud 的话，我们用过 dataflow ，看你的描述蛮符合的
  0 0
  评论

• 

  dayeye2006199 会员

  2022年5月25日 01:28
  0 0
  评论

• 

  xuanbg 会员

  2022年5月25日 01:59
  OP 你的微服务的边界定义有问题。哪有把不同服务串成流水线的。。。
  0 0
  评论

• 

  nothingistrue 会员

  2022年5月25日 01:59
  pipeline 的话，风格已经从业务，变成数据流了。数据流适合处理流程化、大量，但是批量集中的场景，这时候在用微服务不合适——流程化、大量，甚至批量都好说，但是集中处理，微服务与之犯冲。此外，如果流程的异常、反向分支很多的话，这时候用数据流也不合适。 你这个需求可能应当考虑的是长时处理过程，而不是“流”，可以参考：
  0 0
  评论