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

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

系统大概的情况

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

后端采用的架构

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

总体对接情况

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

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

  • 架构

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

    142 引用 • 442 回帖
  • Q&A

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

    8116 引用 • 37012 回帖 • 160 关注

相关帖子

欢迎来到这里!

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

注册 关于
请输入回帖内容 ...