01 | 核心原理：能否画张图解释下RPC的通信流程？

我们目前服务内部调用都是使用 rpc，对外接口采用 restful 接口。 采用rpc 开发最终要我觉得是设置合理超时时间以及重试次数。因为 rpc毕竟需要走网络调用，存在网络耗时。超时间太短，可能导致服务提供端实际执行成功，消费端却因为超时报错结束。这就有可能导致数据状态不一致。 另外，整个链路的超时需要合理设置，如A-》B-〉C，A的超时时间要大于B。 重试次数也需要关注，默认情况下，如 dubbo 重试次数为2，调用失败的情况下，框架会重新调用。而有些服务不能重复调用。 服务提供者应该是最熟悉自己服务的，所以服务提供者可以设置默认超时时间以及重试次数，消费者不设置，就会采用服务提供者参数设置。 😅想了下，开发过程中其实还有好多细节要注意，细节决定成败，后面章节可以再聊聊，让我们跟老师一起学习。

1、你应用中有哪些地方用到了 RPC？ 在公司内部不同服务之间的调用都是走的RPC 2、你认为，RPC 使用过程中需要注意哪些问题？ 1）下游服务的服务能力，避免因为你的调用把别人给调挂了，要事前协商好qps等，做好限流 2）调用服务异常时，要考虑降级、重试等措施 3）核心的服务不能强依赖非核心的服务，避免核心服务因为非核心服务异常而不可用

1：你应用中有哪些地方用到了 RPC？ 我认为还是分开说比较好一点，侠义的RPC就是为了实现进程间方法调用像进程内方法调用一样简单。广义的RPC可以认为只要跨进程通信就是RPC，即使是在一台机器上两个进程间进行通信了，也是RPC，，不过目前来看RPC更强调侠义的含义。广义的含义和网络通信是一个意思，话说两台电脑之间想通信不靠网络靠什么呢？人肉操作嘛？ OK，RPC核心就是为了应用解藕而存在，只有系统间是进程通信必然会用到RPC。 2：你认为，RPC 使用过程中需要注意哪些问题？ 第一服务注册服务发现，服务注册中心 第二服务治理，有多少服务？都是那些服务？谁调用谁？怎么下线服务？怎么修改服务分组？怎么修改服务别名？服务限流怎么控制？服务降级怎么控制？服务上下游信息？服务调用链信息？ 第三服务监控，方法调用链监控？每个方法的监控，比如：TPS/调用量/可用率/以及各种汇总聚合信息，最小/最大/平均/各种TP分位统计，报警配置信息等等，这些东西一下就知道服务是否可用？在一个完整的调用链上那个服务比较慢？也可以统计服务的调用次数？对于分析排查问题，尤其是性能问题帮助非常大 第四日志查询平台，实时日志、现场日志、历史日志都能根据关键字界面化傻瓜式的查询出来，也能统计出日志里的报错信息关键字等。非常利于业务问题的排查，及时发现系统中的业务问题。 第五配置中心，可以调整日志级别、各种业务开关、服务分组别名信息，对于服务控制会非常灵活。 话说JD这些做的还挺不错，不过全链路跟踪系统好像做的还不太好，如果这个改造好了，那链路上那个系统慢就一目了然了，性能问题的排查会更简单方便。

第一幅图中，编解码是一种码吗？ 为什么序列化后生成编解码后还要再编码，才能放到网络上呢? 为什么不能直接一步序列化就放到网络上？

现在最严重的问题就是事物吧，分布式事物，感觉一直没有好办法解决

1. 你应用中有哪些地方用到了 RPC？ 我们的应用是微服务架构的，RPC就是连接这些微服务之间的纽带。 2. 你认为，RPC 使用过程中需要注意哪些问题？ 因为RPC也是网络调用，性能方面肯定不如本地调用，所有RPC的API设计要仔细考虑，比如一次性能完成的调用就不要走多次调用。另外我认为最重要的是要有监控系统能监控所有的调用链，方便问题排查和性能调优。

1、你应用中有哪些地方用到了 RPC？ 答：我们目前系统进行拆分（C++开发的），也是分布式部署的，我们的RPC在系统间交互（或同步）数据时使用RPC接口进行调用。其次，我们RPC还是一个信息管家，可以通过事件进行提醒应用层主备机信息等。 2、你认为，RPC 使用过程中需要注意哪些问题？ 答：这个问题让我想起了一次面试中面试官问我“你觉得一个设计RPC框架中最重要的是哪一点？”我当时首先说了RPC框架首先是通信、自定义协议（protobuf）、序列化、注册中心。我们的RPC由于C++开发的，只提供消息传输的功能，序列化和协议在应用层做的（主要是考虑不同项目的业务也有区别）。我觉得其中最重要的就是注册中心（数据中心）实现了，这个决定了RPC所能提供扩展功能。

我觉得广义来说，只要涉及调用的网络通信都属于RPC的范畴，包括Rest API，因为本质上都是走网络通信的非本地调用。 关于服务内部用RPC，服务外部用Rest API，主要考量的还是安全性。服务内部网络一般认为是相对安全的，因为已经有了很多手段来避免数据包外泄，故不需要强认证。而服务外部是对公网开放的，或至少部分是对公网开放的，数据在公网传输被认为是相对不安全的，所以要强认证。认证强弱的差别导致了RPC分成两派：针对服务内的高效的狭义RPC，和针对服务外的相对低效的RPC(Rest API)。 早在EJB的时代，有个叫RMI的东西，流程和RPC惊人的一致，只不过RMI还需要调用方维护大量底层细节，感觉RPC是从RMI发展来的，是好用版RMI。

老师你好，最近在从零开始手写个RPC框架，深有感触。 实现了多种序列化机制，集成了protobuff、protostuff、json和hessian等。 目前在编码服务发现，基于zk，思路是有，不是太清晰，编码总是断断续续。 希望多点实战性的指导

调用过程中超时了怎么处理业务？ 重试机制，降级处理。 什么场景下最适合使用 RPC？ 网络安全稳定的环境。 什么时候才需要考虑开启压缩？ 压缩后，数据量有明显的降低，压缩会使用CPU等资源，还是要看性价比。