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

如题，公司团队此前比较缺乏微服务开发的经验，开发前期也只是简单按照模块划分的思路设计了微服务，思路简述为：在业务上呈现内聚的资源将被整合为一个服务，服务的业务逻辑实现是需要频繁访问这部分资源的；而如果仍然需要额外的资源(这个资源划分到了其它服务)，通过服务间通信解决(使用 Restful 请求或者中间件)；一些服务间通用的资源通过 jar 包依赖的形式引入。

一段时间的开发之后产生了一些阻碍，主要发生在服务间资源调用中，如下：

1. Restful 接口方式调用服务间资源十分缓慢和繁琐。服务对外暴露的 Restful API 全部是直接面向外部调用设计的，每一次调用都需要走完完整的参数处理以及鉴权验证逻辑。服务间之间互相调用依然是使用这种 API ，每一次调用都基本等同于外部调用，需要重新走一次参数处理和鉴权验证的逻辑，运行效率很差，也导致方法实现中充斥大量冗余参数和冗余返回结果(对于服务间调用来说) 。
2. 某些功能的实现需要频繁进行服务间资源调用。这个意思不是服务调用链路太长，而是诸如服务 A 的某一业务逻辑需要同一时间需要重复访问服务 B 五到六次，或者说服务 A 的某一业务逻辑需要同时访问服务 B 、C 、D 、E 、F 等。又由于 1 的问题，效率极差。

如何针对性解决两个问题？重新设计一类面向内部服务调用的 Restful 接口？还是服务间调用引入 MQ 中间件？

想请教一下 V 友们有没有相关的解决思路，由于公司团队包括我自己也没有太多开发微服务的经验，还望大家可以详细讲讲。