原文地址：https://blog.csdn.net/chenli522/article/details/47082433
dubbo总结(1)——关于我和dubbo
我和dubbo这个东西结缘纯属一次意外中的意外，就在两年前，在csdn博客上随意浏览，开始是被dubbo这个单词吸引了，开始只是纠结于他的发音，后来当我慢慢的深入去了解它，或者是在两年间的使用过程中，它已经成为了技术生涯中的重要里程碑。
dubbo这个东西，起源于阿里巴巴，对于做电商开发的人来说，dubbo似乎已经成为了一个代名词，有的人觉得它高大上，有的人觉得也不过就是soa的一个服务治理框架。也曾经一样在dubbo的官方群和一群人一起讨论dubbo和soa的区别，也曾和梁飞做过交流，过往的总总现在回忆起来，带有很多美好的糊涂和豁然开朗。
这东西使用了两年，也曾莫名其妙出现服务挂掉之后无法启动，也曾在做集群过程中，系统挂掉出现选不出leader的时候影响dubbo，总之在我的技术进程中，是dubbo成就了我，让我站在巨人的肩膀上看到了更广阔的技术。
所以，当我在这家公司准备离职的时候，刚好这几天可以闲下来，对前几年做个总结，我把我对dubbo的总结和整个学习的过程记录下来，肯定写不出高大上的东西，或许更多的只是自己的回忆，也希望能把我学习dubbo的经验带给读者吧，互相进步。
dubbo总结(2)——dubbo的使用场景
关于dubbo的使用场景，这个要从系统的演变开始将起，既然dubbo的使用很多是在电商系统中，那么就从电商系统的演变开始讲起。
一个简单的电商网站说起，它可能包含如下的几个模块和功能，如首页、detail页、list页、下单页、支付页以及后台管理等页面和功能。单一的系统架构，使得在开发过程中，占用的资源越来越多，而且随着流量的增加使得维护起来越来越难以维护。
于是就产生了垂直应用架构，垂直应用架构解决了单一应用架构所面临的扩容问题，流量能够分散到各个子系统当中，且系统的体积可控，一定程度上降低了开发人员之间协同以及维护的成本，提升了开发效率。但是在垂直架构中相同逻辑代码需要不断的复制，不能复用。所以分布式系统就这样应运而生了。
公共的逻辑业务提取出来形成服务，对外提供。这样对于维护和升级都只需要切分成一个一个的小系统去维护，也可以让前端业务系统与底层数据访问分离，团队分工更为明确。
分布式系统所依赖的基础设施包括服务框架、消息中间件、数据访问中间件、配置中心、分布式缓存系统、持久化存储(关系数据库、nosql数据库)、搜索引擎、CDN网络、负载均衡系统、运维自动化系统、硬件虚拟化及镜像管理系统、分布式文件系统、日志收集系统、监控系统、离线计算、实时计算、数据仓库等等。随着服务化的进一步发展，服务越来越多，服务之间的调用和依赖关系也越来越复杂，诞生了面向服务的架构体系(SOA)，也因此衍生出了一系列相应的技术，如对服务提供、服务调用、连接处理、通信协议、序列化方式、服务发现、服务路由、日志输出等行为进行封装的服务框架。
就这样为分布式系统的服务治理框架就出现了，dubbo也就这样产生了。dubbo在整个分布式系统的架构中，按照分层的架构来架构，使得各个层级之间最大限度的松耦合.
Dubbo（三）Dubbo的详细介绍、设计思路、以及4大适用场景
转自：https://baijiahao.baidu.com/s?id=1612574809664801766&wfr=spider&for=pc
Dubbo是什么？
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）。
其核心部分包含:
1. 远程通讯:
提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。
2. 集群容错:
提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。
3. 自动发现
基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo能做什么？
1.透明化的远程方法调用
就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
2.软负载均衡及容错机制
可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3. 服务自动注册与发现
不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
Dubbo采用全spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。
Dubbo的架构和设计思路
Dubbo框架具有极高的扩展性，主要采用微核+插件体系，并且文档齐全，很方便二次开发，适应性极强。
Dubbo的总体架构，如图所示：
Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。
Dubbo框架设计一共划分了10个层：
服务接口层（Service）：该层是与实际业务逻辑相关的，根据服务提供方和服务消费方的业务设计对应的接口和实现。配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接new配置类，也可以通过spring解析配置生成配置类。服务代理层（Proxy）：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。服务注册层（Registry）：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry和RegistryService。可能没有服务注册中心，此时服务提供方直接暴露服务。集群层（Cluster）：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router和LoadBalance。将多个服务提供方组合为一个服务提供方，实现对服务消费方来透明，只需要与一个服务提供方进行交互。监控层（Monitor）：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor和MonitorService。远程调用层（Protocol）：封将RPC调用，以Invocation和Result为中心，扩展接口为Protocol、Invoker和Exporter。Protocol是服务域，它是Invoker暴露和引用的主功能入口，它负责Invoker的生命周期管理。Invoker是实体域，它是Dubbo的核心模型，其它模型都向它靠扰，或转换成它，它代表一个可执行体，可向它发起invoke调用，它有可能是一个本地的实现，也可能是一个远程的实现，也可能一个集群实现。信息交换层（Exchange）：封装请求响应模式，同步转异步，以Request和Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。网络传输层（Transport）：抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server和Codec。数据序列化层（Serialize）：可复用的一些工具，扩展接口为Serialization、 ObjectInput、ObjectOutput和ThreadPool。和淘宝HSF相比，Dubbo的特点是什么？
1. Dubbo比HSF的部署方式更轻量
HSF要求使用指定的JBoss等容器，还需要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，如果你要运行在Weblogic或Websphere等其它容器上，需要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。
2. Dubbo比HSF的扩展性更好，很方便二次开发
一个框架不可能覆盖所有需求，Dubbo始终保持平等对待第三方理念，即所有功能，都可以在不修改Dubbo原生代码的情况下，在外围扩展，包括Dubbo自己内置的功能，也和第三方一样，是通过扩展的方式实现的，而HSF如果你要加功能或替换某部分实现是很困难的，比如支付宝和淘宝用的就是不同的HSF分支，因为加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。
3. HSF依赖比较多内部系统
比如配置中心，通知中心，监控中心，单点登录等等，如果要开源还需要做很多剥离工作，而Dubbo为每个系统的集成都留出了扩展点，并已梳理干清所有依赖，同时为开源社区提供了替代方案，用户可以直接使用。
4. Dubbo比HSF的功能更多
除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。
Dubbo适用于哪些场景？
1.RPC分布式服务
当网站变大后，不可避免的需要拆分应用进行服务化，以提高开发效率，调优性能，节省关键竞争资源等。
比如：为了适用不断变化的市场需求，以及多个垂直应用之间数据交互方便，我们把公共的业务抽取出来作为独立的模块，为其他的应用提供服务，系统逐渐依赖于抽象和rpc远程服务调用。
2.配置管理
当服务越来越多时，服务的URL地址信息就会爆炸式增长，配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
3.服务依赖
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
4.服务扩容
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？等等……
在遇到这些问题时，都可以用Dubbo来解决