Dubbo-高性能RPC通信框架

本章主要内容：

?应用架构演进过程;

?Dubbo 简介；

?Dubbo总体大图。

本章主要是对Dubbo总体的介绍，让读者对Dubbo有一个总体的认识。首先介绍后台应用架构的演进过程，从最初的JEE到现在的微服务架构都会介绍；然后简单介绍一下Dubbo,包括它的发展历史、未来方向等；最后讲解Dubbo的总体大图，通过分层的方式讲解Dubb。的总体架构，并介绍Dubbo的核心组件及总体流程。

应用架构演进过程

单体应用

1. JEE时期

JEE是Java Platform Enterprise Edition的简称，提供了企业级软件开发的运行环境与开发工具。JEE的出现极大地推动了企业信息化进程。

JEE把企业软件划分为展示层、业务逻辑层和数据存储层，如图1.1所示。

最终，各层的组件会被聚合到一起运行在通用的服务器上，如JBoss、WebSphere > Tomcat等。注意，Tomcat M实现了 JEE Web部分的规范。JEE应用会把大量通用的业务逻辑、流程封装到通用组件中，少量定制化逻辑则通过配置文件的方式来访问通用组件。

JEE的优点和缺点都非常明显。优点：分层设计明确了不同团队的分工，职责清晰、分工明确，衍生出了前端团队、后端团队和DBA团队；JEE的开发简单，所有的类都能直接本地引用及使用，事务的处理只需要依赖数据库即可。由于企业级应用通常面向内部用户，使用者较少，也不需要考虑高并发等场景，加上JEE的稳定性，所以基本能满足日常的需求。缺点：大多数应用都在一个JVM中，随着应用的增大，性能会不断下降；业务之间的耦合严重，即使企业内部有不同的规范和约束，但随着业务逻辑复杂度的增加，开发人员的不断流动，整个应用的维护会变得越来越难；EJB使用大量的XML作为配置文件，后期要配置出一个服务的学习成本很高。各种各样的规范约束加大了开发者的开发成本。

2. MVC框架时期

由于EJB的各种问题严重影响了软件开发效率，为了降低成本提高生产力，开源框架开始成为企业的标配，这个时期比较主流的框架有Spring> Struts> Hibernate等。架构也从之前的分层架构变为了 MVC架构，如图1-2所示。

其中Model属于模型部分，主要负责具体的业务逻辑和数据存取；View是视图，主要处理应用的展示部分；Controller是控制器，主要处理用户的交互，它会从视图层读取数据并传递给模型。

在这个时期，常见的有SSH的框架组合。使用Struts进一步划分了 Web UI的职责。Spring负责Bean的管理及IoC、AOP等特性o Hibernate则负责ORM,实现对象与数据库的关系管理，将数据库中的数据抽象成一个个对象。

随着时间的推移，Struts也推出了 2.0版本，但更加轻量级的Spring MVC逐渐成为主流。

0RM框架也从Hibernate逐渐迁移到更加轻量级、灵活的MyBatis上。Spring家族却一直蓬勃发展，成为现在应用的必备框架之一。

这一时期的架构与JEE比较相似，但MVC的分层更加简单，框架也更加轻量级，开发效率有了很大的提升，单元测试方面也更加完善。但这一时期的应用最终还是会被打到一个War包里，并且部署在Tomcat等Web服务器里。即使各个企业有自己的规范和约束，但系统的耦合度一直没有太大的改善。团队的职能依然按照层次来划分，有前端团队、后端团队和DBA团队等。

到了后期，有很多企业会对应用做垂直拆分，即把业务上没有关联的系统独立拆分出来，形成独立对外提供服务的系统。此时，服务之间完全独立，无法进行远程调用，很多基础代码不能复用，需要复制使用。这种方式从一定程度上缓解了单体应用造成的臃肿，但无法从本质上解决问题。因此，为了解决这些存在的问题，衍生出了后面的分布式应用。

1.1.2分布式应用

1.早期SOA

正所谓合久必分，由于之前是单应用部署，导致所有业务都在一个JVM中运行，业务之间的耦合也是“剪不断理还乱”，经常出现“牵一发而动全身”的情况。随着企业业务的不断发展，老应用会不断膨胀直到无法维护。另外，由于互联网的to C业务的不断兴起，传统单应用已经无法满足高并发的需求，经常出现性能瓶颈的问题。单进程的水平扩展能力也极其有限。

为了解决以上问题，面向服务的架构（SOA 出现了。SOA将单一进程的应用做了拆分，形成独立对外提供服务的组件，每个组件通过网络协议对外提供服务。网络协议可以是TCP,也可以是HTTP等，正是通过这种协议，服务之间可以通过接口进行交互。SOA有以下特点：

?明确的协议。服务之间的交互都通过特定的协议进行。

?明确的接口。根据规则划分出不同的服务，每个服务都有明确的对外接口。这让服务的复用成为可能。

?合作方式的改变。后端团队会根据不同的服务进一步拆分，有了更加细化的分工与合作方式。

?通信方式。初期的通信方式通常为XML,由于XML有大量的冗余信息，后来被JSON取代。

常见的SOA实现方式有两种：Web Service和ESB。Web Service通常使用SOAP协议，即用HTTP或HTTPS来传输XML数据。所有的Web Service服务都会注册到Web Service的目录中，每个服务都依赖于这个目录来发现存在的服务。Web Service的工作原理如图1.3所示。

ESB简称企业服务总线，也是SOA的一种实现方式。服务之间的通信与调用都通过总线来完成，因此ESB没有注册中心一说。总线负责服务之间消息的解析、转换、路由，控制服务的可插拔，统一编排业务信息处理流程，等等。这种实现特别适合老企业的内部，不同语言开发或不同来源的应用系统，如外部购买、自研等，应用之间没有统一的交互协议。通过ESB总线可以屏蔽这些问题。ESB的工作原理如图1-4所示。

Web Service和ESB的缺点都显而易见，比如Web Service的通信协议笨重，服务化管理设置不完善；ESB本身就是一个很重的东西，系统的变更可能又反过来影响总线的变更。

2. 微服务化

为了解决早期SOA中存在的各种问题，近几年的服务化架构得到了进一步的演进，逐渐形成了更加细粒度的微服务架构。在微服务架构中，一个应用会被拆分一个个独立、可配置、可运行、可维护的子服务，极大地方便了服务的复用，通过不同的服务编排方式，快速产生新的业务逻辑。微服务和SOA 一脉相承，SOA的思想在微服务中依然有效并做了升华。但微服务与SOA还是有一定区别的。

?目的不同。ESB更加强调业务流程的编排，历史应用的集成。而微服务使用一系列微小的服务来实现整体流程，可以有效地拆分服务，从而实现敏捷的部署与交付。

?服务粒度不同。微服务拆分得更加细小，从而可以方便地复用服务，编排出新的业务逻辑。SOA通常是比较粗粒度的划分。

?协议的不同。微服务通常都是统一的交互协议，如HTTP、自定义的协议，兼容老系统比较困难。

3. 云原生

企业应用在演进过程中又遇到了新的挑战：

?容量动态规划。微服务出现后，服务容量的评估、小服务资源的浪费等问题逐渐显现。为了实现资源的动态规划，容器化逐渐成为标配，容器编排技术也逐步走向成熟。

?服务框架的臃肿。应用虽然已经微服务化，但应用中包含大量业务无关的资源库，即使开发一个小服务也要带上一个臃肿的框架。为了让应用变得更加轻量，下沉更多的通用能力，服务网格开始出现。

2015年CNCF （云原生计算基金会）建立，开始围绕云原生的概念打造云原生生态体系。

CNCF在其GitHub上对云原生有如下定义：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统进行频繁和可预测的重大变更。
云原生计算基金会（CNCF 致力于培育和维护一个厂商中立的开源生态系统来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

觉得文章不错的话，可以转发关注一下小编！！

明天更新Dubbo 简介和Dubbo总体大图这两块知识点，希望大家能够来捧场！！