![牟泉禹[Dark Cat]](/views/front/img/head.png){kind=avatar}
SpringBoot 26 分布式和RPC
26.1 什么是分布式
分布式系统是若干独立计算机的集合，但是这些计算机对于用户来说就像独立的单个系统。
分布式系统是由一组通过网络进行通信，为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用 廉价的、普通的机器完成单个计算机无法完成的计算、存储任务等。其目的是利用更多的机器，处理更多的数据。
通过网络进行通信：是第一种方法 http 请求。
还有一种把这些计算机串起来的方法：RPC 远程过程调用（可以调用另外一台计算机上的东西）
如上可知：如果没有网络，将他们进行通信。何谈 分布式呢？
分布式系统的概念，是 谷歌 Google 最早提出和使用的。那个时候的 谷歌公司 还不是很富有。所以 就把 很多的 廉价的服务器、个人机 都当作服务器来使用。（那就肯定要想办法 将这些机器联调起来呀，也就是后来的分布式系统 。）
只有当单个节点的处理能力无法满足日益增长的计算存储任务的时候，且硬件的提升（比如加内存条、加磁盘使用过更好的CPU）高昂到得不偿失的时候，应用程序也不能进一步优化的时候！！我们才会去考虑所谓的分布式系统。因为分布式系统要解决的问题，本身就是和单机系统一样的。而由于分布式系统的多节点性质、通过网络通信的拓扑结构，会引入很多单机系统没有的问题！
当然，为了解决这些问题 就会引入更多的机制、协议、带来更多的问题。所以分布式也不见得是一件好事，但也不见得是一件坏事
26.2 应用架构的发展
Dubbo 文档
随着互联网的发展，网站应用的规模居然不断地在扩大，常规的垂直应用架构已无法应对！而分布式的服务架构以及流动计算架构势在必行！
单一应用架构
当网站流量很小时，只需一个应用，将所有功能都部署在一起。以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架（ORM）成为了关键！
适用于小型网站，小型管理系统，将所有功能都部署到一个功能里面，简单易用！
缺点：
- 性能扩展比较难
- 协同开发问题
- 不利于升级维护
垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，反而是将应用拆成互不相干的几个应用，效率会更加的高。此时，用于加速前端页面开发的Web框架（MVC）成为了关键。
通过切分业务来实现各个模块独立的部署，降低了维护和部署的难度，团队各司其职更加容易管理，性能扩展也更加方便，更有针对性。
缺点： 公用模块无法重复利用，这属于开发性的浪费。（因为你拆分的这些业务，没法互相通信，那么它们 的公共部分就都不能舍去！）
分布式服务架构
当垂直应用越来越多的时候，应用之间的交互就没法避免了！将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架（RPC）是关键。
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现。此时需要增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心（SOA）[Service Oriented Architecture] 是关键点了。
比如这个中间的 注册中心，我们就可以 放到 云端。
26.3 什么是 RPC
RPC【Remote Procedure Call】是指远程过渡调用，是一种进程间通信的方式，它是一种技术的思想，而不是规范。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，*而不是程序员显式编码这个远程调用的细节。*即程序员无论是调用本地的还是远程的函数，本质上编写的调用代码基本相同。
说白了就是：两台服务器 A、B。一个部署在 A 服务器上的应用，现在想要调用 B 服务器上的应用所提供的函数/方法。由于它俩不在一个内存空间里，所以肯定不能直接调用啊，怎么办呢？这个时候就需要通过网络来表达调用的语义和传达调用的数据。
那么为什么要用 RPC 呢？
答：用 RPC 的原因就是 无法在一个进程内，甚至 一个计算机内 通过 本地调用的方式完成 现在的需求呀，你不是 要 调用 其它 计算机上的嘛。比如 不同的系统间的通讯，甚至是不同的组织间的通讯，由于计算能力需要横向的扩展，需要在多台及其组成的集群上部署应用。那么 PRC 就必须 得 使用了！它可以 像 调用本地的函数一样去调用远程的函数。
用 HTTP 不行吗？**
答：HTTP+Restful，其优势很大。它可读性好，且可以得到防火墙的支持、跨语言的支持。而且，在近几年的报告中，Restful大有超过RPC的趋势。但是使用该方案也有其缺点，这是与其优点相对应的：
- 首先是有用信息占比少，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息。
- 其次是效率低，还是因为第七层的缘故，必须按照HTTP协议进行层层封装。
- 还有，其可读性似乎没有必要，因为我们可以引入网关增加可读性。
- 此外，使用HTTP协议调用远程方法比较复杂，要封装各种参数名和参数值。
换句话说：HTTP 这玩意 根本就不是 用来 解决 分布式系统问题的。只是说 它可以解决，但是它不是为此而生，不是专业的。只是 恰好 能够解决罢了。
- HTTP和RPC都属于远程调用；HTTP是一种国际语言，大家都用的协议，而RPC往往是指与框架相关的定制化协议，及上层的IDL；
- （框架有什么：gRPC、brpc、thrift、srpc等；IDL有什么：protobuf、thrift等；）所以，如果我们更习惯用HTTP，那么只是因为它更通用；如果我们更习惯用RPC，那么只是因为框架使得我们操作IDL更方便；
- 我们既可以用HTTP client访问RPC server，也可以用RPC client发出HTTP请求；我们先看看两者的关系，再看看两者的对比，就很容易理解为什么要有HTTP也要有RPC了。
所以需要再说一句，不是说RPC好，也不是说HTTP好，两者各有千秋，还在比拼中。
RPC 基本原理图：
RPC 两个核心模块：通讯、序列化
序列化：数据传输的时候，肯定需要转换呀。因为你是 网络传输呀，你不可能在传输的时候，传的是 一个 实例类对象吧。咋放呢？？你传输的东西，肯定是 1/0 的二进制数据呀。所以才需要序列化和反序列化。你序列化后的东西，只有反序列化才能还原成 传输前的那个对象。