node 微服务架构是否会降低后端的效率和响应时间，有没有什么解决办法呢？

Question

问题描述

最近在使用 node 构建一个数据处理系统，涉及到的模块较多，因此打算采用微服务架构，目前使用了一个微服务框架 Seneca，采用 tcp 进行通信。

Seneca 微服务主要负责和db通信、以及数据处理计算（不是很耗时的计算）。

这里大部分数据处理计算的工作都可以延时完成，但是前端 http 的返回和其中的一部分工作比如数据库查询工作有关，所以需要等待某些微服务模块有返回结果了（或返回部分结果了）再返回给前端。
于是我通过ab测试发现：采用 Seneca 的方式比原来各个模块写在一起直接引入的方式，效率要低好多，比较坏的情况下，甚至平均响应时间是原来的 1.5 倍。
这个也不难理解，毕竟会有通信的开销，还可能因为采用了 Seneca 造成其他的隐形成本。

我现在有点迷茫，采用了微服务的话，可以使模块之间解藕，对开发有一定方便，但是却会降低效率，感觉有些得不偿失。
我对微服务的理解也并不深刻，只是觉得能在代码维护上给这种单体系统带来好处，另外就是微服务的单个服务方便扩容。

是不是我的使用方式不对？还是说微服务本来就有降低效率这个问题？各位是如何解决的呢？希望能指点一二。

Answer 1

你的理解是正确的，微服务本来就会降低效率。但是为什么我们还要采用微服务？答案也是显而易见的，你自己也提出了：解耦。但是不能为了解耦而解耦，解耦也是有目的的，而且目的绝不仅仅只是为了开发方便。不采用微服务，你所有的模块都必须跑在同一台主机上，如果模块很多，占用内存过大，CPU消耗过多怎么办？这时候你势必要把一部分模块分出来放置到另一台服务器上去，这时候就产生了微服务的需求，两台服务器之间总要通过网络进行通信吧，通过网络进行通信的两个模块无论如何也会比运行在同一台服务器上的两个模块要慢。但是架构就是这么个架构，剩下的只是如何提高速度的问题，比如考虑加一些缓存了，负载均衡了等等。