还需要限流熔断，限流是因为服务提供者不知道会接入多少调用者，也不清楚每个调用者的调用量，所以需要衡量一下自身服务的承受值来进行限流，防止服务崩溃。
而熔断是为了防止下游服务故障导致自身服务调用超时阻塞堆积而崩溃，特别是调用链很长的那种，影响很大。
比如A=>B=>C=>D=>E，然后 E 出了故障，你看ABCD四个服务就傻等着，慢慢的资源就占满了就崩了，全崩。
大致就是以上提到的几点，不过还能细化，比如负载均衡的各种策略、限流到底是限制总流量还是根据每个调用者指定限流量，还是上自适应限流等等。
这个在之后分析 Dubbo 的时候都会提到，等着哈。
最后我之前面过一个同学，两年经验，简历写着熟悉 Spring Cloud Alibaba 然后了解 Dubbo 。
我问他 RPC 的调用原理，他问我什么是 RPC，没听过这个名词。
这就太浮在表面了。
理解原理还是很重要的，像我上面提到的动态代理也不是一定是要的，像 C++ 就没有动态代理， gRPC 框架用的是代码生成。
反正最终只要能屏蔽调用细节，不需要使用者关心即可，至于用什么方式达到这个目的，影响不大。
还有上面提到面向接口，其实有时候就是没接口，例如一些服务网关，暴露出 HTTP 调用的方式给调用者来调用后端 RPC 服务。
网关是要接入很多后端服务的，所以不可能依赖后端的接口，不然就不灵活了。
这里就有个泛化调用的概念。
其实只要你理解了请求方无非就是告知服务提供方我要调哪个方法，参数都是哪些，你就能很容易的理解什么叫泛化调用。
也就能理解其实不需要接口我们也能进行 RPC 调用。
具体泛化调用是什么之后写 Dubbo 会提到。
所以听起来好像很高级的玩意，如果你理解了本质，其实也就这么点东西。
万变不离其宗。
欢迎关注我的公众号【yes的练级攻略】，更多硬核文章等你来读。
