企业微服务建设难点：接口拆分多个微服务后带来的接口响应慢，怎么办？

理论上不会有慢的现象，可从以下方面查
（1）使用skywalking或其他APM监控软件，定位问题，哪种服务慢；
（2）查看慢的服务所属容器的cpu和内存配置，以及在运行时的cpu和内存负载；
（3）如果cpu和内存占用很大，需要进一步拆分应用。
（4）检查是否有串行的微服务，此类微服务不适合拆分

这个问题应该是拆分之前没有做好规划
1、拆分以后链路会边长，服务之间的通信、交互、处理会耗时间，这是正常的现象，但不至于造成性能陡降
2、拆分原则有几个，轻重、快慢、读写、多少
3、如果慢，通过链路监控看慢在哪里，然后进行扩容、包括微服务组件扩容，优化

一个应用功能被拆分成多个服务之后，原本调用一个接口就能完成的功能如今变成需要调用多个服务，如果按顺序逐个调用的话，使用微服务改造后的接口会比原始接口响应时间更长，因此要把原本串行调用的服务修改为并行调用。 例如接口 A ，需要调用 S1 （耗时 200 毫秒）， S2 （耗时 180 毫秒）， S3 （耗时 320 毫秒）这 3 个接口，使用串行调用方式，那么接口 A 累计耗时 =SUM(S1+S2+S3)=700 毫秒。为了让响应时间更短，就需要把这些串行调用的方式更改为并行调用的方式，并行调用方式调用接口 A 累计耗时为 MAX(S1 ， S2 ， S3)=320 毫秒。可以使用 jdk8 提供的 CompletableFuture 方法来并行执行。

微服务拆分之后，调用链路变长肯定会有性能下降的问题，这个无法避免。如果因为交易压力陡增，导致接口相应慢，那是不是要考虑增加该瓶颈节点的实例呢？