共计 826 个字符，预计需要花费 3 分钟才能阅读完成。
本篇次要是对 dubbo 进行一些根本的介绍，让大家理解一下什么是 dubbo。这里是基于 dubbo 2.7.x 版本进行的介绍。
什么是 dubbo
如果当初公司要你做一个分布式的服务程序，要保障整个零碎的高可用、高并发、高牢靠，你会怎么做？首先必定会去网上搜是否有现成的框架，通过搜寻你很有可能会搜到 dubbo、spring cloud 等，他们都是为了分布式服务程序做筹备的。当然，你也有可能会感觉这些都太 low，本人去开发一个，那你要思考哪些货色呢？
1、服务之间调用如何做负载平衡
2、服务之间调用出错了如何进行降级解决
3、服务之间如何进行高效稳固的通信
4、服务端如何裸露服务、生产端如何调用服务
5、如何监控到整个服务零碎的运行状况
6、…
除了性能上的实现，你还得思考如何对业务端通明、可能疾速接入。
以上说的这些如果你要本人做一个的话，预计没个一年半载是不太可能的。此时 dubbo、spring cloud 就露出身影了。这里咱们不探讨 Spring Cloud，只介绍 dubbo，从下面的问题能够看出，dubbo 就是为了解决这些货色的框架，再进一步总结：一套基于 RPC 的分布式服务通信和治理框架。
比对
这两幅图更形象地阐明了 dubbo 到底是什么。
社区活跃度
作为一款支流的 rpc 通信框架，dubbo 的成长天然也是离不开社区的奉献，从对应的源码 star 咱们就能看出 dubbo 的受关注度。
另外从 issue 的解决状况也看进去活跃度
模块
这里说的模块次要是指 dubbo 调用各方的形成，截取官网一张图：
能够看到有 4 个模块
- 服务提供方
- 服务生产方
- 服务注册方
-
服务监控方
其中必须的是服务提供方、生产方和注册方。
简略的介绍一下这个图：大略就是有一个服务注册方，服务提供方启动的时候把提供的服务注册到注册方，服务生产方在启动的时候去注册方订阅服务，一旦有服务变动，注册方会被动告诉到服务生产方进行服务列表更新，另外咱们能够启动服务监控方对所有运行的服务进行监控。元素
最初介绍一下 dubbo 目前有哪些元