前言

本文记录应用架构的发展，RPC的思想。

分布式系统

分布式系统是若干独立计算机的集合，这些计算机对用户来说是单个的相关系统。

直白解释：多台计算机负责不同的功能，相互交互，但对用户来说和用一台计算机没有区别。

单一服务器无法完成如此复杂和如此大量的需求（比如淘宝），因此将不同的功能拆分成不同的功能模块，分别部署在不同的服务器上。

所有的功能模块全部写在一个程序之中，打包成一个包，部署在一个服务器上。当流量不大，功能简单时方便好用。如果流量增大，则服务器无法承受。当功能复杂时，即使部署多台服务器，每一台也无法承受。

难以扩展，难以协同和维护（任何小的改动都需要在所有服务器上更改）

将程序拆分成几块互不相关的独立应用，分别部署，并且将压力大的部分多部署几台。

无法做到界面和业务逻辑的分离，每次页面的小改动都需要重新部署

应用不可能完全独立，大量的应用之间需要交互。

将应用的核心业务抽取出来，前后端分离。有的服务器专门部署各个界面，其他服务器分别部署应用的不同核心业务逻辑，之间进行交互。

之前同一业务在同一服务器上，进行的是进程内通讯，现在的交互是不同服务器间的，称为远程过程调用remote procedure call（RPC）。

分布式架构的难点在于如何进行RPC和如何拆分业务以减少重复。

无法进行动态调控，由于部署各个业务的服务器个数是一定的，会造成压力大的业务服务器不够，压力小的业务服务器闲置浪费

引入调度中心，负责维护服务间的复杂关系，实时管理服务集群，给访问量大的业务多分配服务器。并且平衡跑相同业务的服务器上的请求个数。

一种进程间的通信方式，是思想而不是规范。（类比JVM是一种思想，各种JVM的实现就是规范）

A服务器要调用B服务器上的方法，A上的stub通过网络和B建立连接并且传出相关的参数，之后B上的stub接受参数，执行相应的方法，将操作的结果传回给A。通过stub的帮助，表面上调用远程方法和调用本地方法没有差别。

对于实现这种RPC思想的RPC框架，通信效率和序列化反序列化效率是两个评判标准。

常见的RPC框架：dubbo， gRPC，Thrift，HSF