单体应用拆分为微服务遭遇水土不服,服务间资源调用不畅,如何修改架构?

查看 94|回复 7
作者:chinaguaiu   
如题,公司团队此前比较缺乏微服务开发的经验,开发前期也只是简单按照模块划分的思路设计了微服务,思路简述为:在业务上呈现内聚的资源将被整合为一个服务,服务的业务逻辑实现是需要频繁访问这部分资源的;而如果仍然需要额外的资源(这个资源划分到了其它服务),通过服务间通信解决(使用 Restful 请求或者中间件);一些服务间通用的资源通过 jar 包依赖的形式引入。
一段时间的开发之后产生了一些阻碍,主要发生在服务间资源调用中,如下:
[ol]
  • Restful 接口方式调用服务间资源十分缓慢和繁琐。服务对外暴露的 Restful API 全部是直接面向外部调用设计的,每一次调用都需要走完完整的参数处理以及鉴权验证逻辑。服务间之间互相调用依然是使用这种 API ,每一次调用都基本等同于外部调用,需要重新走一次参数处理和鉴权验证的逻辑,运行效率很差,也导致方法实现中充斥大量冗余参数和冗余返回结果(对于服务间调用来说) 。
  • 某些功能的实现需要频繁进行服务间资源调用。这个意思不是服务调用链路太长,而是诸如服务 A 的某一业务逻辑需要同一时间需要重复访问服务 B 五到六次,或者说服务 A 的某一业务逻辑需要同时访问服务 B 、C 、D 、E 、F 等。又由于 1 的问题,效率极差。
    [/ol]
    如何针对性解决两个问题?重新设计一类面向内部服务调用的 Restful 接口?还是服务间调用引入 MQ 中间件?
    想请教一下 V 友们有没有相关的解决思路,由于公司团队包括我自己也没有太多开发微服务的经验,还望大家可以详细讲讲。

    调用, 服务, RESTful, 资源

  • kkk9   
    1 、参数处理以及鉴权验证逻辑应该由网关前置处理,后面的相关服务默认网关给定的数据是完全可信的。同时拆分中间服务的参数和结果,只保留必须的传递。最后由网关后置处理进行统一输出。
    2 、优化调用就需要具体问题具体分析了。比如:服务 A 的某一业务逻辑需要同一时间需要重复访问服务 B 五到六次,是否可以优化成一次全部读取,只在服务内各取所需。
    emSaVya   
    rpc 调用怎么会慢? 直接上 brpc 又快又好。
    内部服务不需要鉴权。
    同时访问的服务 整理一个 tag 出来, 没有依赖的直接并行请求。
    devopsdogdog   
    不合适就不拆,拆出毛病才是正常的。
    业务量真的很大?大到每个模块都得独立?
    Chad0000   
    我也在给公司拆单体,我的方案更柔和:
    - 先确保每个服务(我这里是模块)的独立性,尽量不要引用其他模块
    - 模块功能抽象成接口,功能定义和实现分离
    - 提出运行环境的概念,即负责跑这些模块的层
    - 运行环境也负责对调用者返回实际实例
    - 将大部分常见操作抽象,实现放运行层,即避免模块接触实现细节
    - 模块只管触发事件,不订阅
    - 设定一个统一的业务模块负责订阅所有消息,再通过运行层调用其他模块
    关键部分:
    - 一个运行环境可以托管任意个模块,如果模块调研在同一个环境则直接本地调用。
    - 迁移过程中基本上只有一个运行环境就是单体本身,本地调用不影响性能
    - 模块和它抽象的接口在单体完成依赖注入,这样单体可以直接调用新的模块
    - 之后你可以实现跨运行环境通讯,也就是 RPC
    - 可以将经常调用的模块放同一个运行环境中,以提升性能
    - 模块所需基础能力(数据库访问/配置读取/缓存访问等)都抽象并由运行环境提供后,那么模块基本上可以动态加载了
    基于此:
    - 如果运行环境只跑一个模块,那就是微服务
    - 如果运行环境跑所有模块,那就是单体
    - 介于两者之间的,那就是混合模式
    - 上述设计保障了只要你在运行环境你就可以访问所有模块
    - 考虑到业务模块订阅了所有消息,那么每个运行环境都部署一个业务模块会避免更多的 RPC
    目前这个计划实施得相当好。
    teble   
    一般来说鉴权不应该是微服务网关统一鉴权吗,所有微服务处于同一内网的情况理论上应该是相互可信的,不太清楚具体业务,个人感觉服务间通信的鉴权开销是完全没必要的
    kkk9   
    @Chad0000 #4 你这个感觉就是容器概念啊,单独一个模块的时候是微服务,多个的时候是单体。感觉出问题就是 All in BOOM 😅 个人见解,也可能我没理解透彻
    wu00   
    先搞个简单粗暴的改造,外层网关 => BFF => 业务服务
    网关处理鉴权认证,请求只转发到 BFF ,BFF 内网并行请求各服务&&整合数据,业务服务不对外暴露,一开始不要把服务拆的太细,尽可能保证独立。
    最后,单体改造成支持分布式再铲铲屎山就行了,最好别盲目搞微服务,如果是为了“练手”搞“履历”,当我没说。
    您需要登录后才可以回帖 登录 | 立即注册

    返回顶部