3.3.1 网络延迟

微服务之间的调用是相当频繁的，特别是一些高并发场景下更是如此。还有一些特定的服务需要反复调用鉴权类服务接口，这些都大大增加了网络的延迟。传统的基于REST风格的RPC调用采用HTTP或者HTTPS协议，无形中又增加了整个链路的响应延迟。

如果通信的过程安全以及数据安全方面的处理导致的延迟无法避免，那么可以考虑从传输链路及传输数据的角度来进行处理了。

1.传输链路方面

传输链路的处理可以采取实时监控+链路切换的方式来提升用户体验。

图3-9所示为传输链路切换流程图，从图中可以看出，在监控系统根据业务情况设定访问延迟报警的阈值之后，服务就会根据响应延迟情况来决定本次访问是否延迟。如果有延迟，则先进入异常自动应急平台处理，异常自动应急平台根据日志及延迟情况自动选择是切换链路还是释放（增加）资源。如果系统还不能恢复，则进入人工介入阶段。

2.传输数据方面

以REST风格为代表的HTTP请求，服务调用方与提供方交互的数据形式通常都是json格式。json格式的优点显而易见：友好；但是缺点也相当明显：明文传输，数据占据空间大，加大了传输过程的延迟。

MessagePack序列化后的数据所占空间比json格式要小，反序列化的延迟也比json格式小，在大量数据实时交互的场景中可以考虑替换json格式的数据。

Protobuf因为是Google力推的数据序列化格式也变得广为流行，其对数据的压缩率比MessagePack还要高，但是其反序列化速度比Messagepack要慢、比json格式要快，因此在批量传输场景中可以考虑使用。