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

问个 Java 微服务的问题,大佬速进

  •  
  •   RichardX2023 · 2024-01-31 15:06:38 +08:00 · 3068 次点击
    这是一个创建于 382 天前的主题,其中的信息可能已经有所发展或是发生改变。

    java 微服务的问题,如果目前有 5 个模块,每个模块都需要进行 [查询] 和 [数据导出] 。 那 [数据导出] 一旦有需求变动,就会导致各个模块来回改, 但是如果单独把导出业务作为一个模块来处理,就需要各个模块把查询返回的数据,传输给导出模块。

    一边是需要来回改,一边是远程调用的花销和性能影响,如何权衡。

    20 条回复    2024-02-01 16:42:48 +08:00
    dayeye2006199
        1
    dayeye2006199  
       2024-01-31 15:08:18 +08:00
    做成一个包,各个模块引入一下不可以吗?
    有变动就更新一下包
    c3de3f21
        2
    c3de3f21  
       2024-01-31 15:14:22 +08:00
    - 首先,改肯定是得改的,这属于正常的版本迭代
    - 其次,个人认为提 单独模块(API 也好其他的调用方式也好) 总好过 各个模块来回改
    - 在者,个人认为微服务首先应有 CI ,后续应有健全的版本发布,部署机制才可以搞,不然手动操作太麻烦
    - 微服务本身就停消耗资源的
    fengpan567
        3
    fengpan567  
       2024-01-31 15:21:26 +08:00
    各个模块的导出功能是独立的,啥需求每次都要把所有的导出都改了?不同服务导出的数据内容又不是一样的
    RichardX2023
        4
    RichardX2023  
    OP
       2024-01-31 15:22:47 +08:00
    @dayeye2006199 是个思路
    RichardX2023
        5
    RichardX2023  
    OP
       2024-01-31 15:23:29 +08:00
    @c3de3f21 是的,有 DevOps
    v2zzzzz
        6
    v2zzzzz  
       2024-01-31 15:25:53 +08:00   ❤️ 1
    我们是导出服务直接多数据源连读库
    RichardX2023
        7
    RichardX2023  
    OP
       2024-01-31 15:28:18 +08:00
    @fengpan567 不是每次,不频繁。比如这次,由原先的实时导出改为做成一个导出中心,通过用户下载的方式实现。
    改动就是把每次请求返回导出的 excel ,切换为导出推送到 oss ,并产生一个推送记录,用户通过推送记录获取 oss 的 url 来下载
    yaodao
        8
    yaodao  
       2024-01-31 15:39:03 +08:00
    如果导出的功能比较单纯,不涉及到连接数据库和其他中间件,那么一楼给出的建议是最好的,直接以 jar 包的方式依赖( maven or gradle )进需要的工程中是最好的方式
    1018ji
        9
    1018ji  
       2024-01-31 16:02:08 +08:00
    做成二方库 要不就 RPC ,咋简单咋来呗
    ALongRanger
        10
    ALongRanger  
       2024-01-31 17:11:23 +08:00
    比较同意一楼和八楼的说法,在功能较为单一的情况下,将导出功能抽离为一个公共导出 jar ,各个子模块直接依赖,通过实现接口提供需要导出数据,由公共 jar 完成数据组装,格式处理、相关上传推送的处理是会比较合适的。

    导出请求直接通过网关或者直接打到对应服务模块完成。
    jfds
        11
    jfds  
       2024-01-31 17:20:06 +08:00
    这种场景 rpc 调用开销可以忽略不计
    5sheep
        12
    5sheep  
       2024-01-31 17:20:47 +08:00
    所有,作者最终选择了哪种方案
    matepi
        13
    matepi  
       2024-01-31 17:27:41 +08:00
    大数据量处理,若考虑处理效率,实现应就近数据节点、而不是就近计算节点;计算找数据,而不是数据找计算。

    所以你想想最好么,当然是在数据本地(如数据库本地)做。真考虑效率的场景,导出根本轮不到 java ,就在数据库当场做了。

    那么,更偏激一点的说法,既然你都不在数据库当场做了,那么选择是否多一个 rpc 很可能也没啥区别了。
    wu00
        14
    wu00  
       2024-01-31 17:41:32 +08:00
    我们服务只做查询,数据给到前端不管是生成 excel 还是 csv 都在前端生成,撑死在 bff 层做下聚合;
    超量数据不给实时导
    nanjingwuyanzu
        15
    nanjingwuyanzu  
       2024-01-31 17:42:15 +08:00
    我们把导出的功能单独做了个服务,各模块通过消息发送给这个服务,这个服务能连所有的微服务,收集完数据后导出
    qiyilai
        16
    qiyilai  
       2024-01-31 17:49:35 +08:00
    这个和微服务没啥关系吧,一个 jar 包的事
    wushigejiajia01
        17
    wushigejiajia01  
       2024-01-31 18:09:11 +08:00
    1. 简单处理,就是导出功能做成 jar 包给其他服务调用
    2. 导出功能做一个模块,多数据源取数
    lidashuang
        18
    lidashuang  
       2024-01-31 20:01:46 +08:00
    别搞微服务
    kanepan19
        19
    kanepan19  
       2024-01-31 20:07:04 +08:00
    导出其实也是比较耗开销的东西,在导出中心,做一些限制, 比如最多 6 个线程可以导出, 其他排队等待状态。
    怎样导出不 oom ,等等。这些才是关注点。
    pengxiaoyu
        20
    pengxiaoyu  
       2024-02-01 16:42:48 +08:00
    个人理解 数据导出是上游服务 对接各个数据提供服务 数据导出流程 应该是 浏览器请求->数据导出服务->查询数据提供服务(订单服务等)-> 生成文件 -> 上传到 oss ->返回前端 url
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2694 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 11:45 · PVG 19:45 · LAX 03:45 · JFK 06:45
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.