冰河开始对Dubbo下手了！

写在前面

对冰河有必定了解的读者都知道，冰河经历了一个高并发电商系统用户从零到上亿的整个研发过程，后期也由此衍生出电商系统（商城+秒杀）和基于海量数据的实时精准商品推荐平台。部分核心知识已总结到我出版的两本书籍——《海量数据处理与大数据技术实战》和《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，一块儿交流技术，一块儿进阶，一块儿牛逼~~