战斧的博客

在当今互联网时代，随着用户量的不断增长和业务复杂性的提升，高并发成为了很多系统面临的挑战。Dubbo作为一种优秀的分布式服务框架，在大规模高并发场景下也面临着一系列的挑战，其中最突出的，就是大量调用带来的流量问题。这次我就和大家一起探讨下Dubbo在高并发情况下的问题，并针对性地介绍流量控制解决方案，帮助大家更好地应对高并发场景下的挑战

前面我们学习了很多理论知识，但一切理论都是为了实践。Dubbo作为一个框架当然有很多配置点，其中有些配置不起眼，但却很重要。笔者曾经分享过一起内存溢出的问题，其中就有接口超时时间配置得太长的原因，因为数据量比较大，三方接口迟迟无法返回结果。而超时时间又很长，最终大量线程阻塞在调用上，资源无法释放，造成内存溢出。由此可见，合理的参数配置是多么的重要

经过前面一系列的铺垫，今天终于迎来Dubbo最最本质的功能了，即服务调用。前面我们不止一次的说过，Dubbo不满足于仅仅作为一个RPC框架。如图，我们甚至可以在官网看见其对自身的定义然而前面不管是服务暴露，还是服务引用，其实都算RPC的组成部分。而Dubbo真正的花活，在服务调用这里开始展现，亦是其自诩超越普通RPC的地方，老规矩，我们先自己构思几个问题，带着问题去学习：服务调用的底层是网络通信，这部分是靠什么实现的?Dubbo超越普通RPC框架的底气究竟是什么?

我们在Dubbo与SpringCloud对比的那一期就说过，Dubbo并不满足于作为RPC框架，除了RPC所需要的内容，还提供了如服务治理等额外的支持。但是无奈，很多人对Dubbo的印象就是RPC框架，因为其核心还是围绕RPC进行的。上一篇我们讲了服务暴露，今天来学习RPC桥梁的另一端：消费者，也就是服务的引用。

今天开始，将正式的进入Dubbo 核心功能的掌握与学习，Dubbo的最核心功能是什么？自然是其RPC功能，而该功能其实分为三个方面：1.服务暴露2.服务引用3.服务调用三者分别专注于服务提供者、服务消费者、服务调用过程。服务暴露有几种？分别是怎么实现的？远程暴露支持什么？注册中心如果服务提供者宕机了，注册中心如何应对？

今天又是手把手教程的一篇————手把手教你搭建Dubbo项目，边搭建边教，一共两种模式的工程，文中还有工程源码压缩包，也欢迎下载

我们之前说过SPI机制，谈到过SPI与API的区别，也讲了JAVA中的SPI机制实例，今天，我们要来讲讲Dubbo的SPI机制

提到Dubbo，很多人都并不陌生，也是这些年来的热点面试内容。笔者也有很深的印象，在n年前的一场面试中，面试官问了一个问题：请至少说出Dubbo的六个包名，笔者当时虽然看过部分源码，但从未关注过包名，内心五味杂陈，当场就懵了。当然了，除开这种角度奇怪的提问，Dubbo也有一些看起来比较"正常"的面试题，比如著名的:Dubbo 和 Springcloud 有什么区别？