V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
v2byy
V2EX  ›  程序员

有关 microservice 的 pipeline 处理

  •  
  •   v2byy · 2022-05-24 22:11:02 +08:00 · 1421 次点击
    这是一个创建于 673 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    应该如何设计比较好?

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

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

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

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

    14 条回复    2022-05-25 09:58:14 +08:00
    T0m008
        1
    T0m008  
       2022-05-25 02:10:47 +08:00
    微服务的意义就在于把不需要紧密依赖的模块剥离出去,你这微服务之前相互依赖就失去了微服务的意义了。
    casparchen
        2
    casparchen  
       2022-05-25 02:15:17 +08:00
    pub/sub
    arloor
        3
    arloor  
       2022-05-25 02:40:08 +08:00 via Android
    把 microservice 去掉吧
    跟这没啥关系
    就一分布式流处理啊。用 mq 哪里不好
    Chad0000
        4
    Chad0000  
       2022-05-25 04:36:22 +08:00 via iPhone
    op 了解一下 dapr
    v2byy
        5
    v2byy  
    OP
       2022-05-25 08:13:00 +08:00
    @T0m008 微服务之间肯定需要通信。如果紧密依赖的话,相关逻辑整合成一个微服务?
    v2byy
        6
    v2byy  
    OP
       2022-05-25 08:20:34 +08:00
    @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
        7
    v2byy  
    OP
       2022-05-25 08:22:23 +08:00
    @Chad0000 多谢,简单了解了一下,是通过给每个 pod 一个 side-car 的方式。这样会不会有很大的 overhead 呢?我们现在一个 pod 都是一个 container
    Chad0000
        8
    Chad0000  
       2022-05-25 08:38:17 +08:00   ❤️ 1
    @v2byy #7
    Dapr 是用 Go 开发的,Sidecar 比较小。至于对于性能的影响,官方的说法是 1000/s 的请求只需 0.5 核 CPU 。使用微服务本身就是进一步隔离不同服务但同时降低了单个服务实例的性能。我选 Dapr 主要是它将分布式开发所需模块都集成,比如服务发现、状态存储、事件等等。它还有自动重试以及保证到达,Actor 模型等有用的功能。以及切换中间件都无需修改代码,大大简化了微服务的开发。

    至于性能影响还是以实际测试为主,比如测试一下带不带 Sidecar 的影响。我们现在都没上微服务,准备将一个传统应用迁移到 Dapr 。
    Chad0000
        9
    Chad0000  
       2022-05-25 08:42:18 +08:00
    @v2byy 而且我这边是海外公司,To B ,数据量大但用户访问量没那么大。我们做了大量第三方对接,都在一个项目直接引用难以管理。将每个对接方独立成服务使用 Dapr 隔离开,是一个很不错的方案。
    aitaii
        10
    aitaii  
       2022-05-25 08:53:40 +08:00 via Android
    Spring Cloud 的话,我们用过 dataflow ,看你的描述蛮符合的
    dayeye2006199
        11
    dayeye2006199  
       2022-05-25 08:58:20 +08:00
    xuanbg
        12
    xuanbg  
       2022-05-25 09:33:17 +08:00
    OP 你的微服务的边界定义有问题。哪有把不同服务串成流水线的。。。
    nothingistrue
        13
    nothingistrue  
       2022-05-25 09:40:17 +08:00   ❤️ 1
    pipeline 的话,风格已经从业务,变成数据流了。数据流适合处理流程化、大量,但是批量集中的场景,这时候在用微服务不合适——流程化、大量,甚至批量都好说,但是集中处理,微服务与之犯冲。此外,如果流程的异常、反向分支很多的话,这时候用数据流也不合适。

    你这个需求可能应当考虑的是长时处理过程,而不是“流”,可以参考: https://www.jdon.com/49216
    T0m008
        14
    T0m008  
       2022-05-25 09:58:14 +08:00
    @v2byy 对,紧密依赖就应该放到一个微服务里面,微服务并不是一个服务承担一种职责。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5334 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 38ms · UTC 09:21 · PVG 17:21 · LAX 02:21 · JFK 05:21
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.