文章目录
提示：以下是本篇文章正文内容，Dubbo 系列学习将会持续更新
官方文档：https://cn.dubbo.apache.org/zh-cn/overview/home
一、互联网架构演变
1.1 RPC架构
RPC 架构是指在 MVC 架构的基础上，将公共业务模块抽取出来，作为独立的服务供其他调用者消费，以实现服务的共享和重用。
- RPC：Remote Procedure Call，远程过程调用。他一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
- 代表技术：
Thrift(Facebook 开发的系统内部各语言之间协调通讯的 RPC 框架，带有强大的代码生成引擎，支持跨语言、多平台调用的)、Hessian(基于HTTP协议的 RPC 框架，提供 RMI 功能，且采用二进制协议的轻量级框架) 等等。 - 优点：应用直接调用服务，服务之间是隔离的。
- 缺点：服务过多时，管理成本高昂。服务治理，服务注册、发现，服务容错，服务跟踪，服务网关，IP暴露等都是此架构无法避免的问题。
1.2 SOA架构
SOA：Service oriented Architecture，面向服务架构；ESB：Enterparise Service Bus，企业服务总线，服务中介，主要是提供了一个服务于服务之间的交互。- ESB 的功能：负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
- 代表技术：
Mule(Java 为核心的消息框架和整合平台，提供服务中介、数据转换、消息路由、服务创建和托管等功能)、WSO2(开源的服务总线，提供了 SOA 基础设施的搭建，内置数据服务支持，服务角色管理等功能)。
1.3 微服务架构
- 微服务是一种架构风格。一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。微服务就是一个轻量级的服务治理方案。
- 微服务架构在某种程度上是面向服务的架构 SOA 继续发展的产物。对比 SOA 架构，使用注册中心代替 ESB 服务总线。注册中心相比服务总线来说，更加轻量级。
- 代表技术：
Dubbo(SOA时代的产物)、SpringCloud(微服务时代的产物)
1.4 SOA vs 微服务
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 小型、专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
二、RPC 基本概念
2.1 RPC 协议
RPC (Remote Procedure Call Protocol)：远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC 协议假定某些传输协议的存在，如 TCP 或 UDP，为通信程序之间携带信息数据。在 OSI 网络通信模型中，RPC 跨越了传输层和应用层。RPC 使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC 采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
2.2 RPC 框架
在单机时代一台电脑运行多个进程，进程之间无法通讯，显然这会浪费很多资源，因此后来出现 IPC(Inter-process communication：单机中运行的进程之间的相互通信)，这样就能允许进程之间进行通讯，比如在一台计算机中的A进程写了一个吃饭的方法，那在以前如果在B进程中也要有一个吃饭的方法，必须要在B进程中进行创建，但有了 RPC 后B只需要调用A进程的程序即可完成，再到后来网络时代的出现， 大家电脑都连起来，这时可不可以调用其他电脑上的进程呢，当然可以，这样 RPC 框架就出现了。严格意义上来讲：Unix 的生态系统中 RPC 可以在同一台电脑上不同进程进行，也可以在不同电脑上进行；而在 windows 里面同一台电脑上不同进程间的通讯还可以采用 LPC(本地访问)。综上：RPC 或 LPC 是上层建筑，IPC 是底层基础。
RPC框架有很多：比如 JAVA RMI 、 Thrift 、 Dubbo 、 grpc 等。
2.3 RPC 运行流程
首先，要解决通讯的问题。主要是通过在客户端和服务器之间建立 TCP 连接，远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接，调用结束后就断掉，也可以是长连接，多个远程过程调用共享同一个连接。
第二，要解决寻址的问题。A 服务器上的应用怎么告诉底层的 RPC 框架，如何连接到 B 服务器（如主机或IP地址）以及特定的端口，方法的名称名称是什么，这样才能完成调用。比如基于 Web 服务协议栈的 RPC，就要提供一个 endpoint URI，或者是从 UDDI(一种目录服务，通过该目录服务进行服务注册与搜索) 服务上查找。如果是 RMI 调用的话，还需要一个 RMI Registry 来注册服务的地址。
第三，要进行序列化或编组。当 A 服务器上的应用发起远程过程调用时，方法的参数需要通过底层的网络协议如 TCP 传递到 B 服务器，由于网络协议是基于二进制的，内存中的参数的值要序列化成二进制的形式，通过寻址和传输将序列化的二进制发送给 B 服务器。
第四，B 服务器收到请求后，需要对参数进行反序列化，恢复为内存中的表达方式，然后找到对应的方法进行本地调用，然后得到返回值。
第五，返回值还要发送回服务器 A 上的应用，也要经过序列化的方式发送，服务器 A 接到后，再反序列化，恢复为内存中的表达方式，交给 A 服务器上的应用。
2.4 RPC vs HTTP
RPC 是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 所以 RPC 的实现可以通过不同的协议去实现，比如 HTTP、RMI 等。
-
RPC 是一种概念，可以通过 HTTP 来实现，也可以通过 Socket 自己实现一套协议。
-
HTTP 接口：信息初期的一种通信手段；优点就是简单、直接、开发方便，利用现成的 HTTP 协议进行传输。
RPC 框架：不需要复杂的三次握手，在子系统较多、接口非常多的大型网站下，减少了网络开销。 -
HTTP 接口：服务端必须位于 HTTP 容器里，受限于 HTTP 协议，需要带 HTTP 请求头，导致传输起来效率或者说安全性不如 RPC。
RPC 框架：它要保证传输的两端都要用 Java 实现，且两边需要有相同的对象类型和代理接口，不需要容器，但加大了编程的难度。 -
Java 中最基本的 RMI 技术，它是 java 原生的应用层分布式技术。在传输性能方面，RMI 的性能是优于 HTTP 的。
-
RPC 框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，RPC 框架是一个强力的支撑。
总结:
提示：这里对文章进行总结：
本文是对Dubbo的学习，先介绍了互联网架构演变的过程，又认识了 RPC 架构，了解了 RPC 和 HTTP 的区别。之后的学习内容将持续更新！！！