共计 3751 个字符，预计需要花费 10 分钟才能阅读完成。
写在后面
对冰河有肯定理解的读者都晓得，冰河经验了一个高并发电商零碎用户从零到上亿的整个研发过程，前期也由此衍生出电商零碎（商城 + 秒杀）和基于海量数据的实时精准商品举荐平台。局部外围常识已总结到我出版的两本书籍——《海量数据处理与大数据技术实战》和《MySQL 技术大全：开发、优化与运维实战》中。随着电商零碎业务的一直倒退，咱们须要对系统一直的迭代降级，这期间，Dubbo 功不可没。
在微服务畛域有两个比拟闻名的技术栈：SpringCloud / SpringCloud Alibaba（目前 SpringCloud Alibaba 有超过 SpringCloud 的势头）和 Dubbo。而 Dubbo 作为一个服务治理的 RPC 框架，在大厂面试的过程中，简直是一个必问的技术。所以，我打算写一个深度解析 Dubbo 的系列专题，揭开 Dubbo 的神秘面纱，让更多的小伙伴彻底把握 Dubbo。
这篇就作为 Dubbo 源码系列的开篇吧！！
注：写完 Dubbo 再写 SpringCloud Alibaba 系列。
文章已收录到：
https://github.com/sunshinelyz/technology-binghe
https://gitee.com/binghe001/technology-binghe
Dubbo 的外围能力
总体来说，Apache Dubbo 是一款高性能，轻量级的开源 RPC 框架，提供了六大外围能力：
- 面向接口代理的高性能 RPC 调用。
- 智能容错和负载平衡。
- 服务主动注册和发现。
- 高度可扩大能力。
- 运行期流量调度。
- 可视化的服务治理与运维。
具体细节小伙伴们能够参见 Dubbo 官网文档。
为何学 Dubbo
为何要深度学习 Dubbo，那必定是要解决某种业务场景啊。接下来，咱们就聊一聊为何学习 Dubbo。不过在介绍为何学习 Dubbo 前，咱们先来看看随着业务的一直倒退，咱们的零碎在架构上会有哪些变动。
单体利用架构
在企业倒退的初期，个别公司的网站流量都比拟小，只须要一个利用，将所有的性能代码打包成一个服务，部署到服务器上就能撑持公司的业务。这样也可能缩小开发、部署和保护的老本。
比方，大家都很相熟的电商零碎，外面波及的业务次要有：用户治理、商品治理、订单治理、领取治理、库存治理、物流治理等等模块，初期咱们会将所有模块写到一个 Web 我的项目中，而后对立部署到一个 Web 服务器中。
这种架构特点有其长处：
- 架构简略，我的项目开发和保护成本低。
- 所有我的项目模块部署到一起，对于小型我的项目来说，保护不便。
然而，其毛病也是比拟显著的：
- 所有模块耦合在一起，尽管对于小型我的项目来说，保护不便。然而，对于大型项目来说，却是不易开发和保护的。
- 我的项目的各模块之前过于耦合，如果一旦有一个模块呈现问题，则整个我的项目将不可用。
- 无奈针对某个具体模块来晋升性能。
- 无奈对我的项目进行程度扩大。
正是因为单体利用架构存在着诸多的毛病，才逐步演变为垂直利用架构。接下来，咱们就来看看垂直利用架构。
垂直利用架构
随着企业业务的一直倒退，发现单节点的单体利用不足以撑持业务的倒退，于是企业会将单体利用部署多份，别离放在不同的服务器上。然而，此时会发现不是所有的模块都会有比拟大的访问量。如果想针对我的项目中的某些模块进行优化和性能晋升，此时对于单体利用来说，是做不到的。于是乎，垂直利用架构诞生了。
垂直利用架构，就是将原来一个我的项目利用进行拆分，将其拆分为互不想干的几个利用，以此来晋升零碎的整体性能。
这里，咱们同样以电商零碎为例，在垂直利用架构下，咱们能够将整个电商我的项目拆分为：电商交易系统、后盾管理系统、CMS 管理系统等。
咱们将单体利用架构拆分为垂直利用架构之后，一旦访问量变大，咱们只须要针对访问量大的业务减少服务器节点即可，无需针对整个我的项目减少服务器节点了。
这种架构的长处：
- 零碎进行了拆分，可依据不同零碎的拜访状况，有针对性的进行优化。
- 可能实现利用的程度扩大。
- 各零碎可能分担整体拜访的流量，解决了并发问题。
- 一个零碎产生了故障，不利用其余零碎的运行状况，进步了整体的容错率。
这种架构的毛病：
- 拆分后的各零碎之间绝对比拟独立，无奈进行相互调用。
- 各零碎不免存在重叠的业务，会存在反复开发的业务，前期保护比拟艰难。
分布式架构
咱们将零碎演变为垂直利用架构之后，当垂直利用越来越多，反复编写的业务代码就会越来越多。此时，咱们须要将反复的代码形象进去，造成对立的服务供其余零碎或者业务模块来进行调用。此时，零碎就会演变为分布式架构。
在分布式架构中，咱们会将零碎整体拆分为服务层和体现层。服务层封装了具体的业务逻辑供体现层调用，体现层则负责解决与页面的交互操作。
这种架构的长处：
- 将反复的业务代码形象进去，造成公共的拜访服务，进步了代码的复用性。
- 能够有针对性的对系统和服务进行性能优化，以晋升整体的拜访性能。
这种架构的毛病：
零碎之间的耦合度变高，调用关系变得复杂，难以保护。
SOA 架构
在分布式架构下，当部署的服务越来越多，反复的代码就会越来越多，对于容量的评估，小服务资源的节约等问题比较严重。此时，咱们就须要减少一个对立的调度核心来对集群进行实时治理。此时，零碎就会演变为 SOA（面向服务）的架构。
这种架构的长处：
应用注册核心解决了各个服务之间的服务依赖和调用关系的主动注册与发现。
这种架构的毛病：
- 各服务之间存在依赖关系，如果某个服务呈现故障可能会造成服务的雪崩（对于穿透、击穿和雪崩的问题，小伙伴们能够参见我之前写的《【高并发】面试官：讲讲什么是缓存穿透？击穿？雪崩？如何解决？》一文）。
- 服务之间的依赖与调用关系简单，测试部署的艰难比拟大。
微服务架构
随着业务的倒退，咱们在 SOA 架构的根底上进一步扩大，将其彻底拆分为微服务架构。在微服务架构下，咱们将一个大的我的项目拆分为一个个小的能够独立部署的微服务，每个微服务都有本人的数据库。
这种架构的长处：
- 服务彻底拆分，各服务独立打包、独立部署和独立降级。
- 每个微服务负责的业务比拟清晰，利于前期扩大和保护。
- 微服务之间能够采纳 REST 和 RPC 协定进行通信。
这种架构的毛病：
- 开发的老本比拟高。
- 波及到各服务的容错性问题。
- 波及到数据的一致性问题。
- 波及到分布式事务问题（小伙伴们能够参见我后续会继续更新的【分布式事务】专题）。
为何学习 Dubbo？
（1）系统升级过程中须要应用 dubbo 解决问题。
在零碎架构降级和微服务落地的过程中，咱们须要解决很多的问题，比方：
- 将一个我的项目拆分为多个服务之后，服务于服务之间如何高效的通信？
- 服务的调用如何做到负载平衡和高可用？
- 服务的调用如何做到限流？又如何疾速的感知到依赖服务宕机？
- 服务的边界如何定义？
- 当零碎中存在的服务越来越多时，如何进行服务治理等等。
这些问题，咱们都能够应用 Dubbo 来解决。
（2）互联网大厂须要把握 Dubbo 技术。
很明确，很多互联网大厂都须要深度把握 Dubbo 这项技术。这里说的深度把握，并不只是停留在简略的应用层面，而是对 Dubbo 的外围原理和源码有肯定的了解。换句话说：就是你要对 Dubbo 的外围原理和源码很熟，在高并发、大流量场景下要可能联合 Dubbo 的原理和源码剖析出问题所在，并可能进行相应的性能调优。
所以说，如果你想进互联网大厂，最好是把握 Dubbo 的外围原理和源码。
Dubbo 的应用场景
在分布式架构、SOA 架构和微服务架构下，Dubbo 有其充沛的用武之地。有些小伙伴可能会说：咱们零碎中应用的是 SpringCloud 技术栈，不须要应用 Dubbo 呀！其实，应用 SpringCloud 和 Dubbo 是不抵触的，甚至二者也能够联合应用。例如，我所经验的我的项目，有些独立的模块应用了 Dubbo 作为 RPC 框架，有些模块则应用了 SpringCloud，二者并不是抵触的，能够做到互相促进的作用。
总体来说，Dubbo 的应用场景如下：
RPC 分布式服务
当网站变大后，不可避免的须要拆分利用进行服务化，以进步开发效率，调优性能，节俭要害竞争资源等。
比方：为了实用一直变动的市场需求，以及多个垂直利用之间数据交互不便，咱们把公共的业务抽取进去作为独立的模块，为其余的利用提供服务，零碎逐步依赖于形象和 rpc 近程服务调用。
配置管理
当服务越来越多时，服务的 URL 地址信息就会爆炸式增长，配置管理变得十分艰难，F5 硬件负载均衡器的单点压力也越来越大。
服务依赖
当进一步倒退，服务间依赖关系变得错踪简单，甚至分不清哪个利用要在哪个利用之前启动，架构师都不能残缺的形容利用的架构关系。
服务扩容
接着，服务的调用量越来越大，服务的容量问题就裸露进去，这个服务须要多少机器撑持？什么时候该加机器？等等……
Dubbo 总结
总之，用官网的话说：Apache Dubbo 是一款高性能、轻量级的开源 Java 服务框架，提供了六大外围能力：面向接口代理的高性能 RPC 调用，智能容错和负载平衡，服务主动注册和发现，高度可扩大能力，运行期流量调度，可视化的服务治理与运维。
Dubbo 的六大外围能力可能为咱们在疾速迭代微服务项目时，更好的提供 RPC 和服务治理能力。如果你想进大厂，就最好把握 Dubbo。
好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，也能够加我微信：sun_shine_lyz，一起交换技术，一起进阶，一起牛逼~~
