这种情况有必要这么设计吗?

本贴最后更新于 403 天前,其中的信息可能已经时移世易

系统大概的情况

内网系统,使用人数 50 人以内(这是往高了估计,同时使用人数不会超过 5 个),数据量特别小,每个模块的数据条数都不会超过 200 条(这也是往高了估计)

后端采用的架构

Spring Cloud,四个微服务,三个分布式数据库,登录还用的 Oauth2.0(实际上就一个系统 😅)

总体对接情况

明明一个步骤解决的问题,拆成了几步甚至几十步,本来对接是一件非常简单的事情,被硬生生搞成对接超级费事

这种情况真的有必要这样去设计架构吗?这么小的一个系统,以后也不会有很高的扩展,是不是不管什么情况就上微服务,分布式就是对的呢?总接口数才那么多,搭架构用了几个月,写接口几天就搞定了,这不是一种病态吗?

  • 架构

    我们平时所说的“架构”主要是指软件架构,这是有关软件整体结构与组件的抽象描述,用于指导软件系统各个方面的设计。另外还有“业务架构”、“网络架构”、“硬件架构”等细分领域。

    133 引用 • 440 回帖
  • Q&A

    提问之前请先看《提问的智慧》,好的问题比好的答案更有价值。

    3035 引用 • 15832 回帖 • 494 关注

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...
  • wangning1018
    捐赠者

    别问,问就是微服务,分布式,SOA

  • mymoshou

    不好说,有那么多的系统就代表有未来的规划..现在就近解决,未来就要重构,得不偿失。 但是如果三年内还是这样,当我没说

  • Eddie
    捐赠者

    搞麻烦一点自己不容易被替代啊

  • someone61489 1 评论
    捐赠者 支持者

    less is more

    避免过度设计
    someone61489
  • Gakkiyomi2019
    订阅者

    微服务也不是这么微的啊,你这是分子服务吧?