关于架构客户端的一个疑问

Question

danny老师 ，看到您的架构图，我们公司一直以来就有一个问题争论不休：
就是
假设客户端里面的那套软件也是基于微服务框架的，存在多个进程（多人负责），（而服务器也是基于微服务框架的，也是多人负责各自进程）那么这几个进程要和服务器通讯的话，就存在2种方案
第一种：
每个进程各自通过服务端各个服务提供的接口进行通讯，然后交互所需要的数据，自己处理自己的。
第二种：
在客户端 的微服务软件框架里面 增加一个 专门与 服务器数据通信的进程，该进程负责 收集客户端内各个服务的数据 ，然后由他统一向服务器层进行交互，服务器下发的数据 也由这个进程进行接受，然后由这个客户端进程转发到客户端内部的rpc框架里面来，然后 客户端的其他服务接受数据 进行处理

我所在的公司有人认为
第一种方案
比较方便，但出了问题比较难查，耦合性太强了
第二种方案
增加工作量，但客户端和服务端的2个系统耦合性没那么强了

关于那种方案更好？这个事情争论了很久，也没有结论。我想听一下老师的看法

Answer 1

Danny_Idea 2023-11-28 09:39:49

我没太能理解你描述的场景，这里的客户端为什么也会有微服务架构设计一说，我理解的客户端一般都是些小程序，app，网页等这类用户操作的平台。

• 提问者 qq_慕斯卡2526505 #1

  Danny 老师您好 我说的场景如下：
  风力发电站上会有一个储能系统，该储能系统上面运行的是BMS 软件(电池管理软件），由于这种大型设备的BMS比较复杂，所以该软件是基于微服务构建的。
  然后这一个个风力发电站需要能量的调度 自然需要一个服务器进行智能化管理 ，所以这些一个个的储能系统上面的软件（bms）就需要和服务器进行交互了，这里面的就是类似 客户端-服务器的说法 自然就会有我上面说的 那2种方案了 我们自己想了很久 那种方案更好一点，一直没讨论明白

• 提问者 qq_慕斯卡2526505 #2

  希望老师能帮忙指点一下哈

• Danny_Idea 回复 提问者 qq_慕斯卡2526505 #3

  建议进学习群来进行讨论，更加方便

点开查看后面2条评论